PRINCE2 terminology can be a real bugbear for agile practitioners; they see it as being too prescriptive and inflexible. However, there are many PRINCE2 terms that reflect agile approaches.
Here, we provide one example from each of the five PRINCE2 elements:
1. Initiation: A PRINCE2 stage
PRINCE2 projects revolve around the business case for justification, the various plans that design what will happen, the funding required to deliver to plan and the project controls and the delivery strategies to be employed, all of which is decided during the initiation stage.
From an agile perspective the business case would articulate the mandatory requirements for the project and the project level planning would focus on feature sets and intended product releases. The project management/delivery approach may mandate specific agile approaches such as Scrum, Kanban, self-organizing teams and decentralized control and decision-making. Plans may be time boxed and not flow-based and project funding may be based on releases (packages of business value) rather than technical stages of delivery effort.
The Project Product Description is likely to be outcome based as opposed to a specific, defined solution and the Benefits Review Plan is likely to focus on value delivery as early as possible – efficient time-to-market enabling end users to leverage the valuable components made available to them as early as possible.
2. A work package: A PRINCE2 product
A key agile concept or foundation is self-organizing teams that are responsive to change. However, to do that, the team needs to be organized within well-understood boundaries and ensure certain aspects of a project are delivered. The PRINCE2 work package, although seemingly prescriptive to agile practitioners, enables them to organize in this way:
- Build accurate products for customers – while agile focuses on what the customer wants from a product, PRINCE2 focuses more on the details required to build the product. For example, a Smartphone: an agile approach may deliver the phone as soon as it functioned with ‘minimal viable’ functionality (apps). Various other add-ons that enhance the experience, (other apps) could be delivered later. It’s about realizing value as quickly as possible.
- A work package enables practitioners to understand clearly the quality criteria and can efficiently meet the minimum quality requirements agreed by prioritizing these when building the product.
- Work packages also enable agile practitioners to clearly define stakeholders, their roles, responsibilities and authority to enable the team to focus on building the products/delivering the services of value.
3. Planning: A PRINCE2 theme
Although not necessarily well-known, agile emphasizes planning, specifically around requirements and features of products as opposed to technical phases of delivery associated with traditional approaches.
In agile, the Project Manager is responsible for compiling the plan but the team undertaking the project itself is responsible for the specific components of that plan. This approach ensures everyone involved has a commitment to and ownership of the plan. If you are involved in the planning and you don’t agree with something you are accountable to challenge and ensure an appropriate, feasible and desirable plan resides as an output of the planning activity.
Planning is left as late as possible, not to put unnecessary pressure on teams but to enable other actions and processes before planning to provide optimized inputs so that planning is most effective and organized. The focus is on flexibility and the drive to deliver maximum value based on real world inputs and results.
4. Continued business justification: A PRINCE2 principle
The agile approach has a definite focus on value, whereas PRINCE2 focuses on benefits. The difference is “value” indicates something with economic or financial benefit but a “benefit” may not necessarily be of financial value.
Agile applications would focus on the rationale for a minimal viable product (MVP) as opposed to a detailed articulation of every product. Applying constructs such as daily stand-up meetings and retrospectives means that lessons learnt are not just compiled at the end of a stage or project itself, they’re “baked-in” to the current project near real-time to realize value of such fast feedback mechanisms: produce MVP product, obtain feedback, adjust, deliver the value and repeat.
5. Tolerances: A PRINCE2 technique
PRINCE2 sets tolerance to control Project Manager variance from agreed estimates in terms of time, cost, risk, benefit or scope. Where such thresholds are, or look like being breached, it is incumbent upon the Project Manager to escalate to the Project Board for formal change control and decision making. In a similar way, agile uses prioritization approaches such as MoSCoW re scope to ensure the project remains within the set time and budget allocated. Product features are prioritized in this way, dependent on time, money and end user assigned business value.
The same can be said for quality; a focus on MVP and not a detailed breakdown of every quality attribute and budget, which is set against prioritized features (that drive business value) and not budgets required to complete a defined stage of work. By way of example, take the building of a car, more traditional approaches may involve big design up front (BDUF) whereas an agile approach would focus on the MVP – comprising a chassis, engine, body, breaking system and seats, etc. with features such as air conditioning and polished wood interior surfaces being “nice to have” features which could be included if time allowed, the cost - benefit - utility ratio were favourable and no other higher priority features were deemed urgent.
PRINCE2 looks at the project, decides the tasks required and the budget allocated to it then the scope is decided and will/can change as the project is carried out. Agile takes it from the other direction: the project is going to be 10 months long and in that time the customer requires as a minimum “A, B and D”; if time permits, “C” would be nice to have.
Have you managed projects using PRINCE2 and found that, as Darren suggest in this blog, some of the techniques and terms in the methodology are also common to agile methods? Are there other aspects of PRINCE2 that you think are also agile? Or areas of agile that could be part of PRINCE2? Please share your thoughts and experiences in the comments box below.
See our sections on PRINCE2® and PRINCE2 Agile™ for more information.