Skip to content

PRINCE2 & AGILE … the philosophies

March 10, 2013

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 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


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:



From → General Techie

  1. Hakim George permalink

    You can’t compare apples and oranges (outside Ig Nobel), one is a process and you should compare it with similar processes like Kanban or even RUP where the later can be used to define processes like PRINCE within it. Agile is a practice, even SCRUM is a practice, and should apply to a component of the process, just like ESSWorks

    Yes, a major component of the submarine design is its systems whether weapons, communications, etc and large part of them are built using agile practices within MOD process guidelines. The processes are necessary here to define procedures for graceful recovery in the event of damage.

    • Yes totally agree; one is a project control framework and the other is system development life cycle (SDLC). There was a little cheeky caveat in the introduction a closer comparison would be with the waterfall model; but this blog stemmed from a comment at the training whereby it was quoted “PRINCE2 is the best way to manage software development”. Am intrigued with Kanban; have you used it; I haven’t seen many who have.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: