If you're running at a different cadence, someone is always falling behind.

If you’re running at a different cadence, someone is always falling behind.

The Scaled Agile Framework Enterprise (SAFe) uses the concept of a hierarchy to translate business strategy and needs to the work a Scrum team does on a daily basis. The hierarchy begins with value streams that are actualized by agile release trains (ART). ARTs are a long lived team of teams this is organized to deliver the support the value stream. While the value stream provides a goal and the ART the long term vehicle for the that support additional structure is needed before teams are set loose. As anyone that has watched teams interact knows, without structure shenanigans will ensue. The program increment provides a structure to connect the long term vision and the scrum teams. Program increments are similar to sprints, but at higher level.

The scrum teams within an ART use sprint cadence as a synchronization and motivational tool to develop solutions in a coordinated manner. Cadence provides short feedback cycles that provide focus. Program increments aggregate a fixed number of sprints together to peruse a common theme or goal such as a group of related features that might comprise one or more releases. The program increment process provides a framework to synchronize planning and development through group planning, group demonstrations and larger scale retrospectives. The program increment functions in much the same manner as the Sprint in Scrum. Here are the attributes of a program increment:

  1. Time-bound planning cycle. Program increments are typically 8 – 12 weeks, four two-week or three-week sprints.
  2. Common theme/goal. The program increment acts a container to focus development on the features and functions needed to deliver common theme or goal. The program increment and release plan do not have to synchronize. Using an example of a hypothetical customer facing website. A program increment could be focused of developing an integrated shopping cart solution with releases being made during the 8 – 12 weeks as major components reach done.  The mantra of SAFe and Agile development is, “develop to cadence, release on demand.” Said more bluntly, develop using sprints and program increments to provide cadence and synchronization and be ready to release when the business needs the functionality.
  3. Ceremonies demarcate program increments. Much like sprint planning and demonstrations and retrospectives mark the beginning and the ending of a sprint, program increments are bounded by ceremonies. The release planning meeting marks the beginning of the program increment and the “inspect and adapt cycle” marks the outer boundary.

A program increment is a time-boxed container with a common theme or goal that helps the multiple teams involved in an ART to stay synchronized. Teams further enhance their synchronicity by integrating frequently, participating in Scrum of Scrums, management dependencies as well as team and system-level demonstration. The duration of the program increment is often syncronized to release schedules and plan, however the two concepts do not have to be synonymous. Agile development is about building implementable functionality every sprint, the macro cadence of the program increment allows that functionality to be bundled into features which can be released as planned or as needed.

A different kind of artifact...

A different kind of artifact…

Scrum is nothing if not simple. Three roles, four or five events depending on what you count and  . . . three artifacts.  The Scrum artifacts are deceptive in their nature as each artifact plays double, triple or even quadruple duty across the lifespan of the project. When using Scrum, the deliverables must evolve.

The artifacts identified in Scrum are:

  1. The Product Backlog. This includes all of the known units of work in priority order.  In a perfect world, the team would already know everything that needs to be delivered and capture it on the product backlog at the beginning of the project.  Classically, project teams invest significant efforts in defining as many requirements as possible, and then they put that list under change control (sometimes the level of control was quite draconian).  In Scrum, the product backlog represents the antithesis of the classic requirement document, at least from the perspective of process. If an initial product backlog does not exist, most projects begin with a short time box to begin the development of a backlog.  Sprint teams begin development at the end of the time box or sooner if possible. The backlog is always prioritized (highest priority to lowest) with the units of work near the top broken down to a point that they can be completed during a single iteration.  As the project begins and the backlog begins to be used, evolution begins.  Existing units of work are continually refined and groomed, while newly discovered units of work are added to the backlog.  The product owner owns the product backlog.  The product owner needs to have perfect transparency into the list as he or she will need to review and refine the prioritization as the team gains knowledge about the solution and the market place.
  2. The Sprint Backlog. It is the breakdown of tasks and activities required to deliver the units of work the team committed during the sprint.  The sprint backlog exists only for the time box beginning with sprint planning and ending with the team retrospective.  The sprint backlog is first developed during sprint planning and then refined by actual events and planning that occurs during the daily meeting.  A sprint backlog that does not evolve is a failure.  Colin Powell, US General and statesman, said “No battle plan survives contact with the enemy.”  The sprint backlog is the team’s battle plan.
  3. The Increment. The increment is the functionality completed during the sprint.   Assuming you are involved in a software project, the gauge as to whether a sprint has met its goals is whether functional software is delivered that satisfies the units of work that the team committed to delivering.  Satisfied means that the software meets the definition of done (a solid definition of done is that the code is written, documented as required, tested and is defect free) and is potentially implementable.

All three Scrum artifacts evolve.  The increment and the product backlog will change over the life of the project.  Inspecting the functionality delivered by the increment provides value to the organization and tangible proof of progress that a schedule or status report can’t provide. The sprint backlog will evolve based on the daily re-planning the team performs as they work toward the goal of delivering the increment needed to satisfy the commitment made during sprint planning.  The artifacts in Scrum are living deliverables in a way that no requirements document or project schedule could be in classic software development techniques.