The agile value stream mapping oxymoron
by Alan Cyment
So I decided to read about Lean and grabbed a copy of Lean Software
Development, by the Poppendiecks. I’d heard so many times about Value
Streaming Mapping that I reckoned it must be good stuff. And so I read
about it. There goes quite brief a summary:
- Analyze your current software development process
- Write it down in a linear/sequential way, considering the average duration of each step
- For each step, decide the ratio of wasteful to productive time
- Productive: adds value to the customer – Wasteful: it does not
I don’t like it. At all. It simply feels awkward, at least
for a Scrum team. Or simply unrealistic. How can a Scrum team write
down their current development process on a piece of paper? It just doesn’t make sense. Scrum is about empirically designing product and process.
Yes, process must be optimized. Yes, it’s fine to try and find waste,
so that you can eliminate it. Yes, you can write down what you did ,
especially if writing it down helps you find useless steps. But it is
simply nonsense to ask a Scrum team to describe the process they
follow every time they develop software. The whole point of this thing
game we play is that we will adapt our process on the go.
Value stream mapping sounds cool for factories, but not so cool for consulting. Perhaps it is useful for software factories. Or perhaps software factories is yet another oxymoron.
Comments
yep.
Nicely written … although, I would like to have seen a more robust argument than “awkward” and “unrealistic”.
I think you get to the heart of the problem in the last paragraph especially the last sentence: “Or perhaps software factories is yet another oxymoron.”
I couldn’t agree more! =)
How does the team decide what to adapt next?
I think this stuff appeals to methodology junkies a little too much to trust it. We’ve been down the methodology path before.
I saw the Toyota Production System in action and thought it was very cool. We can all learn something from the principles behind it. But co-opting specific TPS *practices* and overloading the language might be taking it too far.
–mj (who could be wrong)
Hi
What if you’re not doing Scrum?
And if you are doing Scrum,
* What happens before the Sprint? How is the backlog created?
* What happens after the Sprint? How does the product get released?
Value Stream Mapping may help answer these questions.
Karl
“But it is simply nonsense to ask a Scrum team to describe the process they
follow every time they develop software. The whole point of this thing
game we play is that we will adapt our process on the go.”
I think you’re trying to map the wrong things. You’re thinking about your development team as the factory, and that isn’t right.
When you’re writing code you are building a factory, and that is what you should be mapping.
When somebody uses your code, they use it for a reason. They are looking to obtain some value. That is the value stream you want to map.
What goal does the user want to achieve? What actions must they perform to achieve that goal? Of those actions, what adds value and what is waste.
UI people have been doing this for ages, with the Gulf of Execution and the Gulf of evalution. http://www.interaction-design.org/encyclopedia/gulf_of_evaluation_and_gulf_of_execution.html
@Karl I find you everywhere
> How is the backlog created?
a backlog isn’t ‘created’, that’s the point — it is creatING, it is an ongoing process also based on empirical feedback. A backlog is a living list and is never finished until we kill (or more kindly, retire) the product.
> How does the product get released?
Again, maybe this is just the wrong question. Theoretically, “done” software can be released at any time, so planning big-bang releases may not be necessary, and the release is simply part of the work we do to get to “done”.
By continuing to think in manufacturing metaphors we will continue to bind our thinking to manufacturing practices. Think differently.
@Tobias Because I’m following you
Re: Backlog. My understanding of Scrum is that the input to Sprint Planning is a set of well defined/understood Product Backlog Items. If so, how do those PBI get defined/understood. I agree its ongoing, but its still something that needs to happen and thus its useful for it to be transparent.
Re: Releasing. Who mentioned big bang releases? I prefer to release per feature. Not every Scrum team can, or has to, release as part of the Sprint. When they can’t, or don’t, then its useful to have that work transparent.
@Karl — but where does this idea come from that these things are not transparent? Transparency is a foundational value of Scrum, and the task board is one tool –a particularly good tool– for realizing that.