A long time ago, I learned a little game from James Bach: the beer game. It is a little exercise of trying to do something that people manage on a daily basis, buy a beer at a bar. Yet as the game progresses, it becomes clear that simple things can be hard. Your beer can come in a size you don't expect (you did not specify!), in temperatures you did not expect (you did not specify!) and with stuff you did not expect (you did not specify!). With the rules its played, you can only lose. And the only way to win is to stop the current rules.
Software development has a lot of aspects like this. If we end up in the defensive mode, one part of organization pitted against the other, we can always shift blame around. The estimates and predicting the schedules that are by nature filled with uncertainty can easily turn into a blame game. And from a perspective of an individual team, I can easily find others to blame: it would have taken us a week, but we were blocked by another; it would have taken us a week, but we thought you meant X when you meant X+1; it would have taken us a week, but then quality is flexible and we did not think of that aspect of quality this time. Like the beer game, this is a game you cannot win. Trying is a sub optimization. Instead I find we need to look at the overall system, beyond an individual team.
Why do we want to have a date available? Because we don't have the stuff we need available today. Why we think the stuff we have today isn't sufficient? Because we believe that if we had more, it would be easier to sell? Why do we need stuff to be easier to sell? Because our sales people most likely are heavily paid on commissions. Is there other ways to set up the sales people's salaries? Most certainly yes.
I'm still in the process of asking why but I already know this: I'm not looking for ways to win in a game we shouldn't be playing. I want to change the game into something we can all win together.
And for people thinking that "2-3 hours of estimating every now and then, no big deal". In scale, with uncertainty it is a big deal. And with people like me who feel every given estimate with their every night's sleep, it is a matter of health and sickness. I don't actively lie when I know there are better ways of doing things. Thus estimation is not a routine I take lightly.
Software development has a lot of aspects like this. If we end up in the defensive mode, one part of organization pitted against the other, we can always shift blame around. The estimates and predicting the schedules that are by nature filled with uncertainty can easily turn into a blame game. And from a perspective of an individual team, I can easily find others to blame: it would have taken us a week, but we were blocked by another; it would have taken us a week, but we thought you meant X when you meant X+1; it would have taken us a week, but then quality is flexible and we did not think of that aspect of quality this time. Like the beer game, this is a game you cannot win. Trying is a sub optimization. Instead I find we need to look at the overall system, beyond an individual team.
Why do we want to have a date available? Because we don't have the stuff we need available today. Why we think the stuff we have today isn't sufficient? Because we believe that if we had more, it would be easier to sell? Why do we need stuff to be easier to sell? Because our sales people most likely are heavily paid on commissions. Is there other ways to set up the sales people's salaries? Most certainly yes.
I'm still in the process of asking why but I already know this: I'm not looking for ways to win in a game we shouldn't be playing. I want to change the game into something we can all win together.
And for people thinking that "2-3 hours of estimating every now and then, no big deal". In scale, with uncertainty it is a big deal. And with people like me who feel every given estimate with their every night's sleep, it is a matter of health and sickness. I don't actively lie when I know there are better ways of doing things. Thus estimation is not a routine I take lightly.
