Sets
- Schedule Joint Demonstration Ceremonies
- Run the Joint Demonstration Ceremony
- Report Release Progress
- Support Facilitators
- Review the Release
Schedule Joint Demonstration Ceremonies
Agile Release Manager:
Schedule a “Joint Demonstration Ceremony” that:
- Recurs on a regular schedule matching the most popular sprint length among your teams, on or immediately after the last day of the sprint if they are on the same schedule.
- Is mandatory for all team members, Customers, Architects, and Agile Liaisons, and individual contributors assigned to the program (including part-time assignees).
- Invites as optional everyone outside the program with an interest, such as the Project Sponsor, executives, and external customers (even if they never attend).
- Allows a maximum of 30 min. per team for cycles of three to four weeks or 15–20 min. for shorter cycles, plus 15 min. for discussions.
Note: The Release Planners as a group are free to change these figures if they want more time.
Details: “Address Scaled Communication Problems.”
Run the Joint Demonstration Ceremony
Agile Release Manager, during each Joint Demo:
- One team at a time, have its members:
- Show the stories list from each sprint completed since the last Demo.
Note: In most scenarios, this is only one sprint. - State the acceptance rate of those sprints, and explain any story failures or blockers.
- Demonstrate the deliverables of as many customer- and market-requirement stories as possible, answering questions or taking suggestions for future direction as those are raised.
- Summarize accepted stories covering technical and business requirements.
- Seek acceptance of completed but unaccepted stories and epics.
- Show the backlog, and take input on rank order, or show the Sprint Plan if their next sprint has already started.
- Solicit input from anyone in the meeting on team-level issues or processes, for consideration in the team’s Retro or planning.
- Show the stories list from each sprint completed since the last Demo.
- After all teams are done:
- Show the updated Release Burndown Chart if possible.
- Solicit input from anyone on program-level issues or processes.
Details: “Give Each Team its Time” and “Drive Epic Acceptance.”
Report Release Progress
Agile Release Manager:
- Create a location for release progress reports that all stakeholders can access.
- After each Joint Demo, create or update the report location with:
- A sentence summarizing the results.
- A sentence or two providing a general description of the accepted deliverables.
- If stakeholders cannot access the tracker:
- The acceptance rates for the sprint or sprints (percentage of committed stories accepted).
- Names of the accepted stories from the completed sprint(s).
- The updated Release Burndown Chart.
- Send an e-mail to stakeholders with the summary information and a link to the report location.
Details: “Report Release Progress.”
Support Facilitators
Agile Release Manager, as needed:
- When asked, help Facilitators clear cross-team blockers and those external to the program.
Note: Blockers are your top priority when they arise. - Watch for cross-team problems or inaccurate information going to teams, and coach the Facilitator(s) involved.
- Answer questions about FuSca™ processes (from anyone).
- Answer stakeholder requests for information about the program, referring requestors to your status reporting location or the tracker to reduce future requests.
Details: “Address Scaled Communication Problems.”
Review the Release
Agile Release Manager:
- Either:
- Schedule a half-hour meeting of the Release Planners and Team Guides.
- Invite the TGs to the first half-hour of the first planning meeting for the next release, and add the next step to the top of its agenda.
- During the meeting:
- Ask and record answers to the following in a Release Retro document:
- “What went right in the release?”
- “What went wrong in the release?”
Note: Make sure you address the Agile Performance Standards in those two questions. - “What can we do differently?”
Note: Address every “went wrong” item.
- Review recent Retro notes for items the team said it would do differently, and discuss whether those were done.
- Facilitate additions or revisions to the entire list.
- Create action items or continuous improvement epics if needed to address the “do differently” items.
- Review the list for corrections, preferably in a different view.
- Ask and record answers to the following in a Release Retro document:
- If the group has agreed to make results public, e-mail all program members with a link to the document.
Details: “Retro the Release.”