21.3 PRINCE2 Agile guidance on Managing a Stage Boundary
It is important to use stage boundaries or ‘fire-breaks’ appropriately when working in an agile way as although the delivery teams may be very content, working to a regular cadence and being very productive, because their focus is on product delivery they may not be aware of the wider context of their work. Their work may be going very well but they may not be aware that a competitor has launched a rival product and the expected benefits of the project are now significantly lower. Despite the good efforts of the delivery teams it may be prudent to cancel the project as it is no longer viable.
Tailoring guidance that may be appropriate is as follows:
- Reviewing how much is being delivered (and the quality of it) compared with what had been planned. This would include comparing the amount of value being delivered with the amount of cost incurred to create that value in order to ascertain if the project is still on track and is still viable.
- What has been released would typically be reviewed. What benefits are being realized?
- The appropriate use of agile could be reviewed in case risks are surfacing in certain areas (e.g. if the level of customer involvement is lower than expected more formality may be required).
- Release planning would typically be reviewed. For example, would it be a good idea to increase the frequency of the releases (if it is possible)? Would it be a good idea to alter the number of sprints (or their lengths) inside each release?
- The efficiency of configuration management and the choice of configuration item records could be assessed with respect to the iterative and incremental nature of the agile way of working. For example, are the configuration item records defined at too low a level and is this causing an unnecessary overhead?
- Is it worth carrying out a formal workshop to review the stage (perhaps as part of a release review) and then plan the next stage (see Chapter 22, Closing a Project, for how to handle a similar one) or at least a large-scale demo for as many stakeholders as appropriate? (NB: it is unlikely that this event will take place at the very end of a stage – e.g. on the final day.)
- Decide on which of the suggested improvements to the way the teams are working (perhaps created during a release retrospective) can be reasonably expected to be adopted in the next release. Further learnings could be formalized at this point and given to project support so these lessons can help the wider organization.
Table 21.1 shows PRINCE2 activities for Managing a Stage Boundary and how they relate to agile artefacts and events (all product description references for PRINCE2 products are located in Appendix A).
|PRINCE2 activities and products||Applicable agile artefacts and events|
Note: Sprint planning would typically be too detailed at this point but it may be useful.
Table 21.1 PRINCE2 Agile activities for Managing a Stage Boundary
21.3.1 How to ...
There are many behaviours, concepts, frameworks and techniques that are used in agile and referenced throughout this manual. Table 21.2 provides cross-references to some of the most relevant for use during Managing a Stage Boundary.
|Chapter and section references|
Plan stages and releases
Chapters 12, 27
Assess and improve team performance
Track progress when using agile
Define quality criteria and acceptance criteria
Manage risks and issues
Chapters 13, 14
Assess the risks associated with agile
Break down requirements and products in a way best suited to agile
Tailor any of the PRINCE2 management products
Table 21.2 Relevant agile guidance for Managing a Stage Boundary