27.2 Releasing early and frequently
Traditionally, many projects have delivered the final product using a serial, or Waterfall, approach whereby a series of technical phases (such as analysis, design, build, test, implement) lead to the whole product being delivered at the end of the project (see Figure 2.2).
Even when working in this way, the project can still be broken down into chunks to allow for an earlier delivery of parts of the final product. This is sometimes referred to as ‘phased Waterfall’ as each chunk is still planned around technical phases. But this is still not an agile way of working.
Agile looks at this in a completely different way. It does not base its plans upon technical phases; it bases them on features and requirements instead. As part of the initiation stage of a project PRINCE2 Agile looks at how the final product can be broken down into coherent chunks and what parts of the final product can be delivered early to achieve the advantages outlined previously.
27.2.1 How releases fit in with the PRINCE2 process
Releases can be planned using product-based planning, and individual product descriptions can have their quality criteria defined to allow for different product ‘states’ (to reflect releases). Release backlogs would then sit under these. An alternative to this is to avoid using ‘states’ and assign products to a release backlog when appropriate. This is likely to be more appropriate if there are many releases and a high degree of change as to what is going into each release. It will be easier to use product-based planning this way as well.
Release planning needs to be incorporated into the PRINCE2 plans. A project plan would need to clearly show how many releases were expected throughout the project, when they will take place and what features are intended to be released. The same applies to a stage plan, albeit with a shorter horizon (see Figure 12.3).
The different levels of plan would need to be synchronized with respect to release planning. An example of this would be where the project board would like to establish a stage boundary in order to manage by exception. It would need to balance out its own needs to set a timescale with the needs of the customer or the delivery teams, who will have a view on what releases they would like to happen and at what time.
What is being released, and when, should not be seen as a minor or incidental part of a plan. How a product is released, gradually over time, will have a direct effect on how benefits are realized and can have a significant effect on whether or not the project can continue to be justified. It is possible that a project needs to realize early benefits in order to fund later parts of the project. The project board needs to be fully aware of the significance of release planning. It is not something that just concerns the people working at the delivery level.
Some of the fundamentals of the Lean Startup approach involve releasing a product in such a way that it maximizes the viability of the product and enables it to fail fast if it is going to fail. A well-crafted release plan can prove significantly beneficial to an organization. It can create feedback that can be responded to at the earliest opportunity.
How frequently and regularly releases take place (in terms of creating a regular cadence or ‘heartbeat’) needs to be collectively decided by the key stakeholders involved on the project (e.g. the helpdesk or the training department). In some situations products and sub-products can be delivered too quickly for the customer to absorb them efficiently. This could result in disruption from an operational point of view.
27.2.2 Releasing into operational use
To benefit from all of the advantages of frequent delivery, the ideal situation is for any release to go into the operational environment. However, this is not always possible or desirable. If a release does not go into operational use, it is unlikely to generate any benefits or ‘real’ customer feedback.
It is possible to release features too quickly! So you need to involve the right stakeholders.
A lot depends on how much control a project has over releasing into operational use. If the necessary stakeholders are on the project and they can dictate whether or not a release goes into operational use, and they are responsible for the impact of the release, then this is the ideal situation. This would be seen as ‘very agile’. However, if another company or department is responsible for the release process and the impact a release may have, then they may have other factors to consider such as contractual obligations or the needs of other stakeholders. This does, to a degree, limit the agile way of working.
27.2.3 Not releasing into operational use
Even though feedback from real customers and some form of benefits realization would be missing, there are still many advantages to delivering something into a staging area before going into operational use: for example, the opportunity to assess progress and the levels of quality being achieved. A significant customer demo could take place in order to receive feedback on how the product is developing, along with how the project processes and team behaviours have helped with that specific delivery.
It may be appropriate to populate a list of FAQs for when the product goes into operational use.
Unfortunately there is a significant limitation with respect to agile’s desire for regular, frequent (even continual) delivery when some form of staging area is involved. Typical reasons for inclusion of a staging area are regulatory compliance checking, integration testing or any other form of validation and verification process. The problem is that when an error is picked up and a change needs to be made, further work may have already taken place on the current state of the product, which would have been baselined at the point of delivery into the staging area.
The agile way of working is compromised to a degree when this happens because the problem cannot typically be solved by flexing what is being delivered. Whether or not a product is compliant with a safety standard is usually a yes or no, pass or fail condition. It is unlikely that you could ‘drop a little bit from the requirement for compliance’!
The problem will always remain, however, that when products are delivered into staging areas, their rework will need to be accommodated and planned for in advance. This will affect configuration management and version control so that the current state of the product can be efficiently resynchronized back to one version.