This next task, make us a thingamabob, should be real simple for you guys to implement. You being experienced with this and all.My spider sense went out of the roof at this point. I had a hunch how this might end, and just watched the play unfold. The team suddenly looked uncertain and everyone went quiet. No one spoke. Instead, people looked at each other waiting for the other guy to respond. Eventually the manager said:
Hmm, it ought to take you just a couple of days, three tops, to implement, but just ignore me.Ah! So the team conversed shortly and somewhat hurriedly came up with an estimate of two days...
Can you see anything wrong with this?
I'll spoil it for you. This is called Anchoring and is "the cognitive bias that describes the human tendency to rely too heavily on one piece of information when making decisions".
In this case, the manager/product owner used his position to influence the teams decision by anchoring it using both a figure (2-3 days) an emotional value (simple) and some sugar coating (you are experienced). So it's not hard to understand why the team caved in under all that pressure!
This is bad when used by any team member, but it's particularly bad when it comes from a person in charge and especially insidious when topped with some innocent flattering. It makes otherwise clever and clear-sighted members doubt themselves ("I think this task is harder to implement, so I must not be experienced enough. I better just agree so they won't notice my lack of skills").
This is bad when used by any team member, but it's particularly bad when it comes from a person in charge and especially insidious when topped with some innocent flattering. It makes otherwise clever and clear-sighted members doubt themselves ("I think this task is harder to implement, so I must not be experienced enough. I better just agree so they won't notice my lack of skills").
The end result is what one might call false commitment, i.e. forcing people into making commitments they honestly cannot support. It leaves everyone feeling tricked.
The simple solution is to bring up the definition of Scrum/XP roles which tells us that:
The simple solution is to bring up the definition of Scrum/XP roles which tells us that:
- Programmers estimate
- Product owner prioritizes
This doesn't stop individual team members from influencing the others though. The final piece to this puzzle is to have each person estimate separately without any discussion with each other. A well known method for this is planning poker, which makes it very hard for individual team members to influence others estimations and tends to give more truthful results.
No comments:
Post a Comment
What are your comments? I'd love to hear 'em, so don't be shy now :-) If you want to get in touch with me directly just drop me a mail.