Value stream mapping - the downside

It is of course important to map how long time it takes from an idea being put forward to a development project until it's in operations. For example the time from a critical bug being reported until the fix is in place is crucial. But it's also important to remember that it's not good if you get to eager as well when implementing new functionality.

Of you're into Lean software developement, you know that building extra features is something to be avoided: it increases the overall costs in all future releases and it clutters the solution for the users: you cannot see all the useful features because there are so many useless ones in the way. And the easiest way to build extra features is looking at an idea, finding it neat (and perhaps easy to implement) and just build it. Without thinking if it's easy to test and uphold in future releases and if it really is as good as you originally thought.

It's easy to get carried away. And if you on top of this measure how fast you react to user input, it becomes even easier.

If I'm unsure of a request, I simply listen to it and let it rest. If it's important and really good, the stakeholder will come back again, perhaps give more examples and ideas. And if it's really a good idea, other stakeholdes will probably come forward with the same request. And two persons coming with input on an idea is ten times better than one: with two stakeholders you can have a good discussion on different implementations and the risk for a not thought through solution is lessened.

I use the same method when my son is interested in an expensive toy: if he really wants it he'll remember it and ask for it again. And now he's been asking for that green car with Buzz Lightyear since this summer. So I guess he really wants it. And he will probably appriciate it better now that he has been longing for it for some time.

But do note that this method should only be applied on new functionality: bug fixes is a completely other story...