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. 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. Michael O. Church wrote a "rant", 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 range of values - 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.