What does it mean to do agile development? Some years ago I attended one of Jack Ganssle’s lectures on “Better Firmware Faster”. It was a great presentation – filled with high-level thinking and low-level tricks. The one thing that really got stuck in my mind was Jack’s presentation of Boehm & Turners work on the balance between driving projects in an agile manner versus a plan-driven “disciplined” approach. Somehow this work had escaped my attention up to this point. My book, as well as many of my blog-posts are technical, but in my daily work I am a manager. And when I meet with other managers the subject is often “How to be Agile?”
Judging by the job-market, these days all software projects are doing Scrum. Not just agile – but Scrum. On the Great Links for Developers page I have a link for a “rant” (as he calls it himself) by Michael O. Church, where he really takes the gloves off when it comes to Scrum. I wouldn’t say that he’s completely right – but he has got some points. Remember that “agile” does not necessarily mean Scrum – there is also e.g. Kanban.
Going back to Boehm & Turner, they showed a number of parameters that could be used to help you choose the right approach. When they say agile, they refer to anything from eXtreme Programming to Scrum.
For each Boehm & Turner parameter, I now list the value favoring agile first and the plan-based/disciplined last.
- Number of people in the project: 3-300
- Criticality (of a failure): Loss of comfort – Loss of many lives
- Culture: Thriving on chaos – Thriving on order
- Dynamism: 50% change of requirements/month – 1% of the same
- Personnel: Low number of “architect level” (my term) developers – More of the same
As far as I know, Scrum was invented for consultants developing individual web-sites. It makes sense to be able to show the customer something early – enabling you to make deviations as you go – and charge the customer accordingly. Most people would probably NOT prefer to fly in a plane designed this way. Here the waterfall/planned approach makes sense. COTS – Commercial-Off-The-Shelve products fall in a wide range between these extremes.
The “personnel” parameter could probably start a religious war: Are Boehm & Turner saying that you should do agile if you do not have great developers? Maybe they are just saying that if you really know what you are doing (application-wise but also implementation-wise), it makes sense to create a framework first and fill it out later. If not, it may be better to build iteratively – depending on the other parameters as well.
Boehm & Turner has many great observations of which a few are given here:
- “Design for the battle – not the war“. I have experienced many people that were doing Scrum or other forms of agile that forgot exactly this. Even when doing sprints & backlogs they were discussing how they needed to make code that was prepared for this and that – which is relevant in a later product-release. No – you cannot have it both ways: If you are doing agile, you must be prepared to refactor your code when you need new functionality. You are NOT supposed to prepare for that now. YAGNI: “You Arent Going to Need It” says that you might very well be preparing something that you are never going to use anyway.
- “All projects need a mixture of discipline (plan-driven) and agility”. Find out where your project is in the “homeground” – a map given by the above 5 parameters. Focus more on people than on methods. Then decide which is dominating.
- “Build your method up – don’t tailor it down.” Ouch that hurts! Almost all projects that I have heard about that run e.g. Scrum, have tailored their methods down from an ideal concept. They best we can do now (as generally is always a good idea) is to take a step back and take a look at what works in our team – and what not. And then select better processes or educate ourselves – or maybe both.
There is a good presentation of Boehm & Turners works here:
This refers to the book: “Balancing Agility and Discipline: A Guide for the Perplexed” on Amazon or elsewhere.