Somewhat amusingly in the week that there seemed to be something of a backlash against ‘agile’ development methodologies I embarked on a programme of study towards the BCS Practitioner Certificate in Agile starting with a 2 day intro course and then followed up with 10 weeks of work-based coaching and weekly study groups.
There are 10 modules to study and it is a pretty intense undertaking with a final exam that apparently has a pretty low pass rate. So that is something to look forward to!
I’ve done some ‘agile’ training before back when I was still at Jiva but that was very focused on Scrum and getting that to work in a small, software startup. This seems very different. It is pretty agnostic about specific frameworks and seems much more focused on giving the skills to help embed the ideas and practices within organisations where it is probably still pretty radical and where they might currently follow the ‘half-arsed agile methodology‘ 🙂
I enjoyed the course that Özlem ran. The ONS are working with Emergn to help encourage the uptake of agile in our development teams and they clearly have a well thought out training programme and Özlem was a good trainer. That said I have to be honest I am not a fan of ‘games’ and ‘activities’ in training sessions. There was lots of Lego, spaghetti and marshmallows and even blindfolds at one point! I never really take away the lessons I am supposed to from these kinds of things – I just get frustrated and stroppy which isn’t helpful. I learn in a really quite old fashioned, if self-directed, manner.
I found the run through of the main elements of the course and the principles that underpin agile interesting (though there seems to be a blur of lines between ‘agile’ and ‘lean’ on this course – both words seem to have become a little meaningless with the amount they are mis/used). Everything was about having a framework that allows teams to add value – that is the objective. The main areas we talked about were;
Delivering Early and Often – this has always seemed one of the massive benefits to ‘agile’ for me. The ability to get away from the thinking that ‘big bang’ is always the way to go and to break things up in to smaller pieces to allow this kind of development rather than the all or nothing approach I’ve come to fear and dread.
Optimising Flow – a lot of this session was about ‘time’ and why traditional project planning frequently builds in buffers (and then buffers for the buffers) due to fear of missing deadlines. We talked about the need for some ‘slack’ to exist within teams – if everyone is working flat-out there is no room for people to adapt to the inevitable changes during development.
There is this idea of the cost of ‘task switching’ that really chimed with me – moving from task to task that are sometimes very different inevitably slows productivity – my current role seems based on doing this as much as possible!
I also loved this Standish Report stat that 64% of features in software are rarely or never used and the Michael George quote;
“..complexity is like cholesterol. It clogs up the arteries of an organisation.”
Related to this drive for simplicity and a ruthless drive to justify every feature was the idea of YAGNI (you ain’t gonna need it) which I love.
Feedback – I really enjoyed the discussions around ‘feedback’. I really believe that being much more transparent about the work and getting it in front of the right people at every opportunity really helps prevent going down the wrong paths. Even if sometimes it just means you know to pack it in earlier.
We talked a lot about the need to do more demos of working code, to get users in earlier and more often and to improve our technology for monitoring and reporting. None of our tools are really optimal yet, nor our processes but it was nice to hear about some interesting success stories around the organisation so it is clear there is hope.
Then we talked a bit about some specifics around Scrum and Kanban and how we might be able to implement some of the lessons. Like I mentioned earlier I know my way around Scrum and acting as a product owner in that environment was where I learned the most in my career and felt the most useful but it turned out I had a slightly warped idea about Kanban. I’ve mainly seen it in relation to ‘kanban boards’ and not thought of the entire process – that was really interesting and actually seemed more immediately achievable.
There are books associated with the 10 modules (in full they are the three above plus; Why Change, Teams, Motivation, Trade-offs, Adapting Agile, Scrum & Kanban.) Once I have worked my way through the course – and hopefully passed the exam – I’ll post again.
Clearly ‘Agile’ is not a silver bullet but I think demonstrating some more ‘agility’ in the way we work can only be beneficial to the organisation. There are some aspects that really will represent a massive step-change in how things work and while that will likely be disruptive in the short term it is likely to be extremely useful as time moves on.
Digital by Default 
10 responses to “Learning the value of agile”
[…] Original source – Digital by Default […]
“the three above” – I appear to be blind. What three? Also, they seem to have very pretty covers. Are there links to them?
The 3 above refers to the titles in bold in the post.. https://www.valueflowquality.com is the site for the course – the books come as part of the package when you sign up..
ah, cheers. The covers look nice at any rate 🙂
they are 🙂 I’ve only read one of the books so far but it was pretty well written. Not sure how much you’d learn if you are already actually doing it though – seems more aimed at training ‘agile coaches’..
I think there needs to be something of a “backlash against Agile”. And this isn’t some twee, ill-conceived foot-stamping to try to find blame for failing projects, this is an honest appraisal of a somewhat Utopian vision of project management that cannot always work, based on real project experience.
The main problem we see is precisely with “Delivering Early and Often”. Most of the time (not some of the time, MOST of the time) our clients do not have the budget to iterate. As soon as you cannot iterate, there is nothing to be gained, because you simply can’t “Deliver Often”. There’s only one deliverable, it’s next month, there’s nothing you can show the uninformed customer in the interim that will do anything other them panic them because it will look unfinished and they won’t understand it, and anyway – they have a fixed scope. They might SAY they don’t have a fixed scope, they might pretend to be cool with iterative working and a backlog of stories and so on, but when it comes to “acceptance” they suddenly forget all that.
In some cases (see UK government clients, for example) there is top-down instruction to “use Agile”, which is really damaging for smaller government IT projects (I mean budgets of sub-£100k) because it enforces an unsuitable model. Sure, there are aspects of some Agile frameworks that are useful across the board, but if you’re struggling to force Scrum (and let’s be honest, too many people think Agile == Scrum) onto a project where there is not enough budget for a team to iterate, a total lack of competent product ownership and a fixed scope, that project is going to leave everyone feeling bad. And there you have your “backlash against Agile”. Lullabot have been noisy this week, but my colleague Steve did a talk on this last year:
I can’t edit my comment, but I’d just like to say I misread the first paragraph and I see Matt was amused at the timing of Lullabot’s comments rather than the content. I’d also like to note we HAVE had successful agency-client Agile projects (notably with Le Figaro and Wellcome Trust) where there are informed internal teams and time and budget to iterate over months or even years – I’m just a little jaded by organisations insisting their project be Agile because they read a few interesting blog posts, when they are totally unprepared for such a step. Hence my somewhat strong reply. Sorry Matt! But I think my comments stand and are useful for context. 🙂
Cheers for the comments Greg. I think there is generally a lot of education needed on the client-side if they are going to try and commission projects and expect them to work in an agile manner. I know as I am one of these people.
Procurement processes are challenging enough (especially in Gov) and adding ‘agile’ to the mix adds additional pressure which gets passed on to the suppliers in unhelpful ways sometimes. I’m hopeful we will get better at this though – and start to value ‘agility’ of working rather than getting hung up on ‘Agile’ (which like you said too often = Scrum)
Interesting discussion. The comments by Dave Thomas in the link, are valid and apply to just about any method you care to mention, e.g. Lean, BPR, etc. These all tend to get distorted over time, through commercialization and interpretation.
I think the important thing to remember in all cases, is the philosophy behind the method. The adoption of an agile approach to design (and not just software design) is to recognise the weaknesses of linear, over non-linear approaches. After that, it becomes a matter of where, for a given project, to place the adopted approach on the continuum.
Most major business change projects (which I think is the context here), and the enabling software development that takes place within them, will sit somewhere in the middle. This still represents a huge challenge for traditional procurement and project management methods, and for those who apply them. Focusing on particular techniques and tools, rather than on the thinking, will not help.
[…] Learning the value of agile […]