Season beat

…and exciting endeavor.

✣  ✣  ✣

{{{wish full}}}

Therefore:

{{{therefore full}}}

✣  ✣  ✣

Use the season beat as development episode. Every year has 52 weeks, 4 seasons of 12 + 1 . 12 weeks are 12, 6, 4 or 3 sprints of 1, 2, 3 or 4 weeks each. This leaves room of ‘one week out of time’ for a release review, retrospective and planning.

✣  ✣  ✣

Season Beat

What it is

While working as Practice Manager of Sun Microsystems’ Java Center, Martien van Steenbergen created a perfect release train to drive Agile software development. Based on a seasonal or quarterly release train, he identified six viable iteration lengths that allow an organization to synchronize and integrate all software development on a regular basis.

Using a 12-week cycle, iteration lengths of 1, 2, 3, 4, 6 or 12 weeks are viable. Also, every 13^th week the organization has a “week out of time”, i.e. a week to work on stuff that would otherwise get in the way of regular work like preparing for the next cycle, multi-day training, conferences, deep reflection, and team building activities.

The image illustrates Van Steenbergen’s release train which he calls “season beat“, like heart beat. The columns are the weeks, the rows the viable iteration lengths. Note how all iterations align every 13^th week.

Why it is useful

The seasonal release rhythm of 13-week development episodes:

• brings calmness to both the market, product and development teams, and the organization at large.
• provides clear and predictable deadlines for all stakeholders in the ecosystem;
• tackles dependancies because—in conjunction with risk carrier decides—it:
  1. synchronizes sprint boundaries;
  2. harmonizes sprint lengths;
• obsoletes planning—any recurring event is predictable and does not need planning.

How to use it

Suit these 13 week development episodes to fit what feels natural to you:

• 12 sprints of 1 week;
• 6 sprints of 2 weeks;
• 4 sprints of 3 weeks; or
• 3 sprints of 4 weeks.

Each development episode ends with one “week out of time” to celebrate the previous one and get ready for the next one. Each release is named after the release’s season; for example the Spring release.

Note that using a 6- or 12-week iteration length is only feasible if you are running a plan-driven project, i.e. a Waterfall project. To get the benefit of an empirical Agile approach, keep your iteration length to 4 weeks or less. By identifying the 6 and 12-week iteration lengths as viable options, Van Steenbergen’s release train allows for easy combination and synchronization of both Agile and Waterfall projects.

Week out of time

• Day 1: Release Review
  • Invite first and second grade stakeholders
  • Review last roadmap and compare with actual
  • Demonstrate product increment (release)
  • Highlight events of last season
  • Provide cliff hanger (outlook) to next Release Review
  • Conclude with informal drink, dinner maybe, depending on achievement
• Day 2: Retrospective
  • Include everyone; make it mandatory
  • Pick appropriate Large Scale Intervention work forms (Open Space, World Café)
  • Establish improvement (kaizen) theme for next season
• Day 3: Release Planning
  • Prepare/adjust rolling Story Map and Roadmap for next season
  • End of day everyone is ready for next development episode (season)
• Day 4: Conference
  • Invite one or two external keynote speakers
• Day 5: Free Space (Vrije Ruimte)
  • You can do whatever you want

Sources

• Het geheim van de syncope.
• http://scaledagileframework.com/agile-release-train/
• http://scalingsoftwareagility.files.wordpress.com/2009/11/ch-15-the-agile-release-train-rev-6.pdf

---