then, the methodological spectrum is commonly viewed as a scale running from predictive methods (such as the waterfall) to emergent methods (such as Agile practices), with convergent methods (such as RUP) occupying a broad middle ground. Balance is expressed in these terms, i.e. as being able to move up and down the spectrum - varying the level of process “ceremony” being applied - in a timely and appropriate manner.
Agility, rigor, and balance
This view can be criticised on the grounds that “revving the throttle” is too brute an instrument. It changes multiple project dimensions simultaneously, and if one goes too far with the spectrum analogy then some of them will choke off. The level of project rigor is a case in point. For example, the Agile manifesto claims to value “working software over comprehensive documentation” [Beck, 2001]. This is widely misinterpreted - by both Agile supporters and detractors - as implying that documentation is a contra-indication for Agility. It is often assumed to mean that Agile projects are, by definition, less rigorous than prescriptively managed ones (including RUP configurations) that link artefacts with stage gates and which empower managerial hierarchies. This misinterpretation has lead to the predicament where, regrettably, Agile Methods are widely assumed to mean the absence of process and not the balancing of it.
However, the Manifesto can also be interpreted as an appeal for that very balance. Valuing working software over comprehensive documentation, valuing individuals and interactions over processes and tools, valuing customer collaboration over contract negotiation, and responding to change over following a plan are expressions of emphasis, not elimination. Seen in that light Agile projects do not sacrifice rigor. Management artefacts may well be shorter and lighter, but they will also be “pithier”, more up-to-date, and perhaps even more frequently referred to than on waterfall projects. In the quest to achieve balance, the nature of documentation changes so as to become more tightly focused. Interpreting the rest of the manifesto along similar lines adduces a more pro-active model of Agile project management than is commonly assumed.
Revving the throttle then does not have to mean sacrificing project rigor. A healthy balance of management artefacts will add value, as will a judicious level of managerial authority. At the very least, developers must not have the autonomy to “self-organise” themselves into the weeds where they end up losing sight of the business case; and the project manager should never find that directing a team is an essentially reactive process, like herding cats.
Contemporary social issues with balance
This clearly has implications for developer autonomy. We have to accept that there are some Agile aficionados who have difficulty in accepting any sort of balance. For example, we could point to the so-called “evangelistic” (one might just say irascible) hardcore for whom documentation will always be “in the code”. Unfortunately, by a process of minimalist reductionism this faction can set the mores and values of an entire team. This leads to the modality of project failure where the distinction between development and fire-fighting becomes blurred, and the team attempts to code its way out of trouble.
Ironically these work habits make the devaluation of process a fait accompli . Once one person undercuts process then its predictive qualities are compromised. The value of process to the team is reduced and fewer members will subscribe to it...in effect, the problem snowballs. Yet if an Agile team is to avoid this decay, then its members will need to value the management processes that guard against it...perhaps even to the point of jointly maintaining a suitably balanced arrangement of