PRINCE2 and Agile
Please note that this is a repost from 2012 (which I still find relevant).
My mind got triggered on the ever ongoing discussion of 'PRINCE2® versus Agile' and how these approaches can, or cannot (which is what most people argue), work together. In my opinion, there is no 'versus' here, just a matter of tailoring to achieve a common goal.
To me, what PRINCE2® provides on top of Agile Product Development ideas like Kanban and SCRUM is clarity (I will not go into DSDM here, since it's already well integrated with PRINCE2).
Overall, PRINCE2 describes 3 levels in the project lifecycle: Directing, Managing and Delivering.
Where Kanban or SCRUM fits in from a PRINCE2 perspective is the Delivering level. This is the domain of the team (which may be working in a SCRUM or Kanban context) and this is where products are produced, in the Managing Product Delivery proces.
In PRINCE2 (remember the generic approach) work for teams or project resources is issued or sanctioned through the use of Work Packages. Basically, Work Packages are what you in the Agile world would call agreements on Iterations or Sprints; a defined period of time with a definite start and end, containing a set amount of hours for development (capacity) on specific products (ie. sprint goals), with set agreements on escalation and communication (how to handle impediments, SCRUMs or stand up meetings) and tolerance on the delivery scope (adding or removing Backlog Items during a Sprint).
In a complex project, the PM might have more than one team doing development, and they may even be distributed among several suppliers. It's very important to stress here, that the Release or Iteration planning is not something the PM does all by himself with a good bottle of Chianti, isolated in his own little bell (just because it's a more traditional project management approach, doesn't mean there's no communication or cooperation). Any sort of valid planning requires information and thus also the informed resources.
Artefacts
PRINCE2 uses Product Descriptions to describe products (project deliverables) and these may take many forms, but in essence they capture the needs stated by the business and the matching requirements for quality. For those of you with Agile experience, seeking to equal the product description with a User Story, my recommendation is to use Product Descriptions solely to capture the business needs at an overall level; entire modules in a system, a batch of common business processes etc.
Product Descriptions are great for communication with stakeholders as well as the project board, but should not take over the roles of User Stories, Use Cases or Requirement Specifications; they are more abstract and high level, written in a language the business understands. So an Agile team could simply map their various User Stories to the relevant Product Descriptions to keep the context clear.
All of this is necessary since PRINCE2, being a generic method for project delivery, does not contain specific business domain methodology or controls. This actually necessitates that the organization, in an IT business domain context, already knows how to work with product delivery at team level, applying User Stories, Use Cases and Business Process Flows as required. Of course, this all depends on your evaluation of, how artifact heavy the project should be.
Simply put, PRINCE2 cannot replace SCRUM or Kanban approaches in an IT context, but is actually dependent on such an approach to exist and be agreed upon at the Delivering (team) level.
The best of both worlds
In other words, there is no knowledge in PRINCE2 about software development or how teams should produce good quality software. PRINCE2 does not require process/plan-driven software development methods to be used, just as it does not require you to develop software based on agile principles. It can support both, through the proper tailoring.
What PRINCE2 does provide, is the surrounding governance framework of the project, examplified by the 7 principles:
- Continued business justification embodied by the Business Case and the overall measurement of Benefit, Cost and Risk associated with the project; if value is not possible to achieve, we have no project
- Learning from experience facilitates continuous improvement and is aimed at anchoring and communicating experience in the organisation, from project board to team manager
- Defined roles and responsibilities ensure that the business, user and supplier stakeholder interests are all represented in the direction of the project
- Manage by stages to ensure that overall expenditure is in balance with the actual benefits of the project as well as to secure corporate funding to support the resources required, one stage at a time
- Manage by exception empowers the different levels of the project life-cycle, from Directing to Management and Delivering by setting tolerances on performance targets (time, cost, quality, scope, risk and benefits)
- Focus on products and the quality required to deliver the value that is necessary to realize the project benefits
- Tailored to the project environment to ensure that the project management is productive and effective; using PRINCE2 rigidly as a good robot will inevitably fail, use it too lightly (PINO - PRINCE2 In Name Only) and you are likely to forfeit the benefits at Directing and Management level
Answering Questions
The bottom line is, that by following the PRINCE2 principles, the aim is to have overall project clarity and by this try to answer some very important (and common project management questions):
- Is the project aligned with the organizations strategic goals?
- In light of the risks, does the benefits outweigh the costs?
- Do we have the necessary involvement and commitment from the corporate or portfolio management?
- Is the Project Board of the right size and of the right organisational 'weight' to be able to commit resources and top level requirements for the project?
- Are the resources and competencies required to complete the project, and to incorporate the project results in a BAU scenario, available?
Another point to remember when discussing IT projects is that not all products or deliverables in an IT project are created by software developers. This includes among other things:
- Outsourcing arrangements and contracts
- Implementation of updated busines processes and workflows with users
- Business transformation activities leading to a successfull implementation of products in the business
- Training documentation, course materials and user training workshops
- Marketing & sales material
In such projects, project management must necessarily cover all deliverables (and so must the Business Case) and this should not, due to principle alone, be crammed into an Agile software product development workflow. At the same time, the creative process at team level must be protected and not forced into a rigid waterfall approach that will inevitably fail to deliver value. The right method and tool for the right job in both respects.
By using Kanban, SCRUM or other Agile approaches at the team level, the aim is to make product delivery (productivity) as efficient as possible:
- By establishing an efficient and adaptive self-managing team
- By limiting work in progress and focusing on completing work regularly
- By optimizing the value streams and creating flow, thereby highlighting bottlenecks in the production of software products
- By bringing together business knowledge, development competencies and quality assurance in tight cooperation
Many studies show that Agile is one of the primary ways to develop software products today; in many ways, we've come a long way since the days where software was produced with the same engineering mentality that goes into building bridges, tankers or large office buildings. Put simply, the environments for most software projects today, are soaked in uncertainty and business requirements that constantly shift.
Toyota and Lean has shown that there is a way to produce quality and value for customers (internal or external), which also suits the typically change prone environments where many IT products are delivered.
The Gist
What many organizations I've come across in IT contexts tend to focus too little on, is how to merge PRINCE2 and Agile principles so that they, holistically, achieve a project execution environment that does not sacrifice clarity for efficiency, or vice versa. There needs to be a clear line from the principles driving the project board, to the team(s) delivering the actual products. This is not to say that the project management may not also be inspired by lean thinking, by all means, I cannot see this as a bad idea, but solely focusing on product development will make some of the more general (but still important questions) go unanswered.
In other words, project management must create the structure and foundation (clarity) that enables the specialist teams to deliver the highest quality products with the most value(effectiveness), which enables the organization to accomplish the business strategy.
So to me, Agile and PRINCE2 can and should work together in IT projects in this day and age.
The picture introducing this post was chosen due to it's portrayal of how artists mix and match color as the painting and palette takes form. And so should our mix'n'match of methodology be focused on what creates value in a given context, not on driving forth one ideology in favor of another.
