Season beat

From Pearl Language
Revision as of 13:28, 12 June 2012 by Martien (talk | contribs) (Copy from pareltaal.nl (translated).)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
Seizoenslag.jpg

…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 13th 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 13th 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.

Sources

Template:Bron