In my previous life, as a developer on the Microsoft Visual Studio Team System Process Team, I helped design workflows for user stories and other types of work items. These workflows were to be integrated into the process as a status field on the work item. At one point, we identified a workflow that boiled down to something like this:
At the time, we felt that it was important to make a distinction between items that were actively being worked and those that were waiting for the next stage of the process. In the end, we simplified the status field by dropping all the active verbs (those ending in “ing”), in favor of assuming that all work in the current sprint was active.
Part of me likes that decision – it certainly simplified the workflow. But, part of me, to this day, bemoans that decision because it limits a team’s ability to identify waste within the process that needs to be eliminated.
Imagine a process for building widgets. In this process, each widget starts life as raw materials. These materials get flobbled, marned, and volmed before becoming actual widgets. As materials move through the process, sometimes there are too many to marn all of them at once. So, those “in-process” materials sit and wait for their turn at the marner. Similar delays may also happen at the flobbling and volming workstations. And, of course, at any time, one of the machines could break causing downstream process points to run out of work.
This is a typical manufacturing process. And, it’s just like the software process described above.
In Lean manufacturing (a process improvement method invented by Toyota) the time a piece of work has to wait for a machine is considered waste. (It was a waste of money to buy more materials than the process can handle.) Likewise, the time a machine has to sit idle waiting for the next piece of work is also considered waste. (Idle infrastructure is a waste of the investment incurred to obtain and operate said infrastructure.) Lean manufacturing seeks to eliminate all of that waste. Out of this movement have come innovations like just-in-time inventory.
Likewise, in Lean software development, time spent in the inactive states (those verbs ending in “ed”) is considered waste to be eliminated. In other words, why groom 20 stories when the developers can only work on five at a time. The Product Owner may never prioritize some of the other 15 groomed stories high enough for the team to work on them, rendering moot the effort spent grooming those abandoned stories. Likewise, why continue developing code when there are broken tests? Until the tests are fixed, nothing can move forward in the process.
Scrum lends itself to Lean software development through its iterative, incremental approach to building software. So, the team only needs to groom enough work for the next sprint, for example, reducing the potential for time to be spent grooming stories that will end up being abandoned.
The metaphor breaks down a bit, though, when you run into a particularly urgent but poorly understood request from the business. It may take so much time to groom that development stalls, waiting for well understood requirements. This is wasteful in that the developers and testers (the infrastructure of software development) are idled. Extreme Programming’s approach to this situation would be to punt the poorly understood requirement until such a time that it can be adequately articulated. Scrum is less, um, confrontational, but no less dependent upon adequately articulated requirements.
As with everything else on this blog, I just needed to get this out of my head. I hope you found it interesting and/or useful. But, if not, at least my brain can now move on to something else.