One of the key tenets of the Agile/Lean method of delivering software is the concept of reducing time to value. This is done with a laser-focus on value – simply there is no value from code that is not in front of a user. A necessary corollary of this is that there is no value from work in progress.
This is difficult for both producers and consumers of software to internalize. The managers of producers may be delighted to see high utilization from their development team. Consumers may be impatient with software progress and compensate by requesting more features be worked on. Both of these can produce waste by creating too much work-in-progress. Let’s consider an example.
Assume we have two pieces of work, “A” and “B”, each requiring 5 days of effort, each requested by a different user. We may placate the pair of users by alternating effort by day, thus treating the two users equally by working on both pieces of work at the same time. Our timeline looks something like this: ABABABABAB. At day 9 the first user receives A, on day 10 the second user receives B. Development was fully utilized, users were treated equally, but it took 9 days to deliver any value despite each piece of work taking 5 days!
Let’s consider an alternate scenario, where a strong product owner prioritizes work and minimizes work-in-progress. In this scenario there is no multi-tasking, work progresses as AAAAABBBBB. Now the first user receives value in 5 days (the second user still receives value at day 10). The strict prioritization decision reduced the work-in-progress and reduced overall time to value.
Work-in-progress is even more insidious. Whatever we build, we must consider not only if we are building it correctly but if we are even building the right thing! When we have a lot of work partially done, we are robbed of the chance to find out what our users think. We don’t see how it delights them, or how it confuses them, or how it’s not quite what they want. Without having finished code in front of users, we don’t have the opportunity to make the critical adjustments that take our users from “meh” to “wow”.
Agile scrum-masters only track two kinds of work: “done” and “not done”. (Some practitioners place even more emphasis on done, calling the final state “done done done”.) I used to think this was just a thin veneer on a collection of states in issue tracking software. I now realize this labeling is critical to keeping laser focus on what matters. It doesn’t matter how utilized the team is or how much work is in progress, rather it matters whether code is in front of users or not. Is that code providing value or not.
This lesson is difficult to keep in mind during the louder phases of a software project. There are many competing concerns that are difficult to balance. Find success by laser-focusing on what matters: providing value through completed code. There’s no value to your users from work-in-progress.
1 Comment