In Balancing Agility and Discipline, Barry Boehm and Richard Turner attempt the unenviable task of trying to meld the agile and traditional methodology approaches to software development. Overall, they present a fairly reasonable discussion on the advantages and disadvantages of each, although I do have some qualms about the name of the book.
Staring with the title of the book and continuing throughout the text the authors depict the plan-driven methodologies as being “disciplined.” This bothers me, in that it labels agile software development as undisciplined. Anyone that has ever had to figure out how to unit test some difficult piece of software or tried to keep the daily meetings under 15 minutes knows that it takes a lot of discipline.
One telling quote is, “If one has strong discipline without agility, the result is bureaucracy and stagnation. Agility without discipline is the unencumbered enthusiasm of a startup company before it has to turn a profit.” I definitely agree that without process development degenerates into code-and-fix. However, if you are doing Scrum, even though you might not have all the pretty Gantt charts and estimates accurate to the second, you are doing agile development with discipline. In fact, Scrum is a process of continuous improvement, which corresponds to CMM Level 5 “Optimizing”, the holy grail of CMM compliance!
Merriam Webster’s dictionary definition of discipline is (only the applicable meanings are shown):
5b. Orderly or prescribed conduct or pattern of behavior, c. Self-control
6. A rule or system of rules governing conduct or activity
This doesn’t really differentiate agile processes from plan-driven processes. A word that I think is much better is rigor. Rigor is:
2. The quality of being unyielding or inflexible
4. Strict precision, Exactness
In this light, Balancing Agility and Rigor makes much more sense. Agile software development, when done right, is usually very disciplined. Plan-driven development supposedly has more discipline, but is more often abused by a lack of discipline. So while discipline is up for dispute, I doubt anyone would dispute that plan-driven methodologies are more rigorous than agile ones.
Wording aside, the authors make an effort at defining five key dimensions along which projects vary:
- Personnel – skill level of the developers
- Dynamism – volatility of requirements
- Culture – the degree to which the company prefers follows process or not
- Size – size of the project, mostly in number of developers
- Criticality – the loss due to impact of defects
Each of these factors affects whether the project should be agile or plan-driven overall. The more agile experience project personnel have, the more volatile the requirements, the higher the degree to which the company prefers chaos over order, the fewer the number of developers, and the less critical the project leads to an agile approach. The opposite of these dimensions leads to a plan-driven approach.
This is only the beginning, however, and the rest is where the authors make a substantial contribution to the current methodology literature. The authors go on to classify risks into three different types: environmental risks, agile risks, and plan-driven risks. Environmental risks apply to all projects, regardless of type (agile or plan-driven), since they include things like technology, complexity, and stakeholder coordination. Agile risks are those risks, such as scalability, personnel turnover, simple design, and skill level, which tend to impact agile projects more so than plan-driven projects. Plan-driven projects, though, have their own risks, namely changing requirements, speed of delivery, emerging requirements, and personnel skill level.
Once a project’s various risks are recognized, the base project type (agile or plan-driven) is then customized to address the biggest risks. Simple to describe, difficult to apply. There are also several examples of project tailoring. One adds plan-driven aspects to an agile project; another shows adding agile elements to a plan-driven base. The advice is also to tailor up, that is to add plan-driven rigor when needed, versus trying to remove rigor when it is not needed.
The skeptical reader will ask, so where’s the proof? Luckily Boehm and Turner have plenty. The primary source is a large group (100+) of projects at USC, with secondary input coming from the huge Cocomo II project database. You know the agile movement is coming of age when there are actual statistics to back it up, found in this book and in Agile and Iterative Development, by Craig Larman. Finally we can cast off the agile witch doctors who peddle their “agile wares” without proof or analysis other than “it seemed like a good (agile) idea.”