This article is the first in a two part series. It describes the problems that are commonly associated with Agile Methods vis-à-vis process rigor, and sets the scene for DEV’s remedial approach which will be presented in the second article. It further argues that configuration is best achieved by considering the challenges of integration in terms of orthogonal standards and frameworks. This contrasts with the process “continuum” that is widely held to exist between predictive and emergent ends of a methodological spectrum.
Introduction: Failure and Fervor
Agile methods have become the poster child for innovative, out-of-the-box project thinking. It can be argued that the eclipsing of the “old order” of prescriptive development approaches is now complete. By mid-2008 46% of respondents in an Agile Trends survey indicated that they used Agile practices, as opposed to 44% who indicated that they used waterfall methods [Davidson, 2008].
Of course, Agility does not imply immunity from risk. Making a strategic decision to embrace these new adaptive techniques does not inoculate against project failure. The reasons for this are as controversial as they are varied. For example, in some cases the software was delivered as promised but the customer remained dissatisfied [Lacey, 2008]. This can occur when stakeholder business expectations are lost in a fog of technical detail, or when the business case changes mid-course. In other situations, the organisational commitment to implementing Agility may only have been half-hearted, and it was a lack of political will that lay behind the project’s downfall. Ironically, such problems can be avoided by didactic project management techniques that rely more on authority than they do on consensus. Yet it can even be claimed that a so-called Agile project “failure” was, in truth, a success! After all, if failure happens early enough in a controlled manner, it can stop money from being wasted on a fundamentally bad project proposition.
To the ears of disappointed stakeholders, these reasons may sound no better than excuses. To Agile proponents they can be interpreted as evidencing a failure of application or interpretation of Agile Methods, and not as indicators of a systemic failure in the methods themselves. These varied responses to Agile failure have certainly exposed a polarisation of opinion about how good Agile Methods are when compared to more prescriptive approaches. Interestingly, the resulting entrenchment has even lead to perceptions that Agile advocates are consumed by an evangelistic and messianic fervor [Binstock, 2009].
Reconciliation through balance
Less radical Agile methodologists have attempted to find a healthy balance, or reconciliation, between the Agile and prescriptive worlds. The idea has been to keep the adaptive qualities which Agility brings to bear, whilst also leveraging the benefits associated with rigorous, prescriptive waterfall-type methods.
It seems reasonable to assume that such a compromise can be reached. A very common strategy is to view agility and rigor as occupying opposite ends of a methodological spectrum. An appropriate balance can therefore be achieved for a particular project by varying iteration length, the number and type of discrete deliverables, and the level of autonomy granted to team leads and developers. Thus one can “rev the throttle” of iterative-incremental development on a case-by-case basis.
The Rational Unified Process (RUP) is representative of this philosophy. As with Agile Methods, iterations are used to review and consolidate the development effort, and incremental releases allow early evaluation and the mitigation of risk. Yet like the waterfall approach, the scope of each step can be prescribed in considerable detail beforehand. It can even correlate the production of discrete artefacts to particular stages (c.f. Vision Document, Business Case, Software Architecture Document, etc.).
In essence 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.
Figure 1
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 safeguards and management products. This chafes against the established cultural values of many code-oriented developers who profess to be working in an Agile manner.
Early attempts to integrate PRINCE2 with DSDM
One way of tackling this cultural problem is to appeal to standards. A standard can require that Agile development must occur under the mandate of a prescriptive background environment. Coding standards are an example of how an appeal to standards can work on Agile projects in practice. By extension of this model, team members can be required to subscribe to a standards-based process just as they are expected to adhere to certain coding conventions. Of course, in reality it isn’t as simple as that. There is an enormous difference in terms of the level of perceived intrusion and of sheer scale.
For example, the PRINCE2 framework is an official and de-facto standard in the UK and many other countries. It was initially developed by the Central Computer and Telecommunications Agency (CCTA) as a UK Government standard for IT project management. A rigorous and highly prescriptive method, it is typically associated with waterfall development techniques. For many years it has been seen as the antithesis of Agile Methods. Needless to say, getting Agile projects to work in conjunction with its strictures has been a significant technical and cultural challenge.
In 2006 a major overhaul of PRINCE2 was initiated to make it more flexible, and more capable of supporting recent developments in Agile practice. This was released in 2009 as the “PRINCE2:2009 Refresh”. Prior to this release, serious attempts had been made to reconcile DSDM Atern with the earlier PRINCE2 version [Richards, 2007], [Barron 2003]. Of all the Agile Methods in general use, DSDM Atern certainly stood the best chance of integration. It was product-focused, had broadly compatible artefacts and roles with PRINCE2, and featured a well-defined metamodel.
Unfortunately though, the “join” with the earlier PRINCE2 version was difficult to hide. It was generally recognised that it would be an oversimplification to assume an impedance mismatch, and to try to manage the join by associating PRINCE2 and DSDM with macro and micro level processes respectively (much as one might also try to encapsulate a Scrum sprint within a PRINCE2 work package). Instead DSDM was positioned as being cross-spectrum in scope, encompassing both project management and delivery disciplines. PRINCE2 meanwhile, was contextualised as a project management discipline focusing more on project direction and less on product delivery. Successful integration would involve the picking-and-choosing of which “bits” were thought to work best from each process, and the elision of those “bits” that didn’t. Although general recommendations can be distilled, hard experience - and an awareness of the optimum locus to occupy along the methodological continuum - are of fundamental importance in getting an approach like this to work.
Codeworks DEV: our approach to Agility and standards
The Codeworks DEV programme manages Agile projects in publically accountable environments. We have focused on Agile pilot schemes and prototyping projects. Agile Methods reconciliation and transfer has therefore been one of our responsibilities. Ironically perhaps, a linear model has proven to be a good starting point for the projects we have undertaken. We typically provide stakeholders with a narrative context which gives an indication of progress. This resolves into 4 phases of project “discovery”, project “definition”, solution “development”, and solution “delivery”. These phases, which we call the “4 D’s”, are meant to be conducted in series in order to provide narrative continuity. Although this suggests some sort of linear method, it goes no further than the provision of that high-level narrative. It can be noted from the outset that there is no proscription against the iterative implementation of any particular phase (see Figure 2) or the constituent steps within it.
When defining our methodology, we needed to make sure that our processes were standards-based (PRINCE2 is a defensible choice) and could demonstrate the rigor expected of a publically accountable organisation. We also needed to support the Agile practices which are so well suited for handling an emergent project scope. This could not be achieved through the conventional model of a “spectrum” of software development methods, featuring as it does agility and adaptability at one end, and prescription and rigor at the other. We needed both, and not just the ability to throttle up and down the continuum. We could not accept the risk of falling between two stools, and of becoming either PINO (PRINCE2 In Name Only) or AINO (Agile In Name Only). Establishing a “balance” would be important, but it wouldn’t be enough. We needed to do both well.
We were certainly encouraged by improvements in scalability claimed by the new version of PRINCE2. This scalability allows for documentation sets to be subsumed or (rolled up) into terser artefacts, and without compromising the remit and purpose of each discrete management product. We therefore settled on a model where Agile practice is applied to an orthogonal framework of reporting arrangements and prescriptive checkpoints that support quality and project assurance.
Figure 2
Methodology development
The methodology would have to be generally applicable to all projects being run on our programme. It would also need to be customisable (or at least configurable) so as to accommodate any special cases. For example, some projects might involve significant hardware development. This indicated a need for tool support. It would not be enough just to document the methodology. It would need to be realised as a workflow management tool – ideally web based and configurable using XML – which would allow one project manager to oversee multiple projects, and which would guide stakeholders (including clients and suppliers) through the process.
The iterative portion of the project would come into play during Development when a Delivery Plan (with supporting architectural designs) is specified, and in Delivery itself when incremental releases are produced and evaluated. It would need to support discrete phases of project initiation and feasibility assessment spread over the first 2 D’s of Discovery and Definition.
We were also able to use DSDM Atern as a starting point. There was an apparent synergy between the “4 D’s” and the lifecycle phases as illustrated in the DSDM Atern Handbook. There was, of course, an impedance mismatch in the correspondences, since the “4 D’s” were notional and lacked the prescriptive detail of Atern. However, this was not a problem in so far as a rational mapping to DSDM would flesh out much needed structural detail. We settled on the following translations:
1. The Discovery Stage provides for a high level investigation of potential solutions, costs, and timeframes (including some early desk-based market research). This translates into the DSDM Atern Feasibility Phase.
Figure 3
2. The Definition Stage defines the project focus, in terms of how the technical solution should satisfy business needs. In-depth market research is used to underpin these decisions. As such this corresponds to the DSDM Atern Foundations Phase.
3. The Development Stage produces a candidate architecture from the high level requirements identified by market research, and produces a Delivery Plan. Suitable suppliers will be identified on the basis of this rubric. This translates into the DSDM Atern Exploration Phase.
4. The Delivery Stage engages suppliers who then produce the solution on a fortnighty iterative-incremental basis. This stage therefore corresponds to the DSDM Atern Engineering Phase. The risk of each stakeholder would be limited to two weeks, which is also the billing cycle.
5. For the prototyping and pilot projects that we have focused on, Deployment is usually performed as part of each incremental release. Unlike DSDM Atern it does not typically involve a separate, discrete stage.
DSDM Atern also appeared to fit the bill at the level of the micro-process. During the Delivery Stage (i.e. the Atern Engineering Phase) the project manager, client, and supplier would be involved in round-trip gestalt design. The architectural requirements identified during Development (Atern’s Exploration) cannot be frozen into a fixed vocabulary of scope. Further scope refinement and requirements discovery must be expected and supported during engineering work. The mappings we identified at the micro-level are a means of ensuring that Agile principles can be brought to bear when developing “in-the-small” and not just “in-the-large” (see Figure 4).
Figure 4
Conclusion, and next month’s article
Agile Methods are often considered to be incompatible with high levels of process rigor. This perception has been encouraged in part by a misunderstanding of the terms of the Agile Manifesto, and partly by the assumption that Agility and rigor exist at opposite ends of a methodological spectrum. Such views are commonly held by Agile supporters and detractors alike.
In the past it has proven difficult to accommodate traditional and emergent approaches simultaneously. In this article some of the technical and cultural obstacles to progress have been presented. We’ve looked at the problems that are commonly associated with the implementation of Agile Methods in prescriptive environments, and shown how DSDM Atern provides a basis for PRINCE2 integration.
Next month we will look in more detail at the remedial approach adopted by Codeworks DEV, and show how a specialised, tool-supported, configurable toolset can be used to leverage Agile Methods across multiple PRINCE2 projects at both delivery and programme levels.
References
[Barron, 2003]. Barron, Kevin, et. al. “White Paper: Using DSDM and PRINCE2”. The DSDM Consortium, 2003.
[Beck, 2001]. Beck, Kent, et. al. 2001.“Manifesto for Agile Software Development”. http://agilemanifesto.org/
[Binstock, 2009]. Binstock, Andrew. Software Development Times, 1 March 2009. “Integration Watch: The Zealots of Agile”.
[Davidson, 2008]. Davidson, Michelle. Software Quality News, 27 June 2008. “Survey: Agile interest high, but waterfall still used by many”. http://searchsoftwarequality.techtarget.com/news/article/0,289142,sid92_gci1318992,00.html
[Lacey, 2008]. Lacey, Mitch. Agile 2008 Conference. “When Working Software Is Not Enough: A Story of Project Failure”. http://www.infoq.com/presentations/A-Story-of-Project-Failure-Mitch-Lacey
[Richards, 2007]. Richards, Keith. “Agile Project Management: Running PRINCE2 projects with DSDM Atern”. The Stationery Office, London, 2007.
