In Balancing Agility and Discipline: A Guide for the Perplexed, Barry Boehm and Richard Turner contrast Plan Driven and Agile software development processes. A Plan Driven process is associated with defined process, process improvement, heavy documentation, and high ceremony. An Agile process is associated with prioritizing people over process, embracing change, and a focus on working software. On the surface, these approaches appear to be in complete conflict with each other. It seems that software development teams ultimately must make a choice of which approach to take.
As the title of the book suggests, Boehm and Turner spend most of the book providing advice on how to mix Plan Driven and Agile approaches. They have some tools in the book to help a project team determine what approach would be optimal. In this post, I’m going to discuss how my team, the Microsoft Business Framework, fits into the Boehm / Turner model for determining where a project should be on the Plan Driven vs. Agile scale.
(Side Note: I do have an issue with the title of the book as it implies that Agile is not Disciplined – this is far from the truth. A better title would have been Balancing Plan Drive and Agile, IMO.)
There are 5 critical factors that are described in the book for evaluating a project for the suitability of agile or plan driven methods. I’m not going to spend much time describing each factor (you can buy the book!), but I will describe where MBF sits on each one.
- Team Size (more planning is required for a large team) – MBF is a large project, hence more towards the Plan Driven end.
- Criticality (more critical – loss of life potential is the extreme– requires more formality of Plan Driven) – With the potential for loss of critical business data, MBF sits in the middle of this scale.
- Dynamism (more stable requirements allow a team to be more Plan Driven) – Given where MBF sits in the Microsoft stack, we are subject to a lot of changing requirements. We need to be on the agile end of this scale.
- Personnel (less experienced team requires the more formal process of a Plan Driven approach) – MBF is fortunate to have strong, experienced technical leadership gleaned from years at Great Plains, Navision, and Microsoft. We do have some less experienced staff also, but I think we’re able to support less formal process due to the experience of the staff.
- Culture (a team that thrives on order needs to be Plan Driven; a team that thrives on chaos can handle Agile approaches) – Hmmm, I’m not sure where our organization fits on this scale. Let’s put it in the middle.
Using these factors, the answer is clearly …. well, not that clear. We have one factor that is clearly on the Plan Driven end of the scale (Team Size) and one factor that is clearly on the Agile end of the scale (Dynamism). The remaining three factors are somewhere in the middle.
It appears that MBF needs to have some elements of Plan Driven process and some elements of an Agile process. I could quibble about the model that Boehm / Turner use, but referencing other methodologists with other models (see Alistair Cockburn’s Agile Software Development – a very good book) would likely come to the same conclusion. It’s a reality for large projects like ours.
My goal is to be as agile as possible, but we need to support our agility with some overarching Plan Driven approaches. This combination of Plan Driven and Agile is what MBF has been evolving to and will continue to evolve to over the upcoming months. I plan to write more about the some of the specifics that we are doing in these areas in upcoming posts.