PRINCE2 and Agility: Reclaiming the Manifesto

In October this year Codeworks DEV received the 2010 Agile Award for the “Best Use of Agile in the Public Sector”. The use of Agile Methods within large, publically accountable environments has long represented a challenge to the Agile community. Agility is more often associated with small to medium size enterprises (SME’s) in the private sector, where organisations are incentivised to keep pace with a changing business environment. Public sector companies and larger corporates, on the other hand, are renowned for their essentially prescriptive, “non-agile” attempts at long-term planning using techniques such as PRINCE2.

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


About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!