Most software development teams are working in iterations, but they are not working in an iterative, incremental way. Dividing time up into sprints is not enough to receive business benefits of agility. Sprints do not provide the benefits they offer unless the cycle time of the work is shorter than the length of the sprint.
Sprints are intended to be a fixed length time during which improvements to a product are planned, built, tested, integrated, and deployed. At the end of the sprint, the results of work are reviewed by stakeholders and new decisions and plans are made based on the outcome.
Sprints provide the following benefits:
- Short Horizon Planning – The short time of the sprint fixes the “project schedule” over a short time, encouraging the team and stakeholders to plan only a few days into the future, review what they did, and then make a new plan. This iterative, incremental approach accepts uncertainty and is an attempt to manage it.
- Small Batch Work – Because the sprint is short, work selected for the sprint must be small, or it will not be completed during the sprint.
- Cadence – Humans need a regular cadence to function at top performance. The more rhythmic events are, the more likely they are to survive the effects of entropy.
Sprints establish a frequent learning loop that helps a team cope with the uncertainty inherent in developing software. These are not guaranteed outcomes. These effects only exist if the sprint contains a complete work cycle.
Sprints perform another function: making visible that work cannot be completed during the sprint. This is intended to signal to the team that the way work is broken down and the process it goes through will need remediation to achieve agility.
Sprint Time < Cycle Time
If the cycle time of the work performed during the sprint is longer than the length of the sprint, then the length of the sprint is not the cadence, learning is delayed, and the iterative, incremental delivery system delivers far less value.
- Batching will continue and projects will remain the de facto work organization standard, slowing flow and increasing risk and cost throughout the lifecycle.
- Planning horizons will continue to be far into the future, creating further batching
- Learning cadence will be infrequent and perhaps low-value
- The wrong things may be built and deployed, increasing risk
- The long, unwieldy process will become accepted as impossible to improve and become a fact of life that is never addressed.
The purpose of short horizon planning and small batch work is to handle uncertainty. Since the we do not know the value of work until it is delivered, a cadence of frequent learning is the fastest way to discover the truth about value. By reducing the batch size of work, it flows more quickly through the system, is lower risk, and far less expensive to interrupt or abandon if it is no longer the top priority.
Iterative, incremental delivery is intended to replace the idea that we can plan a project with many ideas, work on it for an extended period, and then deliver the right thing while remaining responsive to market changes and customer satisfaction.
The Symptoms Organizations See
When cycle time is longer than sprint length, symptoms of this being a problem will emerge.
- Sprint review becomes a status update. Instead of having a discussion with stakeholders about what to do next, the team will find the sprint review to become a status update on work in progress, and no conclusions will be drawn about the value of the work delivered during the review.
- Stakeholder disengagement. Stakeholders will lose interest in attending a sprint review that is essentially a project status update. Instead of attending themselves to review work and make new plans and decisions about how to pivot based on what they see, they will delegate to a project manager or prefer to receive an email on progress while they focus elsewhere.
- Interruptions. Teams will begin to complain that they are constantly interrupted, and will want some boundary placed around the sprint disallowing changes to the plan. Because cycle times on far horizon plans are long and the batches are large, interruptions become more likely.
- Carry-over or spill-over. Teams with long cycle times will find that work items are not completing during the sprint and continue into the next sprint regularly. New work will be accepted while old work is still being completed. The sequential nature of iterative, incremental delivery is lost, and the sprint now holds no meaning other than regularly scheduled status updates.
The worst possible response is to conclude that “this is how things work here” and accept the situation without trying to solve the problem.
Why Cycle Time is Longer than Sprint Length
There are multiple causes of long cycle time which are often unaddressed after initial adoption of something like Scrum, xP, or SAFe. The most common is functional silos. Traditionally, organizations divide up teams by their function for efficient, top-down management control of capacity and utilization. All of the developers are in one group. The testers are in another. Designers live in another group. Organizing around top-down management rather than value may empower control mechanisms, but it has costs.
Unempowered, silo teams cannot control WIP, which drives up cycle times. Over-utilized teams who are ordered to fill capacity with work will also experience very high cycle times. Handoffs from one silo team to another cause delays and queueing. Requiring approvals from upstairs makes management the bottleneck. Silo teams cannot improve the process itself, as they each only own a small part of it. The process, collectively owned by a large organization, is imposed, not emergent. Because of this, the process is only ever embellished with additional steps, and none are removed.
Misdiagnoses
Organizations see the long cycle times and often apply a “fix” that is worse than the original problem. I refer to this as process embellishment: the habit of management to be embarrassed by an outcome and institute an additional approval, check, template, or gatekeeping activity to prevent it from happening again. Over years, these embellishments pile up and slow down the system dramatically, leaving teams working in a convoluted process. They cannot change it, and they cannot deviate from it.
Teams will sometimes see these symptoms and come to the misguided conclusion that the sprints are to blame. Work is being interrupted and spilling over the sprint boundary all of the time, so they want to get rid of the sprints. Scrum teams will say that they want to switch to Kanban so that they can improve their flow, not realizing that Kanban is not an alternative to Scrum. Removing iterations removes the measurement, not the delay.
Costly estimation practices will be established to attempt to plan away the uncertainty plaguing the team. Plans will be made more detailed and comprehensive. Teams begin to believe that if they just knew what the future would hold, if they could name every dependency, imagine every possible complexity, they will be able to successfully deliver to plan. But these efforts lead to large batch work, far horizon planning, and long cycle times. All these changes will cause is more of the same problem!
The Correct Response
Create cross-functional teams. Move authority and functions into the team. You can keep the functional silos in the org chart, but construct teams around the ability to do all of the work end to end. Analysis, design, build, test, integrate, validate, deploy, and release should all live within each team. This will give the team members control over the process and empower them to continuously improve it. They will no longer be trapped by a top-down mandate of how work flows through the system.
Remediate the process. Remove unnecessary steps, automate repetitive manual labor, remove unnecessary vertical communication in the form of approvals and reviews. Empowered teams can help greatly with this, but it will also require management to step back and remove themselves as bottlenecks from the system. The more management tries to help control the work, the more management slows the work down.
Adopt short horizon planning. Make small plans only out a sprint or two. Accept uncertainty and the fact that it cannot be planned away. We can only plan to engage with it. Use the sprint learning loop to discover what is true, and create sprint-long projects, not multi-month projects with a fixed scope and then ask when all of that stuff can be delivered. Such thinking is deterministic and fails to account for the changing environment leaving the organization unable to adapt.
Make work items small. Instead of spending valuable time in refinement estimating how big items are, simply ask if something can get done in the next couple of days. When the answer is no, make the item smaller. Spend time in refinement downsizing items to small batches so that they will flow through the system. This will reduce the effects of complexity and dependencies dramatically. Interruptions will no longer feel like the ship has been hit with a torpedo.
Control WIP. Limit the number of work items that are allowed to be in progress at a time to create a pull system, preserve priority, and improve cycle time.
Note: adopting only one of these items because the others are political non-starters or would require many difficult conversations or expensive updates to infrastructure is unlikely to be effective. To get a return on the investment of adopting agile practices, create cross-functional teams, remediate the process, adopt short horizon planning equal to the length of the sprint, emphasize small batches, and control WIP.
Sprint as a Smoke Detector
Most of the elements of agile practices exist to create transparency. In part, that means that elements exist to reveal when things need to change to make improvements. Sprints exist to reveal that these things need to be done. Think of them as a smoke alarm sounding at night. You can either respond to the alarm and fix the problem, or you can reach up and pull the battery out of the alarm so that it stops annoying you. Sprints do not impede flow. Used properly, they create it.
A team cannot learn faster than its cycle time.
