Embedded Files
Agile development and delivery should be performed with respect to a certain cadence. As a minimum, this cadence must regulate the taking of productivity measurements and provide systematic opportunities for a team to inspect and adapt its process so as to improve it. This simple and effective approach is common to most Lean Kanban delivery teams, which assess their throughput and other measures, such as latency, over set periods of time. Other agile teams will batch related work for completion within each set period in order to achieve a significant product-focused goal. The “Scrum Sprint” is an illustration of the goal-driven approach in action. Success with regard to the goal - which is to say, the delivery of the batch and the mitigation of significant risk - provides a useful point of reference for inspection and adaptation. Sprints occur on a regular cadence of no longer than a month. At the beginning of each Sprint a batch of work can be planned, and at its conclusion a corresponding increment of functionality can be reviewed, demonstrated, and potentially released. The Scrum Team's process will then be subject to inspection and adaptation during an end-of-sprint Retrospective.
Each Delivery Team's cadence of inspection and adaptation should align at least once per month with the Transformation Heartbeat of the organization. This allows multiple teams to synchronize organizational deliveries, and gives the Transformation Rollout Team a regular indication of overall progress towards enterprise agile adoption. For example if an organization has a Transformation Heartbeat of 4 weeks, then teams might reasonably have cadences of 4, 2, or 1 week in length. The cadence of any given team would thus align every first, second, or fourth occurrence with the 4 weekly Transformation Heartbeat.
The Transformation Rollout Team should promote cadences that are appropriate for each individual Delivery Team. Any given team's cadence should be as rapid as efficient practice will allow. The timebox must be short enough to enable inspection and adaptation with minimum delay, yet long enough to permit the retrospective analysis of a significant sweep of team experience. If batches of work are planned into each timebox – as would be the case with Scrum Sprints for example – then there is an additional consideration to bear in mind. In such cases the Team Cadence must be short enough to stop large batches of undelivered work from building up and depreciating in value, yet long enough to allow meaningful Sprint Goals to be achieved.
Choosing a suitable cadence for a team is hard, and experimentation may be needed before the right balance is found. When promoting a suitable cadence, the Transformation Rollout Team should also consider the ability of the Development Team to absorb items from the Transformation Backlog, and to inspect and adapt its practices accordingly. In the early stages of agile transformation this is likely to be more important than any other single factor.
Note: An example increment status summary is available (DOC format).
Synonyms: Iteration, Sprint, Development Timebox, Delivery Timebox
Page updated
Google Sites
Report abuse