June 2015

PRINCE2 Agile Health Check

Appendix C of the PRINCE2 Agile Guide contains a checklist that can be used at any time during a project to assess how well the project is going from an agile perspective.
In fact I recommend that you read these pages to get a better understanding of PRINCE2 before starting to read the rest of the manual and it provides an excellent summary of what is important to get right when implementing and running PRINCE2 Agile.

Note: This is not a replace for the PRINCE2 Checklist

You can just use a simple Yes or No when answering the questions and then will then provide you with a general overview of the health of the project in Agile Terms.



C.1.1 Behaviors
1. Collaboration, trust and a no-blame culture exist.
2. Self-organization is predominant and is supported by the project management team. There is a culture of inspect and adapt and continual improvement.
3. Transparency prevails.
4. Teams are regularly talking about the delivery of value and benefits.
5. There is an attitude of keeping things simple.
6. All stakeholders impacted by the project are being kept up to date.
7. The product board is frequently interacting with the people involved on the project. Planning and work assignment are being carried out collaboratively.
8. The Pastor of Fun is well-organized.

C.1.2 Environment
1. People are happy and work is enjoyable.
2. The team is stable, ring-fenced and working well together.
3. The project is responsive to change and is change friendly.
4. The customer is involved and engaged at all levels.
5. A blended view prevails that takes into account the diverse views of the customer on a project.
6. The desired outcome, as well as the desired output, is clear to everyone.
7. There is a thirst for feedback and a collective desire to find out what the customer really wants.
8. Agile learning’s are being moved around the organization (e.g. by project support).
9. Communication is very good and fast-moving.
10. Control has a light touch and people are empowered.
11. Musts really are musts.
12. The project management team and the delivery teams are ‘understanding agile’ and not just ‘doing agile’.
13. The overriding mind-set of the people on the project is an agile one.
14. Frequent releases are happening that are ideally put into operational use (or a staging area if the live environment is not ready).
15. The five targets of what to fix and what to flex are understood by all.
16. Significant events become routine because they happen frequently (e.g. stage boundaries or release reviews).
17. All roles are clearly defined and understood (and this is taking into account that the mapping of the agile roles to PRINCE2 is not necessarily straightforward).
18. PRINCE2 is seen as agile.

C.1.3 Process
1. Management by exception is working fully.
2. The level of control is appropriate to the level of uncertainty.
3. The work package interface is happening well. It is smooth, has clarity and is not a source of communication problems.
4. Requirements and user stories are explored and not just followed blindly.
5. The way of working is typically iterative and incremental, and benefits are being delivered at several points throughout the project.
6. There are clear definitions of ‘done’ and ‘ready’, and working agreements are transparent.
7. Planning and work are feature-focused and timeboxed.
8. The MVP is clear to everyone, and it is understood that its role on the project is to help with learning.
9. Quality checking and testing includes independent quality checking and testing.
10. Quality checking is happening as you go and sometimes even drives the building of the products.
11. Planning is happening well in relation to all planning horizons (i.e. short term, medium term and long term) and with respect to the appropriate level of uncertainty.
12. A lot of planning is being done empirically.
13. Early requirements are based at a level that avoids unnecessary detail. Project assurance is adding value from an agile perspective.

C.1.4 Techniques
1. Prioritization is happening continually, and timeboxes are not being extended or having people added to them. Information is very visible (e.g. on the walls) and is kept up to date.
2. When prioritizing, teams are looking at both scope and quality criteria.
3. Acceptance criteria always exist and are well written.
4. Estimation is a team-based activity.
5. Documentation is Lean, and the right channels are being used for each type of message.
6. Demos take place frequently.
7. Some risks are being mitigated by the use of spikes, prototypes and experiments.
8. Burn charts are being widely used and progress is clear to see.
9. User stories are being used to stimulate conversation and communication.
10. When Kanban is used, a holistic approach is adopted – not just a Kanban board.
11. Workshops are a regular occurrence and are being used appropriately.
12. Stand-ups are happening daily and are taking place quickly (i.e. lasting 15 minutes or less, perhaps 10). People are clear on terms like ‘requirement’, ‘user story’, ‘feature’ and ‘epic’.
13. Product descriptions have been written at the appropriate level and with flexibility as to quality criteria.

Why this blog post on the Cynefin framework?
The Cynefin framework is included in the PRINCE2 Agile Guide

What does the word ”Cynefin” mean?
The word “Cynefin”, pronounced ki-neh-vin, is a Welsh word meaning something like ‘habitat’ or ‘place’. The term was chosen by the Dave Snowdon to describe a perspective on the evolutionary nature of complex systems, including their inherent uncertainty

Origins of Cynefin
Cynefin was first developed by Dave Snowden in 1999 in the context of knowledge management and organisational strategy.

What is Cynefin?
Cynefin is a decision framework that recognises the causal differences that exist between different types of systems, proposing new approaches to decision making in complex social environments. Cynefin is also a sense-making model, not a categorisation model.

In a categorisation model, the framework precedes the data. This is good for exploitation but not exploration. In a sense-making model the data precedes the framework, making it good for exploration

PRINCE2 Agile Cynefin

PRINCE2 Agile Cynefin

The Cynefin framework has five domains. The first four domains are:

1) Simple, in which the relationship between cause and effect is obvious to all, the approach is to Sense – Categorise – Respond and we can apply best practice.

2) Complicated, in which the relationship between cause and effect requires analysis or some other form of investigation and/or the application of expert knowledge, the approach is to Sense – Analyze – Respond and we can apply good practice.

3) Complex, in which the relationship between cause and effect can only be perceived in retrospect, but not in advance, the approach is to Probe – Sense – Respond and we can sense emergent

4) Chaotic, in which there is no relationship between cause and effect at systems level, the approach is to Act – Sense – Respond and we can discover novel practice.

The fifth domain is Disorder, which is the state of not knowing what type of causality exists, in which state people will revert to their own comfort zone in making a decision. In full use, the Cynefin framework has sub-domains, and the boundary between simple and chaotic is seen as a catastrophic one: complacency leads to failure.

Prioritise Requirements – MoSCoW

Chapter 25 of the new PRINCE2 Agile Guide is focused on Requirements and this includes the MoSCoW which is used for prioritisation (Prioritise Requirements – MoSCoW)

This chapter describes how to define and prioritize requirements in terms that are compatible with agile ways of working.

Here is a 20 minute video explains one of the best prioritization techniques which is MoSCoW and is use to prioritise requirements. Understanding and using this technique is really helpful for IT projects, as long as other kinds of projects.

MoSCoW stands for the following priority groups:

  • M (must have) – Features you must have in the final solution and it would be useless otherwise.  (Prioritise Requirements – MoSCoW)
  • S (should have) – Features you should have in the final solution and you would get into problem otherwise. However, you can find a workaround for the problem (do it manually, use another solution in parallel, etc).
  • C (Could have) – Nice features. You won’t have any problems if you don’t have them in your final solution.
  • W (Won’t have this time) – Features that you’re not planning to deliver this time.

Besides the use of MoSCoW prioritization for management of scope, as it’s done in some Agile methods, it can also be used for prioritization of acceptance criteria, as recommended in PRINCE2.

So, hope you would enjoy this video and find it helpful:

This use of MoSCoW was first developed by Dai Clegg of Oracle UK Consulting and he subsequently donated the intellectual property rights to the Dynamic Systems Development Method (DSDM) Consortium.

MoSCoW is often used with timeboxing, where a deadline is fixed so that the focus can be on the most important requirements. MoSCoW is also seen as a core aspect of rapid application development (RAD) software development processes and agile software development techniques.

MoSCoW is a technique used in management, business analysis, and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement. This is also known as MoSCoW prioritization or MoSCoW analysis.

See the PRINCE2 Agile Group on LinkedIn for more information

Page:  Prioritise Requirements – MoSCoW

PRINCE2 Agile Guide

Some good news, Axelos have given us a preview of the new PRINCE2 Agile guide. This preview also includes a simple high level overview of each chapter

So you can read the first three chapters of the PRINCE2 Agile guide and remember the publication date is 14 June 2015

Download from the AXELOS website




PRINCE2 Agile – the Structure

Blending Agile with PRINCE2 processes and themes will likely be a challenge for both PRINCE2 and Agile practitioners alike to fully embrace. Many may see it as adding a set of heavy processes to Agile. However, as they come to understand what PRINCE2 Agile offers both communities, we believe that they will overcome any initial scepticism and recognize the value PRINCE2 Agile brings to both. No-one thought you could blend ITIL and Agile but DevOps is proof that old practices can indeed find new friends.

As already stated, this is just the beginning of a broader push to integrate different methodologies and practices that will enable practitioners to get the most out of their existing knowledge and experience while they continue to identify areas for emerging practice – but with a very definite emphasis on incorporating Agile thinking throughout.

Looking at the new PRINCE2 Agile qualification I have two initial observations: the first is that it was long overdue. Many of us have long known that Agile and PRINCE2 could and should be blended. The second is now that we have done the blending, we know Agile and PRINCE2 are, in fact, quite complementary, just as PRINCE2 and the PMBOK are. A good balance has been struck between the two; the blend is far better than simply the sum of two parts.

See full article:  

By Larry Cooper – Senior Partner, BSSNexus Global Inc.

Authors: Larry Cooper and Jen Stone

The title of this book, Agile Value Delivery: Beyond the Numbers, recognizes that linear extrapolations from past successes—which may have been a successful formula in recent times—is no longer a practical guide for managers or workers in a post digital world. Simply stated, the digital revolution has thrust us suddenly and rapidly into in a new world with new rules. This book is a practical behavioral guide to those who want to master these new rules. (from our Forward by Rod Collins)

About the book
We decided to write this book to illustrate how Agile Practices, and more importantly Agile thinking, can be combined with those from Outcomes, Portfolio, Programme and Project Management to successfully and consistently deliver Value into Business Operations.

If you are a Portfolio, Programme or Project Manager and want to know which Agile practices would apply to your space then this book is for you. If you are on an Agile team and want to know how Portfolio, Programme or Project management need to change to support you then we’ve got you covered.

If you are in HR or Finance and are wondering how all this Agile stuff really affects you then you really need to read Chapters 2, 3 and 9. It’s not just a technical thing – it’s a cultural and a money thing.
If you still believe in waterfall and think best practices are awesome, check out Chapter 3 and be stunned. They’re far from awesome.

The website that will accompany the book. www.NextGenAgile.com, will provide additional collateral such as practice descriptions and how-to’s, tools, templates, articles, etc.
This is Release 1 of the book. We hope to do two additional releases in the next year.

See link for more information:   https://leanpub.com/agilevaluedelivery-beyondthenumbers