Speed is essential in today’s business. Some people even say speed equals to life, or at least to being alive.
In my rather long software career, I have seen tens, if not hundreds, of managers pushing their software teams for more speed. The pressure for speed is all about how soon you can get your deliverable ready. This is often called time-to-value or execution speed. The irony is, you rarely get more speed when you ask for it. Instead, you are likely to get faster action, slower time-to-value, and more problems.
Lean manufacturing gets time-to-value right: it is more about removing slowness than accelerating your actions. Slowness comes from tasks that do not add value, idle time, and rework. In software, just as in manufacturing, attempts to accelerate often result in more defect and thus more rework. The more rework there is for someone, the more idle time there probably is for someone else.
In addition to time-to-value, one has to consider at least three other perspectives of speed: reaction speed, cycle-speed, and timing.
Reaction speed is about how fast you can get your act together when your objectives and circumstances change. This is a vital skill nowadays as objectives and circumstances tend to change more often than not. If you are good at both time-to-value and reaction speed you may consider yourself agile. The agile movement was born from the desire to combine time-to-value and reaction speed. Before agile, all mainstream software management methods were based on controlling and limiting change while agile boldly welcomed change.
Welcoming change, executing fast, and reacting fast is a losing recipe without controls that help both the team and its external stakeholders understand what they have accomplished so far, how far they are from reaching their goal and whether the goal should be adjusted somehow. This is where cycle-speed, also known as pace or frequency kicks in.
Agile methods responded to the need for controls through standups, sprint demos, and other regular events that force people together for the review of progress. Such practices turned out to be hard to implement, though. It is not easy to maintain time-to-value, react fast, and still integrate, synchronize and review regularly. The solution was to automate the process of synchronizing, integrating, and measuring so that a high and regular cycle-speed can be maintained. The practice is known as DevOps. In DevOps, time-to-value, cycle-speed, and reaction speed come together in a meaningful way.
One perspective is still missing: timing. Timing is about knowing the right time for doing something, be it a new feature in a product, a new tool or method, or whatever. It is great to deliver fast, react fast, and operate in fast cycles but those only matter once you know time is right for the thing you are trying to accomplish.
Check out how to make your software development more efficient and how to manage all these four aspects at once.