Stop Starting and Start Finishing
Companies typically have a large number of active or valuable work to be done at any one time, all at various stages of development. Performance improvement often focuses on how to do more, not how to do less. Therefore, limiting the volume of requests being done seems to go counter to the overall goal. In fact, many systems speed up when the volume of work being worked on decreases.
The Traffic Flow Problem
A reasonable metaphor for this is the speed-density-flow relationship seen in traffic studies. Figure 1 shows the classic relationship, where flow = speed x density. In the case of traffic, the speed of the traffic increases (from a standstill) as the number of cars on the road falls. The flow of traffic on the road, on the other hand, increases to a point, but then falls off as the number of cars on the road falls below a certain number, however fast they are going. In other words, there is excess capacity in the system as the number of cars on the road falls.
Figure 1: The graph shows the relationship between speed, density and flow for traffic on a highway. The higher the volume of traffic, the slower the speed of the cars, and the lower the flow of cars along the highway. However, as the number of cars on the highway falls, the flow will also drop off even as the cars go as fast as they can (hopefully at the speed limit).
In the case of work requests entering development, the flow of work through the system changes in the same way, increasing to a point, but then decreasing rapidly as the volume of work requests increases. Unfortunately most systems operate at or above capacity, at which point there is a negatively reinforcing feedback loop driving the performance down (Figure 2). Once a system has passed its optimal flow regime, additional work requests quickly decrease the performance of the system, causing longer wait times as more work requests pile up, which can lead to more requests being worked on, decreasing the performance (throughput) of the system even more.
Figure 2: Above the maximum capacity of the system (when the flow through the system is at its highest), we see a negatively reinforcing loop. That is, as the density of cars increases, the flow through the system falls, increasing the number of cars in the system, leading to a further drop in the flow through the system, and so on. Something we’ve all encountered around 5 o’clock in most cities.
This can be seen in any system by measuring the cycle time, the total time it takes to start and complete a single feature or piece of work, and lead time, the total time it takes to complete a piece of work (cycle time) plus the time the work spends in the queue, and plotting these as a function of the number of work items open at any given time.
Limiting WIP in a Scrum Team
So how can we apply this principle to an existing backlog of work consisting of the many valuable and less valuable tasks a product gathers over time? In Scrum, the team limits the number of items they are working on by pulling in only the number of work items (or stories) they can complete in a sprint. This automatically limits the team to a fixed number of stories, hopefully between 6-10 stories. More mature agile teams will also limit the number of stories they are actively working on during the sprint, only working on 2-3 stories at any one time; The purpose of this is to speed up throughput by limiting work-in-progress (WIP).
Many teams have other kinds of work they have to handle. Perhaps emergency items (such as production support tickets) that cannot wait until the next sprint planning to be addressed, or small enhancements, maintenance items or report extracts, that are part of the everyday maintenance and support of a product or service. These types of work requests can be handled through a contingency stream, captured on the team’s task board, and tracked visibly for all to see. There are a few guidelines for handling these tickets:
- Set a capacity limit for the team to spend on these additional items, and help the team manage to this capacity.
- Have clear policies around what to do with larger items (e.g. work requests larger than 1 day go into the backlog, work requests smaller than a day are handled in priority order).
- Hide the bulk of the tickets from the team (but not the business stakeholders) to avoid distracting the team.
- Allow the business to prioritize the tickets the team works on – hopefully through the Product Owner – and if this is not possible set clear rules (e.g. date order) and keep to that.
- Make the work backlogs visible to all so that everyone can see where their ticket is and what is in front of their ticket.
Prioritizing Work across Multiple Projects
In situations where there is a portfolio of projects for a single team to work on, it can be hard for the team to complete one project before the pressure to turn their attention to the next project in the pipeline becomes unbearable. This leads to large amount of unfinished work (inventory with a very real cost to maintain and support or build around) as well as the frustration of abnormally long lead times or time-to-market, incomplete work waiting on small changes, and never-ending projects.
In this case, we clearly want to allow the team to work on each project a little at a time. But doing this story by story (work request by work request) doesn`t solve the problem of partially complete work unless the work on each project delivers something shippable, something that adds value even if the project in its entirety is not delivered. Grouping a minimal set of stories together to deliver a slice of functionality – a Minimum Viable Product (MVP) the customer can interact with and use – allows the team to work on one project after the other, delivering something of value for the owner of each project (this could be feedback, rather than working functionality, but that’s a discussion for another post) as quickly as possible (Figure 3), while moving each project forward.
Figure 3: Managing multiple projects is hard. Many times, the priority of a project is determined by urgency or whether or not a project is ‘front-of-mind’. In this case, projects can be continually open, never quite ready for release, but not moving forwards either. In order to facilitate effective delivery of projects, we want to break them down into small, releasable slices of functionality. Minimum Viable Products (MVPs) that we can release, perhaps to a limited audience for feedback, before committing to build the next slice of functionality. This allows multiple projects to be developed in parallel, while ensuring each project moves forwards in viable steps.
This does not remove the need for prioritization of the projects. However, this can be done at the portfolio level, even better at the MVP level (rather than the project level). Its easy to say that a performance project has priority over a site re-design project. However, some performance improvements are more valuable than others, and some site re-design changes can be more valuable than other performance enhancements. Prioritizing between MVPs allows the line of business to optimize on what is most important to the business at any one time, while allowing all projects and priorities to move forward.
Working on Fewer of the Right Things
In conclusion, limiting the number of projects a team is working on (making the team do less) does not have to reduce productivity (can actually deliver more). While the development team takes responsibility for delivering an increased flow of work through the team - making sure the capacity is predictable and continually improving, the business team and product owners ensure a transparent backlog of MVPs from which to work from - making sure that how the capacity is used maximizes value delivery. The increase in throughput as a result of focusing on fewer work requests, coupled with an ordered backlog of small features or Minimum Viable Products (MVPs), allows a development group to deliver the most important and valuable work more frequently.