The Tortoise or the Hare: Achieve Speed Through Predictability

In my line of work, I'm often called to help an organization "go agile" or do an "agile transformation."

My first question usually gets the most awkward pause: "Why do you want to do this?"After some discussion, we often get to something like, "We need to be faster," or "We've got some tight deadlines, and we need to get more done." It's about increasing throughput: getting more work done in shorter time frames.

Increasing throughput is a great thing to want; don't get me wrong! You definitely want more throughput as you become more agile.

There's a problem, though, when an organization makes that the near-term focus. If all you care about is going faster, you start seeing things like:

• Eliminating things that were adding value
• Fixing surface issues without discovering root causes
• Optimizing one part of production without looking at the whole system
• Improving speed but reducing quality

So, What's the Solution?

Instead of optimizing for speed, consider optimizing for predictability in Agile.

When I was learning to play tennis, my coach made me hit tennis balls into hoops he placed in different areas of the court. This was super hard and just as boring. I knew I would win games if I could just hit as hard as Andre Agassi. I wanted to learn power shots, not tapping the ball into hoops!

My coach told me that hitting hard was no good without control. Would I win games if I hit all my serves out of bounds? What if I kept burying the ball into the back fence with my tremendous power? Of course not. By learning control first, I could make things happen, and then the power and speed would follow.

It's the same way with production. Focus on predictable results first, then worry about increasing speed.

In my experience, most organizations want predictability even when they say they want more speed.Imagine that you have a product that needs to be done, and I told you that you could choose between A) having it done in precisely six months or B) having it done between four and eight months, but nobody could tell you when. Which would you choose?

In most cases, organizations would choose "A" even if the other scenario is potentially faster. They would probably even choose it if the range were between four and seven months. They would probably choose it if the range were between four and six months. The certainty of the six-month time frame is more useful to most organizations than an uncertain time frame that is potentially faster.

Why? Because delivering the product often requires more than just coding. There may be:

• Marketing efforts
• Change management
• Timeline-based budget decisions
• Multiple teams that need to coordinate their efforts

In all of these scenarios and more, a predictable timeline is more valuable than a variable but potentially faster timeline.

The Importance of Predictability in Agile

"But wait!" I can hear you saying: "If we become more agile, do we need our teams to be that predictable? Why can't we all just be responsive to things as they happen?"

First, let me congratulate your company on truly ninja-like levels of agility! I personally haven't run across an organization yet where completion times didn't impact anyone, but let's say you get there.

Consider this: how do you know if your teams are improving if their results are unpredictable?

Let's say you have a team that thinks they'll be done in six months. In that time, they make some process improvements, and they get done in five months. There's a good chance those process improvements were helpful ones.

But what if a team says they'll get done between three and eight months, they make some improvements, and they get done in five months? How do you know if those improvements helped or not? They might have even slowed the team down! You have no way to know.

You can apply that same principle down to the daily throughput or up to the project portfolio.If your production is unpredictable, you have no way to know if what you're doing is working.

This agile predictability also enables you to establish good SLAs with the business you serve, other teams, and your customers.The consistency of meeting those realistic SLAs builds trust, and the value of high trust between your teams and your customers is immense.

I'm not saying you should never try to increase your throughput, but that we need to get predictable first.

Some Diagnostic Tools

You probably already know in your gut if your team is unpredictable. The simplest indicator is: are they able to tell you when things are going to be done with some degree of accuracy?

I work in software development, and I can tell you this is a common issue. It's so common that there's now a counterculture in software development that actively fights against the notion that teams should even have to provide an idea of when things will be done. While I agree that organizations should focus more on value and less on time frames, there's still value in knowing when something will be done.

Another informal indicator can be the variability in the work item's size. Again, coming from the software industry, it's widespread to see an item in the team's backlog like "Add shipping to Canada as an option" right next to items like "Build an online shopping cart." When the work items themselves are widely variable, the team's throughput will also be variable.

Those can give us a clue that our teams are unpredictable, but often we want to know for sure and measure that variability more closely so we can work toward improvements.

A Cumulative Flow Diagram, for example, can show us where our arrival rates are out of sync with our departure rates. If we see a stage that isn't reasonably constant in width over time, that stage's arrival and departure rates are out of sync, and that stage is unpredictable.

Furthermore, a Cycle Time Scatterplot will show us the distribution of the cycle times of the items we move through our production system.Almost every team will have some outliers, but if there is commonly a wide degree of difference in your cycle times, that can show us how unpredictable your team is.

Another tool that can help us at a tactical level is an Aging Work in Progress report. If we commonly see items aging into "potential outlier" territory, that tells us that our day-to-day production is unpredictable.

What Do I Do About It?

The thing you can do with the most impact is to make your arrival rates match your departure rates. Make sure that new work comes into your system at a similar rate to your completion of work.

Seems like common sense, doesn't it? Unfortunately, most organizations run exactly the opposite way. The rate at which new work comes in is completely uncontrolled, and teams are forced to come up with a way to change their departure (or completion) rate to keep pace. This is often by working lots of overtime, cutting corners, or covering up the problems by adding more workers.

The thing is, there's only so much you can do to affect how fast you can get things done. Definitely try to take inefficiency and waste out of your process, but work takes time, even when you're running at peak efficiency. We have minimal control over how long work takes.

It's much easier to control how fast work gets into your system. We can't control the rate at which people ask for things, but we can control the rate at which we start them.

Define Commitment Points

One way to do this is to establish "commitment points"in your value stream. Many teams are familiar with coming up with a "definition of done" or identifying the point at which work is complete. That's one commitment point.

Another commitment point is to identify a stage (or come up with one) where a work item becomes work your team will definitely begin. Items in the backlog may never get done; that's not a good commitment point. In many cases, items also go through a bit of a process of discussion and ideation to refine them, but that still doesn't always represent a commitment to doing those items. At some point, you want to identify when a work item is going to be something your team is definitely going to produce.

For instance, many teams use a replenishable, WIP-limited column on their kanban boards that sits between work that might be done (e.g., items in the backlog, items still under discussion) and work the team is actually working on.It functions like a miniature backlog that holds work that the team has decided to pull into their system. The WIP limit on this column controls the arrival rate of work into the system.

By using a column between the variable pool of stuff that people ask for and your actual workflow, you set up a buffer between the highly variable part of your system and the rest of it. Techniques like this help you get a handle on arrival and departure rates and keep you from being "forced" to start work just because someone dumps it onto your team's plate.

Control What Comes In and What Goes Out

At one of our clients, we were looking at their kanban boards for all their projects, and one of the managers yelled out, "We have more active projects than we have actual developers!". An organization operating like this will be unpredictable no matter what they do until they decide to start new projects as old projects get done. Control of the arrival and departure rates - or "starting" and "finishing" rates - is key.

Visualizations such as the diagnostic tools we mentioned earlier can be of tremendous help in figuring out where your disparities are and what your limitations should be.

I like to use Cumulative Flow Diagrams in my Kaizen events because we can see right away the stages in which work is being taken on faster than it can be completed (or sometimes vice-versa).At one client, our team was looking at the CFD, and we noticed that the "start rate" of our items went way up even though the "completion rate" stayed the same.

It turns out someone on the team was only doing the UX piece of each item and moving on to the next one, leaving the items unfinished and starting new ones. When one developer races out ahead of the rest of the team, it impacts the team's efficiency and predictability in the Agile process.

Even though I tend to use Cycle Time Scatterplots more as a planning tool, they can show us the patterns of our completion times, and talking through the root causes of these patterns can be good material for improvements.If an item is a massive outlier, how did it get to be that way, and what can we do to prevent it in the future? If there are wide variances of cycle times, how did we end up that way? Do we perhaps have two different kinds of work items?

Aging Work in Progress is a very underused but compelling way to make tactical decisions on a day-to-day basis.If your team has any kind of daily standup or regular planning session, consider taking a look at your Aging WIP.

It's not uncommon for me to say something to a team like, "This item is getting close to passing 85% of our cycle times. Is this right? Do we need to do something here?". This may identify blocked items that need resolution or team members who need help.

Reduce Batch Sizes

Many of us work in fields where our work items do not all come out to be the same "size." In software development, for example, some features will be more complex than others. 

One thing we can do, though, is make sure we have split and pared our items down to their smallest deliverable value. Getting our work items down to where each one is as small as possible while still being a deliverable can keep our cycle time variations low. The more similar our cycle times become, the more predictable our teams can be.

Make Policies Explicit

Finally, you can apply the Kanban principle of explicit policies and/or the Lean principle of standardized work. For example, in software development, it's common for teams to have an explicit policy that Development is not done until the work item passes all automated tests.

When Quality Assurance pulls this item for testing, they are already confident the feature "works" and can focus their time finding edge cases or other cases a developer did not consider. Look for opportunities where it would add value to create standard operating procedures and explicit policies. These bring a lot of benefits to organizations, not the least of which is greater predictability.

Lesson from Martial Arts

In martial arts, there is a saying: slow is smooth, and smooth is fast. In other words, if you take the time to focus on consistent performance, the speed will come. This is just as true for our production.