In his now infamously named book “Balancing Discipline and Agility”, Barry Boehm, creator of the Spiral method, juxtaposed plan-driven and agile methods in terms of their discipline. His main point is that both planned and agile are valid methods depending on the context. His criteria for deciding which to us include the experience and skill of the developers, the criticality of the application, the culture of the organisation, the size of the team and the stability of the requirements. Many critics have suggested that what makes agile methods, or indeed any methods based on lean thinking (I believe agile is a lean method) work precisely because of their disciplined application. Although they must be modified to a certain context, that does not mean you can just cherry pick those practices that allow you continue with your current method pretty intact. That approach leads to a superficial adoption of agile when the underlying method does not support the core principles and values of lean and agile. However, I have another two critisisms of the ‘discipline or agile’ approach:
- It assumes planned methods are more disciplined, or enforce discipline more effectively than agile ones – this is a fallacy. Research suggests that where planned methods are employed, a mere 6% of projects follow the defined method closely, whether that method is customised to a certain context or not (see Fitzgerald, B. (1996). “Formalised systems development methodologies: a critical perspective.” Information Systems Journal 6(1): 3-23.)
- It assumes there are only two basic types of method – a false dichotomy. A recent Forrester Survey 2010 shows that only 13% of projects use waterfall methods, and 35% use various agile methods. But another 30% do not follow any method (ad-hoc) and 21% use iterative methods like RUP. Are methods other than agile and plan-driven ever valid? Boehm does not explicitly exclude them, and I see situations where they are valid in certain contexts.
Boehm has contributed hugely to the development of software engineering over the decades. But this book title gave rise to myths such as “agile can’t be relied on to produce quality and therefore critical systems” and “agile only works for experienced teams”. These myths are gradually being deconstructed as agile is scaled across enterprises composing large as well as critical projects, novice as well as expert developers. By focusing on the roots of agile in lean thinking, first generation agile methods can be extended to work effectively across a much greater array of contexts.