Is PRINCE2 still relevant in an agile world? Or like in the fairy-tale, has it lost its relevance and changed into a frog? Well, no… it is still very relevant for two reasons:
PRINCE2 is not the only option when considering a traditional methodology but it is a popular one and one that blends in well with new Agile project methodologies such as the Agile project management framework which is derived from DSDM.
PRINCE2 is a formal, structured approach to project management. It recognises that there are three major levels of activities:
The major focus of PRINCE 2 is in management and direction. Delivery it treats as a black box because it may be internal or external. Prince2 does not dictate how delivery is done but it does state the expected communication and deliverables.
A PRINCE2 project looks like the following:
In fact, the 2009 revision to PRINCE2 reiterated its underlying simplicity by recognising explicitly seven principles:
It doesn’t say anything about how you should build your products.The only things PRINCE2 says about making things is the following:
PRINCE2 can be used to manage the project and Agile methods can be used to deliver the solution. The two methods are entirely complementary; they touch only in the definition of what constitutes a “workpackage” – and they even agree on how big that should be!
A paper on integrating DSDM and PRINCE2 is on the DSDM website. Another option is to use PRINCE2 for direction and use an agile Project management methodology and solution delivery. Agile Project Management is an initiative which extracts the Project Management elements of DSDM Atern and makes them available as Agile Project Management – a certified approach in its own right. This can then be combined with popular Agile solution delivery approaches such as Scrum and XP. This is detailed in this Agile Proect Framework for Scrum document.
In some cases the requirement may be to go completely Agile. This is possible as long as the direction provided is agreed and sufficient for the company leaderhip. Agile Project Management derived from DSDM (Shown in next 2 diagrams) or Disciplined Agile Delivery (Shown in bottom diagram )may be used.
In managing a project to develop and deliver a product the traditional way of delivery are methods such as PRINCE2 (PRojects IN Controlled Environments) which is a widely used project management method that provides all of the essentials for running a successful project. It is sequential in that one task is finished before the next starts and the product is delivered at the end and is managed by a plan. Traditional plan based sequential methods are known as generically as “Waterfall”.
A new way of developing and delivering products is Agile. It is a term commonly associated with software development. The Agile Manifesto was published in 2001, building on work throughout the 1990s, which summarised the core philosophy behind agile development philosophies. This consists of 4 key values and 12 principles.
“We are uncovering better ways of developing software by doing it and helping others do it.Through this work we have come to value:
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 planThat is, while there is value in the items on the right, we value the items on the left more”.
Agile started out improving software development but the term Agile has evolved into an umbrella for a group of methodologies that can be used to manage business change projects. Agile delivery teams will develop a project :
It is worth noting that Agile, recently, has had a good press and Waterfall a bit of a poor one. However, both have value and can be utilised depending on the problem to be solved. A methodology does not make up for bad management or unreasonable constraints or criteria for success.
Three of the major Agile approaches are Scrum, XP and DSDM:
One of the major developments in thinking in Agile has been a to re-evaluate what should be done in situations where all criteria of success cannot be achieved and trade-offs have to be made – when something’s gotta give:
Traditionally the scope or features remained fixed with time, cost and possibly quality having to flex. In Agile time, cost and quality are fixed and features are flexed. Hopefully to be included in a later iteration. The breakthrough in thinking is that in many developments, too much time is spent upfront, planning and designing based on imperfect or no information, based on what customers think they want, based on technology that is changing. The Agile approach recognizes an imperfect world and tries to adapts to it in the most pragmatic way. This will not work in all circumstances. I’m sure we have all won customer contracts that include developments that are very uncertain but “cast iron” promises have been made to customers on price, on time, on features and on quality. But as I said earlier, good tools don’t make up for bad circumstances or bad management.
This approach of developing in fixed time cost increments with usable releases at the end of each increment getting customer feedback on working software (service, product) can reduce risk, reduce cost, improve quality and be more adaptable to change. It is a seductive and compelling argument. That and the name Agile (who does not want to be agile?) has meant that Agile has become a meme that is having an increasing impact. It has become about values and behaviours, more about being agile than doing a specific Agile methodology. This is sometimes dangerous as it means that conversations can become confusing especially as media and companies will use the term agile to increase hits or attract attention. But its always the way with ideas whose time have come, that have crossed the chasm and are ripping through the rest of the market.
Scrum is the most popular approach for team management at the product delivery level. Data from Forrester’s Q3 2013 Global Agile Software Application Development Online Survey indicates that a whopping 90% of all teams practicing Agile development have adopted Scrum.
User stories in the form of “As a <type of user>, I want <some goal> so that <some reason>” are used to create individual requirements that go into a product backlog that is prioritised by value. Those that are committed to be delivered in the iteration or next development cycle called a sprint are put into the Sprint backlog. Sprints can be from 1 week to a month depending on the development environment.
Daily scrum meetings are stand-up for 15 minutes where progress is monitored, commitments made and impediments aired.
There are weekly planning and review meetings . Artifacts are light and include the product backlog (requirements), sprint backlog ( deliverables in this sprint), burndown charts (a monitor of value delivered and sprint velocity).
A comparison of Waterfall and Agile is shown below. Please note that either tool in the wrong hands can deliver poor results and in the right hands can deliver excellent results. It’s a matter of choosing the right tool for the job.
Attribute | Waterfall | Agile |
Communication Bias | Written | Face-to-Face Conversation |
Artifacts & Ceremonies | Heavier | Lighter |
Documentation | Heavier | Lighter |
Customer Relationship | Negotiation | Collaboration |
Change | Costly- Control | Less Costly-Welcomed |
Risk through project | Risky till end | Risk decreases throughout |
Management | Command&Control | Trust to Self Organize |
Prioritisation | By Plan | By Value |
Delivery | At end or large increments | In smaller increments |
Design & Planning | Mostly Upfront | Minimal Upfront&Throughout |
When Something's Gotta Give | Time&Cost | Scope or Features |
Strength | Large Scale Projects | Innovative software development |
Questions | Stifle Innovation? | Corporate Governance and Project Management? |
Team Size | All Sizes | Optimally Smaller |
Team Location | All Locations | Optimally Co-Located |
Predictability | Can be more | Can Be less |
Learn and Improve | Yes | Yes |