Apart from the wonderful scottish accent there was one train of thought that particularly caught my interest in SE-Radio Episode 156: Kanban with David Anderson:
Estimation is a choice! Estimates lead to commitments that drive a dysfunction that is undesirable:
Estimates lead to setting an artificial target and forcing people to meet that. That tends to drive heroic behavior. [...] When people act heroically they stop improving [...] and they stop learning.
- David Anderson, SE Radio #156
What if you can use your estimations mainly to prioritise your stories? The commitment should be that deliver as fast as possible but not that you are in sync with the estimates, should it? You always have to stress that estimates are estimates.
ReplyDeleteWhat if you do not have estimates, commitment, priorities...
@bertolami
ReplyDeleteAre prioritization and estimation really coupled?
In some cases this is certainly the case, but in a lot of cases I don't think they should be.
Is commitment coupled to estimation?
I think it should definitely not be...
In Kanban you are striving for this mystic constant throughput without waste. If you have reached this, then estimates are probably useless and wasteful...
Is this realistic? Is this applicable to software creation?
I don't know... I think it is very disconnected from the reality I am living in...
In my opinion there are three estimations that mainly drive priorisation: business value estimations, risk estimations, cost estimations.
ReplyDeleteBut if you consider estimation not coupled to priorisation nor to commitment, what should they be used for?
The stuff I read about Kanban was completelty ignoring story priorisation
@jonas: I agree that the Kanban approach is idealistic, but that doesn't necessary mean it's unrealistic.
ReplyDeleteI think in an environment where trust is not a question (and people are motivated intrinsically) it would work without a problem. The problem is we usually lack this trust in the typical business environment we work in, but IMHO provide estimations in this case won't fix the real problems, but rather hide them.
As for the priorities, I think they're connected more times than they are not. I can see the value in giving a *relative* estimation to the ones setting the priorities, so for that I wouldn't call estimations a waste either.
Hi,
ReplyDeleteit's not a dream land. It's a different concept simply. Think about maintenance where all you do is fixing bugs. An estimation of how long you need to fix a bug is senseless as after you know how long you need for fixing the bug you nearly have fixed the bug.
But more generally speaking, Kanban goes after the concept of stopping to manage timelines rather than managing functionality to be issued as efficient s possible. This is a very economic approach based on the work of Don Reinertsen, one of the most elaborate thinkers of product development. Far from unrealistic :-)
Lots of good companies go that way in product management and development as well.
Just take apple as an example. The perfect plan was to have copy & paste in place in time for the first release. But it was more important to release the first gen iPhone than having it complete. So Kanban fits perfectly in this way of issuing products.
Cheers
Markus
@sztupi
ReplyDeleteI agree that this is a very much a trust thing.
However that's probably where my doubts concerning reality come in.
I doubt that there is ever enough trust when money and more than two people are involved...
Call me a cynic :-)
And somehow this reminds me slightly to communism... everybody works out of intrinsic motivation ... perfect harmony and collaborative advancement ... but by now we accepted that this does not work...
@jonas: you're a cynic :)
ReplyDeletemy point was that of course if you're just starting a business relationship with a partner, you probably can't use Kanban - both parties lack the trust, and that's normal. in this phase estimations may not be so much a waste, but rather a tool for risk management.
still, earning the trust is crucial IMO in a longer partnership anyway (as in game theory: cooperation is much more effective if both parties do it). when (if) it is earned, then certain earlier practices may really become a waste, so you should get rid of them. just like there're no silver bullets in development, so are there none in processes IMHO.
if you don't think this trust can really be earned in the real life, the I think you're questioning the basic principles of agile processes.
about agile and communism: well, I've grown up in a (now-former) socialist country, so I may have a better feeling on why it was doomed to fail :). I think one of the main reasons was that the basic ideas are just not scalable - but that doesn't have to mean it can't be applied partly for small groups - I would cite game theory again. if motivation is missing anyway, you should fix that first above others, or else you'll much more likely to fail, regardless of the process used.
Also see: http://www.agileadvice.com/archives/2007/07/agile_is_not.html