Agile Heresy
January 2, 2012Those who do the work are the best people to estimate what it takes to perform the work. Makes sense. Sounds reasonable. The problem with such a definitive statement is the subjective word “best”. Most of us read “best qualified” into that statement. But what if the “best” person to do the estimation, won’t? Have you ever worked with people on an agile team who don’t want to contribute to the backlog item estimation activity? Sometimes a rigid corporate culture causes people who are, or perceive themselves to be “lower on the food chain” to say little and thereby avoid perceived conflict or anger of a more senior person. Sometimes it’s a cultural behavior. Sometimes fear. Sometimes shyness.
One successful team that I coached found a workable solution. They selected a small sub-team from the more senior people on the team. This sub-team did the estimation for the whole team. It worked well and they have been very successful.
But do you think this is agile heresy? If so, how would you otherwise fix such a situation?
Paraphrasing that old adage: You can lead a horse to water, but you can’t make him estimate.
Robert Maksimchuk's Blog 
Well,
Considering the amount of heresy in Agile, I don’t think this can be counted as heresy anymore. Agile has been twisted and modified and adapted in the most horrendous ways that it no longer looks as Agile.
I’m sure those who created the Agile Manifesto won’t like it
PS: You might be interested in reading this article I have published a while ago: http://www.pmhut.com/agile-myth-vs-the-practical
Yes indeed there is a lot “confusion” out there. Your aritcle gave me a chuckle because when I am coaching teams I often talk about “throwing up the guardrails”. Also I too have found that the “Truth Mirror” is very real and often frightening to people.
Of course, having the senior people estimate works. It’s the traditional waterfall approach, “Team, you’ve got X hours to do Y.” And if the time is too much or too little, the team will adjust their behaviors to oblige, or at least try to. It’s easier. I had the same experience.
IMHO, there are two big problems with this approach. First, it reinforces the hierarchal power structure that Agile is supposed to transform. It’s a slippery slope back to task assignments and the command and control world.
Second, the team is able to hide and avoid both learning about estimation but also avoid learning about constraints & dependencies inherent in the work in the most timely manner.
Bottom line: It becomes an ownership issue. Although pragmatic and keeping everyone content, it’s the equivalent of continuing to cut the meat for your children.
Wow, I couldn’t have said it any better than Karen did. The only thing I would add, as a leader and coach, I would take it as my responsibility to understand the specific hindrances within my team that prevent some members from participating in the estimation process, and then come up with specific actions to overcome those.
The potential for flattening out the hierarchy, broadening the scope of ideas, and building a broader skills matrix (more members who can perform more of our needed roles) are worth the effort, imho. The individual development and affirmation that could result is also quite valuable to the team and individuals.
One of the key principles in building an agile team environment is educating junior technical resources to estimate through best practice. I have created small pods lead by a senior developer/manager and two junior developers who work to estimate features on a daily or weekly basis depending upon the Roadmap. The approach has been very successful in building confidence with junior staffers (who these days tend to be young and sometimes from a different culture). Estimation can then be tested through development and code review process, ultimately reviewed by Program Management (Project and Technology Leadership).
This technique also builds the team dynamic, and improves the quality of deliverable incrementally.
Like your experience Victoria, I have seen this problem to be particularly acute with teams that have members that are globally distributed. The cultural impacts are often underappreciated. And even more so if the distributed team members are provided by external vendors (vs. employees of the “home” company).
To be true to Agile principles, I would far rather improve the estimation process to make it more enjoyable (or less painful) than to have less the 100% team participation in Poker Planning meetings.
Ideas:
1. During Poker Planning, let them just flash their story-point vote without asking them to say much. Give them a couple iterations for them to get their bearings and become comfortable in this meeting setting. If they’re still not comfortable speaking out and defending their vote, then look inwards as to how you’re encouraging them to participate – rather than blaming them for their lack of participation.
2. Keep the Poker Planning sessions short (but have more of them, if necessary to keep up). Anything more than an hour is too long. Half an hour might be enough at a time. Timebox it, and don’t exceed the timebox – even if there’s more to estimate. Don’t try to squeeze one more estimate into the time box – which will cause you to go over a bit. Better to finish a bit early than a bit late, because then the team will believe you when you say the meetings are time-boxed.
3. Simplify the estimation process so that it’s not as time-consuming, and doesn’t require as much precision. e.g. Try T-shirt sizing instead of Fibonacci sizing. To vote for S/M/L is so much faster and easier than to vote for 1,2,3,5,8,13… And maybe surprisingly to some, it’s just about as accurate. (As SM or PO, you can convert S/M/L to 2/3/5 or 2/4/6 later – on your own time.)
4. Remember that the most important aspect of Poker Planning is not the estimate itself, but the discussion that resulted in the estimate. This discussion helps the entire team understand the entire project – not just their small piece of it.
5. The key question is not “Do we have consensus on the estimates?”. Rather, it’s “Are the requirements and acceptance criteria clear?”. To that end, revote often (sometimes without much discussion at all if the story is clear), and encourage the minority votes to concede to the majority – but only if the values are adjacent. If they’re not adjacent, there’s probably some misunderstanding that needs to be cleared up.
I have seen teams painfully struggle trying to use “points” in their estimation. But once we introduced the T-shirt sizing, they got it and they loved it (and with much less resistance that using Fibonacci). Thanks for the reminder Kirk.