Steps: Support the Release

Sets

  1. Schedule Joint Demonstration Ceremonies
  2. Run the Joint Demonstration Ceremony
  3. Report Release Progress
  4. Support Facilitators
  5. 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:

  1. One team at a time, have its members:
    1. Show the stories list from each sprint completed since the last Demo.
      Note: In most scenarios, this is only one sprint.
    2. State the acceptance rate of those sprints, and explain any story failures or blockers.
    3. 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.
    4. Summarize accepted stories covering technical and business requirements.
    5. Seek acceptance of completed but unaccepted stories and epics.
    6. Show the backlog, and take input on rank order, or show the Sprint Plan if their next sprint has already started.
    7. Solicit input from anyone in the meeting on team-level issues or processes, for consideration in the team’s Retro or planning.
  2. After all teams are done:
    1. Show the updated Release Burndown Chart if possible.
    2. 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:

  1. Create a location for release progress reports that all stakeholders can access.
  2. 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.
  3. 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:

  1. 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.
  2. During the meeting:
    1. Ask and record answers to the following in a Release Retro document:
      1. “What went right in the release?”
      2. “What went wrong in the release?”
        Note: Make sure you address the Agile Performance Standards in those two questions.
      3. “What can we do differently?”
        Note: Address every “went wrong” item.
    2. Review recent Retro notes for items the team said it would do differently, and discuss whether those were done.
    3. Facilitate additions or revisions to the entire list.
    4. Create action items or continuous improvement epics if needed to address the “do differently” items.
    5. Review the list for corrections, preferably in a different view.
  3. If the group has agreed to make results public, e-mail all program members with a link to the document.

Details: “Retro the Release.”

Share this page