Different songs have a different cadence.

Different songs have a different cadence.

If you listen to the radio, talk or music, you will notice that the cadence you hear varies song-to-song, show-to-show or podcast-to-podcast. One cadence simply does not fit all people or situations. Songs, talk or software development the concept is the same.  In Agile, there are three types of cadence variation. They are innovation or recovery sprints, slow then fast and irregular sprints. Organizations tend to push towards a standardized cadence however they a few twists and turns might add a lot of value.

Innovation or Recovery Sprints. Innovation or recovery sprints are sometimes used to demarcate periods of significant development effort. These types of sprints are generally part of larger cadence cycles, just like the changes of seasons mark the boundaries of solar cycles within the overall annual cycle. Activities in these types of sprints often include training, vacations, planning for future sprints or roadmap building. Knowledge generation activities in these sprints often include infrastructure building, prototyping, spikes, building out the architectural runway for the project and hackathons. Sometimes these innovation and recovery sprints are used for catchup or overall integration testing (if not possible during standard sprints). A Scaled Agile Framework Enterprise (SAFe) program increment is generally 8 – 12 weeks long made up of 4 to 6 2-week sprints. The last sprint is an Innovation Planning (IP) Sprint. All of the teams involved in the program increment participate in the IP sprint. In February 2014, Mike Cohn described an overall cadence of 6 x 2 +1, 6 2-week development sprints followed by a 1-week sprint for catchup, recovery and improving the team’s capabilities. The primary goal of innovation or recovery sprints is to improvement the capability of the team (or teams) involved. Learning, planning, exploration, reduction of technical debt and recovery improves the ability to deliver value when the next overall cycle begins.

Slow Then Fast Sprints. This variation is similar to the ebb and flow of cadence in a concert. The overall cadence at the beginning of many concerts I have attended are  generally slower than the cadence at the end. The cadence builds up to generate excitement so that then end of the concert is a crescendo. Recently at a monthly meeting of the Cleveland Agile Group, Chris Bohatka described a project that began with 2-week sprints, however 2 months before the end of the project shifted to 1-week sprints. The shift in cadence used the knowledge and team esprit de corps that had been built to accelerate the cadence and provide new functionality on a weekly basis. Interestingly it was noted in the presentation that the team probably would never go back to the longer/slower cadence. This is one of the VERY few times I have ever seen this behavior. Typically managers indicate that their teams will start with three or four week sprints and then accelerate, then the teams never accelerate their cadences. In theory this behavior seem to make sense however follow through is generally poor because team settle into a rhythm and get comfortable.

Irregular Sprints. While I have heard of Agile teams with irregular cadences, I have never actually seen a team perform in this manner over any significant period of time. Teams that are alleged to have irregular cadences often modify their cadence based on the story size and their inability to break them down. Sometimes implementation of continuous delivery, Kanban or a kanbanny-form Scrumban are confused with irregular cadence. These techniques, heavily influenced by lean, either don’t leverage or deemphasize the idea of cadence. They focus more on the continuous flow of work than on the time box that cadence generates. This is not the same thing as irregular cadence. Irregular cadence is most often a reflection of lack of discipline or a problem with how stories are being groomed.

A sustainable pace is one of the benefits of Agile. Sustainable is sometimes thought of as delivering prioritized user stories every “x” weeks, month in and month out. Innovation and recovery sprints interspersed at regular intervals are a great idea to ensure sustainability. Teams need to learn, innovate and in some cases catch-up to their promises. Interspersing innovation or recovery sprint at regular intervals is reflection of a higher order cadence. Using the knowledge gathered by working as a team, delivering functionality and innovation team can accelerate the cadence, or at least has the option so that functionality can be delivered sooner AND feedback cna be gained sooner. Irregular sprints rarely make sense unless teams are ready to move to continuous delivery. Cadence in Agile projects promotes predictability and discipline which are attributes valued by both IT management and the business.

Longer isn't necessarily better.

Longer isn’t necessarily better.

In Agile, cadence is the number days or weeks in a sprint or release. Stated another way, it is the length of the team’s development cycle. The cadence that a project or organization selects is based on a number of factors that include: criticality, risk and the type of project. As a general rule, once a team or a team of teams has settled on a specific cadence they tend not to vary significantly. While In today’s business environment a plurality of teams and organizations use a two-week sprint cadence, there is often a lot of angst over the finding the exact number of weeks in a sprint any specific team.  Many organizations adopt a standard and take the discussion off the table. With any specified cadence duration, there are typically three complaints: too much overhead, not getting stories done and not being able to commit resources on full-time basis to the work. In almost every case the complaint is coupled with a request to lengthen the duration of the sprint and therefore to slow the cadence.

  1. The sprint structure requires too much overhead: Sprints begin with a planning event and typically complete with both a demonstration and retrospective. Short stand-up meetings occur daily. Some team participants view these events as overhead. Scrum practice and observation of teams strongly suggests that the effort for the Scrum events increase or decrease depending on the length of the sprint. Longer sprints tend to require more planning and lengthier demos and retrospectives.  As a rule I suggest two hours of planning per week and 30 minutes each for the demonstration and retrospective per week in a sprint. Stand-ups should be approximately 15 minutes per day. For example, I would expect to spend 3 hours 45 minutes (2 hours for planning, 30 minutes for demo, 30 minutes for the retrospective and 45 minutes for 3 stand-up meetings) on events in a one-week sprint and 8 hours (4 hours for planning, 1 hour for the demo, 1 hour for the retrospective and 2 hours for 8 stand-up meetings). I have noticed that the effort for sprint events that are more than three weeks long tend to take longer than one would expect (four weeks sometimes being more than twice what is expected). Realistically, sprint size should not significantly affect overhead until you get to sprints duration’s of four weeks or more therefore overhead is not an obstacle to shorter sprints. Remember that in earlier posts we have shown that shorter sprints deliver feedback and value sooner so therefore are preferred all things being equal.
  2. Our stories can’t be completed during the sprint. This is typically not a problem with the duration of sprint, but either an issue of how the stories are split or a process problem. One typical corollary to this complaint is that the team can’t break stories into thin enough slices to complete. Most of the time this is a training or coaching problem rather than a technical problem, however in highly regulated environments or systems that affect human life I have seen scenarios where stories tend to require longer sprints due to very specific variation and validation. One common cause of this problem is assigning and hard wiring roles (testers can only test for example), which can cause bottlenecks and constraints if there is any imbalance in capacity. This is illustrated by the Theory of Constraints (take a look at our Re-read Saturday entries about The Goal for more on the Theory of Constraints). Typically, longer sprints will not solve the problem. Unless the underlying capacity issue is addressed longer sprints typically equate to worse performance because more stories are started and are subject to bottlenecks and constraints.
  3. Our organization can’t commit full-time resources to a sprint. Part-time team members typically have to time slice, switching between projects and pieces of work leading to some loss of efficiency. This is a reflection too much work and not enough capacity causing delays, constraints and bottlenecks. Similar to issue 2 above, typically longer sprints will not solve the problem. Unless the underlying capacity issue is addressed longer sprints typically equate to worse performance for the same reasons as noted above.

Many problems with cadence are either a reflection of process problems that generate overhead or poorly split user stories. For example, teams that do not have a groomed backlog will need to spend more time planning. Some team members see planning as avoidable overhead (the just wing it mentality). Overly large teams tend to have long daily stand-up meetings, again typically seen as overhead. Stories that are not thinly sliced will take longer to complete and have higher propensity to get stuck giving the team a feeling that a longer sprint is better. In almost every case, thinly sliced stories and committing to less work tends to improve the flow of work so that the team can actually deliver more. The duration of the sprint and cadence are usually not the root cause of the team’s problems.

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.

Bands need to sync up with the beat.

Bands need to sync up with the beat.

In music, cadence is the number of beats in a bar. When I was young I was in a band. Our drummer generally set the cadence with the beat. In classic rock, the cadence was based on four-four time. When anyone of band members slipped out of time they would use the beat to synchronize. Most songs that include solos leverage the beat to re-sync the band when the soloist returns to the melody. Projects with more than one team use sprint cadence and the ceremonies of Scrum or Scaled Agile Framework Enterprise (SAFe) to stay synchronized or to re-resynchronize. Techniques for synchronization include:

  1. Matching cadence. All techniques for intergroup synchronization begin with matching cadences. When projects teams need to act in a coordinate fashion either because the functionality they are creating has to integrate or because teams might have to help each other need to be on the same cycle. Matching cadences allows teams to more easily integrate, plan and demonstrate the overall functionality being developed.
  2. Joint Planning. When teams are on the same cadence, they can plan together. Getting groups in the same room to plan allows cross-coordination and communication. For example, SAFe uses two day planning exercises to synchronize the planning for program intervals. I have also seen and led planning exercises for smaller groups Scrum teams that fall below the scale SAFe should be used (yes . . . you can scale SAFe work with groups smaller than 50 if you know what you are doing).
  3. Joint Builds. In a perfect world all teams in a project would be operating on a single, unbranched code base so that daily builds and tests would expose any inconsistencies. In many organizations teams either have not matured to that level of coordination or have technical constraints that preclude continuous integration. Matching cadence allows teams to get to done at the same time and to integrate at the end of every sprint. Integration provides technical feedback that helps the overall project stay on track.
  4. Joint Demonstrations. Demonstrations are to stakeholders what joint builds are to developers. Joint demonstrations provide feedback to help the overall project stay functionally on track.
  5. Scrum of Scrums. The Scrum of Scrums is the meeting of Scrum masters (the concept can and should be used for product owners also) on a periodic basis during a sprint. SAFe suggest twice a week; I typically suggest starting at twice a week and then more often if significant issues or risks crop up that need to shared and coordinated. When teams use slower cadences I generally recommend having Scrum of Scrums meetings more often to ensure that teams stay coordinated.

Using Agile at scale for work that requires more than one team will require adopting some techniques for coordination. Matching the cadence is the first place to start. Teams with the same cadence start and end sprints at the same time, making it possible to plan and demonstrate together. Joint planning and demonstration makes it easier for everyone to hear the same story at the same time. We often apply the analogy of herding to coordinating large projects, however cadence and other Agile techniques can be as useful as a good cowboy and horse for keeping the herd together.

 

Space between has to big enough and no bigger.

Space between has to big enough and no bigger.

Cadence represents a predictable rhythm. The predictability of cadence is crucial for Agile teams to build trust. Trust is built between the team and the organization and  amongst the team members themselves by meeting commitments over and over and over. The power of cadence is important to the team’s well being, therefore the choice of cadence is often debated in new teams. Many young teams make the mistake of choosing a slower (longer) cadence for many reasons. The most often cited reasons I have found are:

  1. The team has not adopted or adapted their development process to the concept of delivering working functionality in a single sprint. When a team leverages a waterfall or remnants of a waterfall method, work passes from phase to phase at sprint boundaries. For example, it passes from coding to testing. Longer time boxes feel appropriate to the team so they can get analysis, design, coding, testing and implementation done before the next sprint. The problem is that they are trying to “agilefy” a non-Agile process, which rarely works well.
  2. New Agile teams tend to lack confidence in their capabilities. Capabilities that teams need to sort out include both learning the techniques of Agile and abilities of the team members. Teams convince themselves that a longer sprint will provide a bit of padding that will accommodate the learning process. The problem with adding padding is twofold. The first is that time tend to fill the available time (Parkinson’s Law) and secondly lengthening the sprint delays retrospectives. Retrospectives provide a team the platform needed to identify issues and make changes which leads to improved capabilities.
  3. Large stories that can’t be completed in a single sprint are often noted as reason to adopt longer duration sprints and slower cadence. This is generally a reflection of improper backlog grooming. More mature Agile teams typically adopt a rule of thumb help guide the breakdown of stories. Examples include maximum size limits (e.g. 8 story points, 7 quick function points) or duration limits (a story must be able to be completed in 3 days).
  4. Planning sessions take too long, eating into development time of the sprint. Similar to the large stories, overly long planning sessions are typically a reflection of either poor backlog grooming or trying to plan and commit to more than can be done within the sprint time box. Teams often change the length of a sprint rather than doing better grooming or taking less work. Often even when the sprint duration is expanded the problem of overly long planning sessions returns as more stories are taken and worsens as the team gets bored with planning.

Teams often think that they can solve process problems by lengthening the duration of their sprints, which slows their cadence. Typically a better solution is to make sure they are practicing Agile techniques rather than trying to “agilefy” a waterfall method or doing a better job grooming stories. A faster cadence is generally better if for no other reason than the team will get to review their approach faster by doing retrospectives!

 In today’s business environment a plurality of organizations use a two week sprint cadence.

In today’s business environment a plurality of organizations use a two week sprint cadence.

In Agile, cadence is the number days or weeks in a sprint or release. Stated another way, it is the length of the team’s development cycle. In today’s business environment a plurality of organizations use a two week sprint cadence. The cadence that a project or organization selects is based on a number of factors that include: criticality, risk and the type of project.

A ‘critical’ IT project would be crucial, decisive or vital. Projects or any kind of work that can be defined as critical need to be given every change to succeed. Feedback is important for keeping critical projects pointed in the right direction. Projects that are highly important will benefit from gathering feedback early and often. The Agile cycle of planning, demonstrating progress and retrospect-ing is tailor-made to gather feedback and then act on that feedback. A shorter cycle leads to a faster cadence and quicker feedback.

Similarly, projects with higher levels of risk will benefit from faster feedback so that the team and the organization can evaluate whether the risk is being mitigated or whether risk is being converted into reality. Feedback reduces the potential for surprises therefore faster cadences is a good tool for reducing some forms of risk.

The type of project can have an impact on cadence. Projects that include hardware engineering or interfaces with heavyweight approval mechanisms will tend to have slower cadences. For example, a project I was recently asked about required two separate approval board reviews (one regulatory and the second security related). Both took approximately five working days. The length of time required for the reviews was not significantly impacted by the amount of work each group needed to approve. The team adopted a four-week cadence to minimize the potential for downtime while waiting for feedback and to reduce the rework risk of going forward without approval. Maintenance projects, on the other hand, can often leverage Kanban or Scrumban in more of a continuous flow approach (no time box).

Development cadence is not synonymous with release cadence. In many Agile techniques, the sprint cadence and the release cadence do not have to be the same. The Scaled Agile Framework Enterprise (SAFe) makes the point that teams should develop on a cadence, but release on demand. Many teams use a fast development cadence only to release in large chunks (often called releases). When completed work is released often either as a reflection of business need, an artifact in thinking from waterfall development and, in some rare cases, the organization’s operational environment.

Most projects will benefit from faster feedback. Shorter cycles, i.e. faster cadence, are an important tool for generating feedback and reducing risk. A faster cadence is almost always the right answer, unless you really don’t want to know what is happening while you can react.