PRINCE2 & AGILE … the philosophies

The software perspective:

In the field of software development having worked with different teams in projects employing both these two methodologies; I thought it would be good to write a small blog on the different approaches these two techniques adopt to solve the conundrum of producing successful software.

My prospective comes from being a software developer and not the actual project manager; hence I WILL be heavily biased towards the development team.

A little background:

First off it must be pointed out that PRINCE2 is a project management framework; while agile methodologies deal more with the particle side of software life cycle; hence comparison between the two is slightly skewed pending on what you are comparing. The blog will examine at a high level the different philosophies used by each to develop software.

PRINCE2

PRINCE2 is an acronym for “PRojects IN Controlled Environments” (version 2). It is a generic project management methodology used for exercising control over a project by setting out the major components of a project. It has a definitive set of processes that should be followed and adhered accompanied by documentation.

Although it originated in IT although the current version makes no reference to IT and indeed it can be used for all sorts of projects. Heck you can even used it to plan your next shopping trip but I wouldn’t recommend it. At stated in the introduction this blog focuses on using PRINCE2 as a tool for delivering software. More can be found on PRINCE2 [Here1] [Here 2] and [Here 3]

Figure 1: Process workflow of a typical PRINCE2 project

AGILE

On the contrast agile software development refer to a group of software development methodologies principally based on iterative and incremental development. In agile, requirements and solutions evolve over time through collaboration; focus is given to frequent deployment with quick feedback loops over processes and tools such as those imposed by PRINCE projects. More can be found out about the philosophy of in the agile manifesto and other resources [Link 1] [Link2].

Figure 2: Process workflow of a typical agile project

The philosophies:

PRINCE2 takes a very process oriented approach to software development – as evidenced by the 7 processes. In many ways the conventional waterfall model is akin to this liner approach whereby components follow after another with documentation covering the each step. Therefore projects in PRINCE2 define what is to be produced before any work is performed backup by the business case.

In my view this leaner process oriented approach is indirect conflict with several key principles of agile development namely:

(1) Individuals and interactions over processes and tools

(2) Working software over comprehensive documentation

(3) Customer collaboration over contract negotiation

(4) Responding to change over following a plan

Agile methodologies emphasize on close collaboration between the development team and business experts using face-to-face communication rather than using a formal structured processes such as those employed by PRINCE2. The focus of agile techniques is on delivering frequent features that add value to the business and to provide quick feedback to on those features. There is no formal process that govern how the team operates, hence leaving the team to “self-organise” and craft the code and achieve its goals on its own. Documents aren’t created for the sake of documents.

From experience:

Creating software is dynamic and ever changing process. Quite often what you find is that end users don’t really know what they are looking for until they actually started using the product. What at the start of the project might seem as a ‘MUST HAVE’ feature might in the end up as a nice to have or even replaced by some other component altogether. Clients often don’t know what they want or need until they actually see working software.

Due to this dynamic nature of software making accurate design prediction at the start of the project becomes very hard and any predictions are usually unsurprisingly incorrect. Where the PRINCE2 approach fails in software development I believe is in the ‘big design up-front’ approach. The fact that every requirement of the system needs to be documented on the onset makes huge assumptions before any code is written. Any deviation from this original plan involves a heavy handed approach to keeping everything aligned*. PRINCE2 sees change as something to be minimised and managed rather than be recognised it as an integral part of the creative working software.

PRINCE2 approach works well if the software being developed is well define and the requirements are exact and certain not to vary widely during the project… having a processes to guide such development might not be such a bad idea. But in reality this isn’t the case; specing out the details of a complex project is very hard especially when new features and third part integration is involved.

One important point here to make is that while PRINCE2 has been applied to various industries for various size projects this cannot be said for agile progresses. (You wouldn’t build a nuclear sub on agile principles, would you?); having said that you might build a Toyota.

Due to this different philosophy these two approaches aim to tackle the creation of software in a totally different manner and at the moment I am an agilest… what’s your thought?

Welcome your comments/thoughts/improvements 

Also look at:

ITIL, DSDM,   RUP, SSADM, PMP