Beware the Agile Speed Trap

Speed: A Common Goal

A quick management poll, asking their desired goals of pursuing Agile, will likely yield “increased speed” in the top 3, or even top 2 goals. Hearing such, it’s not surprising that Programs and teams will institute, or will be directed to institute, measures that attempt to measure productivity. They may even attempt to measure speed using something like Velocity (the average story points delivered per Sprint for teams using Scrum).

Yes, But…

While increasing your agility can lead to an increase in speed, or more importantly, using direct interaction and feedback from customers, lead you more quickly to the highest value work, directly targeting speed can be disastrous.

Teams that understand they are being measured based on how fast they perform their duties will give you more speed. But if the environment and system remains the same, at what cost?

Will they:

• take shortcuts that reduce quality?
• select lower value, yet easy to do, work so everyone appears continually busy?
• rely on overtime?
• start gaming the system by altering how they estimate?

Tell me how you will measure me, and then I will tell you how I will behave. If you measure me in an illogical way, don’t complain about illogical behavior.

Eli Goldratt

Watch the baton, not the runners

A useful metaphor from Don Reinertsen, author of The Principles of Product Development Flow, is to consider a relay race. In a relay race, 4 people run one fourth of the race and pass a baton from one to another to complete the race. So, at any given time, it can appear that 3 of the 4 team members are standing around doing nothing. Someone who doesn’t understand the race may conclude that having people idle nearly 3/4ths of the time is waste and that they need to be busy doing, well, anything but standing around.

The proper perspective is to consider what is of value — the baton crossing the finish line. Getting the baton across the finish line is the goal, not ensuring every team member is continuously busy. If all team members were always busy doing something during the race, and attempting to go even faster, passes may not be able to occur if one team member is across the field instead of being ready for their part of the race. Or another runner may be trying to do some juggling while grabbing the baton and drop everything. Stopping, bending down to pick up the baton, then check directions and finally starting to run — all of these things will slow you down. Think context switching here.

Process Cycle Efficiency/Activity Ratio

The vast majority of the management groups I’ve worked with all have had the same desire — increase code development speed. Having been a developer in the past, I understand that designing, writing, testing and getting feedback on the software takes time, often considerable time. Agile won’t directly increase the speed at which developers can write code. That’s not its purpose.

In their book Value Stream Mapping, Karen Martin and Mike Osterling describe the process of evaluating the Activity Ratio of the flow of value in the current delivery system. Others refer to this measure as Process Cycle Efficiency. The activity ratio is the total process time (time spent doing the work) divided by the total lead time (time from request to completion) multiplied by 100 (to get a percentage).

From their research, they have discovered that the activity ratio of the average value stream is 2 to 5%. Yep, 2 to 5%. What that means is that while people are very busy doing things, on average, less than 5% of the time required to move a piece of work through the system adds value.

Spuddle (17th Century): to be extremely busy while achieving absolutely nothing.

Two Time Concepts

Value-Add Time, or VA Time

This is the time spent adding value to an item of work. I also refer to this as “touch time”. Some examples in software development might include designing and writing the code, writing the user manual and releasing the code.

Non-Value-Add Time, or NVA Time

This is the time that work is sitting idle in the process flow. No value is being added during these periods where the work is at rest. I also refer to this as “inventory”. It is a documented idea or request but nothing is happening at this moment, the work is stuck somewhere in the process. Examples of NVA time would include waiting for an approval, waiting for someone to test the code, waiting in a backlog for another team to finish dependent work. Some NVA time is necessary in our flow, such as getting an approval in a highly regulated domain, but most NVA time is unnecessary.

This unnecessary NVA time is of the most interest to me in this conversation on speed.

Why many attempts at speed are doomed from the start

The vast majority of speed improvement efforts I’ve encountered centered around ways to increase the productivity of the development team. But remember, in the average value stream, only 2–5% of the time required to deliver an item of work is adding value (VA time).

Thus, most improvement efforts target only 2–5% of the delivery (lead) time.

Let’s say, for an example with easy math, that your Lead Time is 100 days. That’s the amount of time between accepting a request and delivering the final work to your customer. If you have an average value stream (unoptimized) then your VA time is perhaps 4 or 5 days (4–5% activity percentage). Doubling the speed of a team with a 4 day touch time reduces that to 2 days of touch time. This leads to a new Lead Time of 98 days, down from 100 days. Who will even notice?

You’ve just spent considerable time and effort to deliver an improvement that your customers will never even notice.

Change the Conversation

If addressing the Touch Time isn’t going to necessarily improve customer satisfaction, what might?

Of that 100 day Lead Time described above, work is sitting at rest somewhere in the value stream for around 95 days. Inspecting the NVA Time is where your efforts to improve your flow will pay far larger dividends. Why do we have so much inventory (work at rest) in so many places within our flow of value?

Again using the example above, if the NVA Time is currently 95 days in a system with a 100 day Lead Time, cutting out half of the NVA Time, or roughly 45–50 days, will be noticed by your customers. You would, in that case, likely cut your Lead Time in half, from around 100 days to around 50 days. And you didn’t risk adding any gaming, cutting of corners or lowered quality to get there.

Just watch your NPS soar!

There are many concepts from System Thinking that apply at this point — how do we optimize the whole? That’s beyond the scope of this article but I’ll be addressing some ideas in the future.

For now:

• identify where work is at rest
• what backlog(s) are accumulating work
• what sign-offs are no longer required or taking far too long
• what dependencies might we remove by rethinking our team structures. Every dependency (handoff) creates a queue.

In my experience, helping teams increase their effectiveness are limited by the surrounding system. Teams can only go so far within the current environment. While there are surely some gains to be found by the teams, it’s likely that the biggest wins are beyond their ability to change.

Efforts targeted at increasing “team productivity” will be constrained and likely limited in returns. Look for work at rest and understand what is causing so much work to be piling up in the flow. That’s where the big wins are!

If you found this article helpful, please click on 👏 and follow me for more valuable information on Agile, Lean and Book Reviews.

Until next time!