- Managing Release Content
- Release Planning Event
- Preparation for the Release Planning Event
- Tracking the Release
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Tracking the Release
All the hard work that the enterprise has put into the Agile transformation should now start paying dividends. Once a commitment is achieved, the primary responsibility for delivering the release in a series of short iterations lies with the project teams. After all, they write and test all the code, and in Agile enterprises they're both empowered and accountable to achieve the agreed objectives.
Even then, however, the Agile enterprise recognizes that continuous tradeoffs of changing requirements and scope are inevitable, so the product manager also plays a pivotal role in helping the teams to meet the release objectives. Doing so requires ongoing tracking and managing of the release and its content. Fortunately, our Agile enterprise model is replete with visibility, so understanding the actual status versus the planned status of a release is no longer a "crystal ball" activity. Instead, four primary mechanisms help the enterprise and its key product manager stakeholders to keep the Agile release train on its rails:
- Constant informal communication with the product owners
- Participation in the release management team
- Attendance at iteration demos
- Release status assessment via Agile project management tooling
Let's examine these mechanisms briefly.
Communication with the Product Owners
The product manager has a direct liaison to the teams via the team's product owners. The fan-out is not too extreme—a single product manager typically interacts with some small number of product owners (3–6, for example), and thereby has ready status from all the project teams that must collaborate in meeting the release objectives.
Participation in the Release Management Team
In my book Scaling Software Agility: Best Practices for Large Enterprises and my Release Management Team blog, I've described a typical construct in which development management, Agile/Scrum masters, product managers, quality assurance, release managers, and other key stakeholders meet weekly to assess the status of a release. This release management team has the primary responsibility for shepherding the release to market. This weekly forum is a key touch point through which product managers can assess release status and adjust scope where necessary.
Attendance at Iteration Demos
The inherent visibility of Agile development also provides an inherent opportunity to see the working code as it develops. This happens in the context of the iteration (sprint) review, which contains both product demo and retrospective. The every-other-week product demo is key to the product manager's insights into status and progress, and is a not-to-be missed opportunity to see the product, interact with the teams, provide feedback, and make midcourse adjustments where necessary.
Release Status Assessment
To have even reached this point, the enterprise will assuredly have rolled out appropriate Agile project management tooling, which provides support for the higher-level status views needed by project managers and other stakeholders. This tooling should provide some form of hierarchical, feature-level burndown so that the product manager can assess—on an aggregate basis—exactly where the team stands within the release, as Figure 5 shows.
)
Figure 5 Release-level burndown.
This chart provides a sense of the probability of landing the release. However, it doesn't give any notion of what features may or may not be delivered. For that, the tooling should also provide default reports on the status of each individual feature, perhaps something like Figure 6 shows.
)
Figure 6 Status of release by feature.
Together, this information should give the release management team and the product managers objective knowledge of where they are—and, even more importantly, what changes might be necessary to land the release on time.