Tag: Health Check

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.