I was recently asked whether Agile methodologies are contradictory to the PRINCE2 methodology. I can see why people may think this, but the question itself is confused. PRINCE2 with Agile is not the correct comparison to make; Waterfall and Agile maybe. In actual fact, PRINCE2 and Agile are complimentary.
PRINCE2 & Waterfall:
PRINCE and PRINCE2 were developed by the OGC (It is now run by the ILX Group) to provide governance for UK Government projects predominantly in IT.
Courtesy of Silicon Beach Training
During the 1990’s the de-facto methodology for large governmental software delivery was Waterfall. Waterfall followed specific stages where one stage had to be completed before another stage could begin. It is similar to “Stage-Gating” – a process which exists in PRINCE2 where you cannot proceed to the next stage until certain criteria have been met.
Waterfall model” by Peter Kemp / Paul Smith
The above is one example of how the two methodologies appeared entwined in the process for more than 15 years. As a result, people began to think PRINCE2 and Waterfall were pretty much the same things. They are not. The waterfall is a software development methodology that is all. PRINCE2 is a project methodology within which one or multiple discipline methodologies can exist to complete the project’s finite requirements.
A prime example would be delivering a product to the marketplace. Both a Product Management methodology and a Software Development Methodology can co-exist to deliver the project.
PRINCE2 and Waterfall were predominantly used to deliver traditional Client-Server architecture’s. This architecture began to be overtaken by the need to deliver permanently online models to serve the increasing demand for productive use over the internet. The talk was of the death of the Client-Server model.
Whilst exaggerated, the rise of rapid application development increased the velocity in understanding how to deliver software products successfully. Only they weren’t successful, the vast majority of software development projects fail.
The term ‘failure breeds success‘ is evident in IT as it led to the refinement/evolution of the ‘Waterfall‘ model into a newer methodology called ‘Agile‘.
PRINCE2 & Agile:
Agile software development is a collection of methodologies where the core principle is about continuous integration. It is about breaking down the requirement into its simplest form and just developing that feature. Once developed, release it, gain feedback and refine. A continuous cycle where the focus is on continuous success in small pieces, and not one large delivery where the feedback and refine cycles take prohibitively long to manifest.
PRINCE2 is also about understanding what the requirement is and breaking it down into smaller product parts until it cannot be broken down anymore. This is called the Product Breakdown Structure. This is no different to Agile’s view of modelling. Both require you to create models which clearly define the parts which successfully create the solution.
Waterfall vs. Agile:
Agile has taken the core learnings from the failures of Waterfall to ensure software development does not cause the costly mistakes exhibited by large Government projects during the 1990s and early 2000s.
The simplest way to explain this is in relation to a product. Breaking a product down into its simplest parts is the same as creating a series of feature requests for a product. The waterfall model will require you to take ALL of the feature requests in one go and take them through each stage ONE at a time. The Agile model will require you to take ONE of the feature requests and take it through ALL of the stages in one go. The statement above is highly simplified, but hopefully,
it gets the point across.
Courtesy of Agile Enterprises
Converting from Waterfall to Agile within PRINCE2:
Smaller teams utilising Agile help to deliver more successfully than larger teams using Waterfall. Larger Enterprises tended to throw investment in the belief bigger teams will deliver larger software instances more quickly. This is not the case and significant investment wasted through a series of well-documented failures.
Instead, a larger project delivery should be split up into smaller finite projects, with smaller teams delivering to a set purpose. Carrying out a programme of work in this way leads to greater control, understanding, communication, feedback and ultimately a more successful project.
When this occurs, by definition you adhering to PRINCE2 guidelines by breaking the project down into smaller product parts for delivery. For a larger project which may require multiple systems to integrate with one another to achieve an overall solution, each product may be considered to be the system which needs integrating.
For each of these products they can be broken down further into smaller product parts. These smaller product parts will be a series of features which are required to deliver the successful solution. These features create what agile terms, the ‘product backlog’.
The ‘product backlog’ can be delivered through a series of smaller development teams devoted to the product. Instead of having one large team delivering all products, have a small team per product, devoted to delivering the product backlog for that product.
Each development team will have a series of SPRINTS to deliver the end goal. The team is managed through the SPRINTS to deliver the product backlog. It may not be known how to get to the end goal initially, but by the end, the result will be realised through the continuous development process occurring. Each SPRINT provides a continuous feedback loop into the product backlog to ensure all features necessary to deliver the strategic objective will be delivered. This can make forecasting overall cost of development difficult. As a result, it is perhaps wise to take a conservative 60/40 rule. 60% is known up front, 40% will be through additional unforeseen development to reach the end goal. It will depend how strict your quality expectations will be.
Managing Successful Programmes (MSP):
A programme is collection of projects with a common purpose. This is different to portfolio management. Portfolio management relates to the management of a collection of projects which exist within an environment with differing objectives. What has been described above is a series of projects (products) using a PRINCE2 framework and an Agile implementation methodology to deliver a successful solution.
Take a look at the MSP Lifecycle. The bit in the middle looks very similar to a formalised SCRUM lifecycle. SCRUM is an iterative and incremental agile software development framework for managing product development. The ‘Product Backlog’ in SCRUM is the same as ‘Identifying a Programme’ in MSP; the ‘Sprint Backlog’ in SCRUM is the same as ‘Defining a Programme’ in MSP; the ‘Sprint’ in SCRUM is the same as ‘Managing the Tranches’ in MSP; and the ‘Product’ in SCRUM is the same as ‘Closing the Programme’ in MSP.
The synergy between methodologies is evident. In a simplistic sense, it is merely terminology differences. It just depends upon what context you look at it. The reason why SCRUM has so many advocates in the business world is because of its scalability, it is able to match the controls of larger programmes of work whilst keeping focused on delivering the small things correctly.
My point?
Both can co-exist in harmony because both frameworks look to achieve the same thing. It is the context in which you look at creating your environment which will preclude the probability of your projects’ success. Remember, PRINCE stands for “Projects in Controlled Environments”, create the correct controlled environment and your project(s) however small or large, will succeed.