22.4 Agile concepts and techniques
22.4.1 An example of how to close a PRINCE2 Agile project
An ideal way to close a project would be with a workshop involving all of the key project stakeholders. Ideally this would be independently facilitated and use information from project-level information radiators that have been used throughout the project. It may even take place in the room or area where the project took place and the project management team worked.
The whole project team should be present (e.g. the project board, project assurance) along with other stakeholders such as those who will make the final product operational (or the final release of the product operational), those who will maintain and support it, and those from the strategic level who will be interested in the project outcome from a programme perspective.
The following is an example of how a workshop could be structured:
- Final product demo This would be conducted in order to achieve sign-off from the customer. This would not be a ‘big event’ as it would be the last in a regular and frequent series of demonstrations. There should not be any surprises here and it will not be a ‘big reveal’ due to the constant customer involvement throughout the project that has resulted in a lot of transparency and interaction.
- Follow-on actions These could be assigned to people formally or verbally or even by handing them a sticky note from an information radiator. Collectively the workshop participants could decide if unfinished work could be moved over to an appropriate BAU backlog, or handed over to the strategic/programme level as potentially a new project. Correctly addressing outstanding actions is most effectively done when the parties affected are in attendance and can discuss the relative merits of the options available.
- Checking against the baseline The final project-level information radiators and a demonstrable product could be compared with the original vision and baseline information, along with other supporting documentation that the project was justified against. The information radiators would typically show the project product description, the business case and the project plan and would have dynamically displayed this information throughout the project.
- Reviewing the use of agile This would involve assessing how well the delivery teams, and the project management team as a whole, used retrospectives to address issues and risks as they went along. Further to this, the use of the Agilometer should be checked to see if it had been assessed correctly and to determine if lessons about the use of agile on this project, and how the associated risks were handled, could be used on other projects. Ideally, project support would be in attendance to capture these learnings.
- Closing the event Perhaps the executive (depending on personal style), who would be there to look at the final costs, could thank the team and celebrate the end in some form such as a team meal. When a project has involved high levels of collaboration and teamwork, and the team is disbanded, it can result in a degree of ‘mourning’ for the team members, so this should be anticipated and ideas suggested as to how to reduce this.
22.4.2 Premature close
If the project has closed prematurely, it could have been triggered by a fail fast/learn fast situation caused by the correct use of management by exception (for example, a stage boundary was reached and the project was no longer viable, or tolerances were forecast to be exceeded and it was not worth taking remedial action). Many agile techniques are designed to help with this, such as timeboxing or empirical forecasting, which forces the ‘bad’ news to surface in a transparent way.
If a project is going to fail it is best that failure arrives as quickly as possible. Many agile techniques and ways of working can contribute to this, but the following are the most significant:
- empirical forecasting
- sprint (or release) demonstrations, reviews and retrospectives
- shortening the feedback loop to the customer
- frequent customer interaction
- experimentation, prototyping and spiking
- early enablement of benefits that did not accrue.
All of these concepts and techniques create or force a clear understanding of what is being attempted and can therefore highlight that a project or stage will take too long, cost too much, will fail to work or the project objectives have not been set correctly.