Agile verses PRINCE2 - a new species in evolution

"PRINCE2 verses Agile - As Two Worlds Collide" (The Genesis Of A New Species?) 

Like a lion and a tiger pacing each other while quietly noting the other's positive attributes. What's it to be then? A Liger or a Tion?

Who cares frankly, two magnificent creatures of practical evolution. If Agile and PRINCE2 could be designed as a unified framework solution to any project should we call it PRAGILE or AGINCE2?

What nonsense - Vive La Difference say I...

Am I the only voice that says adapt and tailor? Blending both PRINCE2 and Agile while watering neither down seems to have superb potential for the world of projects.

This is a big topic and this blog is just going to scratch the surface, but if this gives a few of my readers food for thought of blending possibilities...

Like the lion and the tiger, I am going to write about the bountiful benefits each brings to the table - the 12 Agile Principles and the 7 PRINCE2 Principles, so I'll blend from the perspective of Agile:

1. Agile states that customer satisfaction is increased by swift requirement gathering coupled with feedback in a short timeframe.

PRINCE2 defines roles and responsibilities pre-project with a focus on the customer/supplier environment. It sets up the project management team ensuring representation from the customer/user/supplier sides and actively involves the specialist team in bottom up planning. Translating requirements into agreed deliverables is key here, and the product-based planning techniques will get the job done fast! It also facilitates the breaking down of the project into manageable stages with the focus on products (=deliverables) and their quality criteria to test completion. Further, each stage is planned down to work package level so such packages aid Agile's continuous and swift delivery principle.

2. Agile welcomes changing requirements at any development point with a focus on the customer's competitive advantage.

A marriage made in heaven for PRINCE2 via its Change Theme. It has a structured approach to any proposed change, and can be used at any point in the project. As part of this approach the impact of the proposed change is assessed using 6 performance aspects that include customer benefits (read customer's competitive advantage), time and cost, etc. A series of options are developed all of this with close consultation with the customer. This aids a swift and focused decision-made by considering the project and customer priorities.

3. Deliver working software frequently and in the shortest timescale possible.

PRINCE2 manage by stages principle again. A Stage time frame and/or work package can be as short as you like, including the degree of formality used  - right down to coffee machine chats and decisions if you wish. PRINCE2 readily adapts for spiral or waterfall development models, wher each 'spiral' can be at product, work package, or stage level. The important fact here is that each stage will have a plan that is created with bottom-up design and collaboration between the customer and the project team. SCRUM sprints and PRINCE2 plans/work packages/products fit hand-in-glove.

4. Business people and developers work together daily.

This is all about communication and Agile nails it! PRINCE2 with representatives of both customer and supplier direction aids this mindset. The Business Case can be as simple as the reasons and benefits, and this can be created by the project manager ensuring close agreement down at the important development/specialist team level. PRINCE2 has a document that is created prior to the project plan called the Communication Management Strategy, never mind the big words here - the intent is to define HOW we will communicate. The Agile principle plugs straight in!

5. Build projects around motivated individuals. Building a supportive and motivated environment.

PRINCE2 states that it does not define the 'soft skills' of management and teams because it is a flexible 'framework' suitable for any type of project in any industry, so I agree that this Agile principle would drive the tailoring of PRINCE2. But don't forget the Roles and Responsibilities principle here. Tailoring this to meet Agile seems a straight-line fit to me. Tailor the roles and responsibilities to allow individuals to thrive, apply the principle of business justification to allow them to do the right thing, set clear tolerances so the team has clarity about their role/responsibility scope so they know when to escalate (the manage by exception principle). Teams are motivated by clarity, and the PRINCE2 Product Description with the unambiguous quality criteria will give the developers the inspiration to thrive.

6. Convey information with face-to-face conversation. This points to Agile bullpens utilizing maximized co-location.

Back to PRINCE2's Communication Management Strategy again...defining the 'how will we communicate' plus the defined roles and responsibilities. It sets out the who, how and when for face-to-face conversation (=communication). Add to this the PRINCE2 defined Work Packages containing product and criteria ownership, and you have a recipe for refining and clarifying face-to-face conversations.

7. Working software is the primary measure of progress. Agile must have read the PRINCE2 Manual and recognised best practice when they saw it.

PRINCE2 clarifies the deadly difference between completing the 'work' - verses a completed and acceptable product (= anything that the project produces = deliverable). In PRINCE2, a product can never be ultimately  '90% done'. Product completion is a binary decision. It's either complete becasue it has passed the quality criteria AND been approved by the appropriate named individual - or it's still 'work in progress'. It also applies the principle of focus on products. PRINCE2 actively involves the customer/users in the drafting of each product description along with its quality criteria, method, and responsibilities (including who will authorise its completion). Agile and PRINCE2 are already the best of friends...

8. Maintain an indefinite constant pace. An inscrutable principle for sure, yet we all know it makes a whole bunch of sense!

I'll approach this from a very general PRINCE2 approach. You see, I don't think Agile is recommending exhausting the team, nor being a monkey on their backs measuring productivity and effectivity. It is the total Framework of PRINCE2 that aids Agile in this respect. Once you understand how the 7 PRINCE2 processes are tools to tailor, then you begin to see that they are a recipe to harness efficient work structure and pace within a project's timeframe. PRINCE2 plans only contain activities that are directly related to the creation of quality products. When you understand that the 7 PRINCE2 Themes (see them as approaches that are to be embedded within each process if you like), are there to aid flexible and timely decision-making and that these drive the project in a lively and controlled fashion through its stages/phases. PRINCE2's product-based planning leads to more realistic estimating, which in turn gives rise to challenging but achievable project schedules.

9. Give continuous attention to technical excellence. 

Another PRINCE2 and Agile hand-in-glove fit. The PRINCE2 Quality and Change Themes sings this song loud and proud.

PRINCE2's Quality theme ensures that delivered products meet specific and measurable standards. See this as Agile's working code. If a product needs rework because it did not meet the standards, then the Agile team has the focus on fixing it, or if needed, applying PRINCE2's flexible, timely, and structured approach to change. Job Done!

10. Simplify - maximize the amount of work not done. Agile advocates simple design. An interesting Agile way of saying only do the work required to deliver acceptable products (and that must include management aspects too). I also teach PMBOK and that states a similar aspect in terms of 'no gold-plating'. But back to PRINCE2...

The PRINCE2 method states that it should be applied with a lightness of touch. The chapter on tailoring PRINCE2 to the project environment speaks Agile's language here, stating that the method should be tailored on a 'fit-for-purpose' basis. Each project should be tailored with due consideration to it's size, risk, complexity and importance. Again, I must mention PRINCE2's product-based planning technique here. It's a masterstroke in supporting this Agile principle - by first identifying the products to be created along with their quality criteria, and only then, identifying the activities needed to create those products. In a stroke, redundant work activities are shut out.

11. Teams self-organize. I admire the guts of whoever evolved this Agile principle. But again, it's on the money for maximizing team cohesion and effectivity.

I guess the point I'm making that the team needs a scope zone around them if they are to be empowered. I'll mention again the PRINCE2 approach to team work with agreed roles and responsibilities, and the use of customer/user/supplier involvement in planning along with the management by exception principle. Tolerance is then given/set for the project manager who is now free to manage within a given management stage. Tolerance can be set at work package level to allow the specialist team to do their job independently. In the working sprit of Agile, a work package is a licence to 'just do it' In each case these are a 'contract' of understanding. Regular checkpoint reports (at face-to-face conversational level) allows the project manager to manage with getting in the way of team excellence.

PRINCE2 also has a powerful Progress Theme, which sets up a monitoring and control framework. Unite this with the PRINCE2 risk and issue management aspects and you have a structure for a self-organizing team.

12. Teams retrospect and tune their behaviours. This is all about becoming more effective - who couldn't agree with that?

Starting pre-project, PRINCE2 ensures that lessons from previous/similar projects are proactively sought out and captured in a log/register. This is used throught the project and such lessons applied as needed in a continuous fashion. It follows the principle of Learn From Experience, and is big on not repeating mistakes nor inefficiencies from previous endeavours. These lessons form the basis for all PRINCE2 strategies and plans. Throughout, including each stage end, lessons are considered for incorporating in the remainder of the project, and such lessons are captured in a Lessons Report at the end of the project for use on appropriate future projects. Perfect for learning organizations.

Prologue.

Is the world a better place yet? So how did we do? If I've given food for thought as to how both Agile and PRINCE2 advocates can form an alliance by blending the best of both worlds - then we will have avoided a collision and potential fracturing of two great project methodologies.

So we still have lions and tigers, but at least they're hanging out together and respecting each others company! When you celebrate our common goals and objectives, it gives us a vision of how we can harmonize the differences.

This story is only at the end of the beginning.