Let me clarify.
Sure, all the self-organized team estimation techniques work fine when your planning work for a single team. However, I’m finding more and more that single-team techniques (story points, ideal days, T-shirts, etc) break down when applied to large programs and portfolios. I know this, because I learned it the hard way.
THE PROBLEM
Let’s say we’re working at a company, where several product lines each need access to several agile teams at the same time. Some of these were component teams and some were feature teams. Pretty standard deal.
One day the lead PM comes to me and says, “Jesse, we have a new project that touches 4 agile teams. Each of them uses a different estimation method. I’m going to the portfolio review next week to get this project authorized, where the executive team needs to know much it will cost, and when it will be done. How to I merge their different estimates into a single answer?”
THE CLICHE’ REPSONSES
1. [Calculate the Average].
Me: “Just average all the estimates together and divide by the average velocity to get the number of iterations needed to finish the work. Once you have the number of iterations, you can easily calculate the schedule and the budget. The mean is a least-squares-sum statistic, and corrects for the intrinsic variation across the teams.”
Greg: “Okay, but here’s my problem. Every two weeks, one team delivers an average of 11 story points. Another averages 55 ideal days. The third team uses T-shirt sizes, and the fourth team averages 97 ‘agile function points’. If I mash that all together, I’ll just get soup.”
Apparently, they had learned all these techniques in agile training, MY agile training. In every class I teach, I train people to use any one of a variety of popular estimation techniques, you know, just to give them options. It never occurred to me that so many teams within THE SAME organization would use EVERY technique I taught, and then self-organize themselves into a gordian knot. So I offered a different suggestion:
2. [Implement a universal estimation standard].
Me: “Let’s quickly teach all 4 teams to use ideal days. No story points. No T-shirt sizes. One size fits all.”
Him: “Okay Jesse, but here’s my problem. Our flagship agile pilot team has been using story points, for over a year. A newer team is using T-shirt sizes, and in 1 month they’re already at a 100% hit rate on their commitments. That’s great momentum on the norming-performing scale. If I go back and tell those guys they were wrong about how they estimate their work, they’ll point to their results and then ignore me. I lose a ton of credibility on the whole self-organizing topic we’ve been coaching.”
Ug. He had a point. I was in a coaching quagmire. Credibility with the teams or with the CTO? I knew this was a false choice. So, I put together another option:
3.[The convoluted spreadsheet].
Me: “Go ask each team to use their own estimation technique for their piece of each feature. Then, divide by their respective velocities to get a forecasted number of iterations per team per feature. Then add it all up. You’ll end up with a spreadsheet that looks like this:
PM: “Okay Jesse, I can do that this time for this small project, but here’s my problem. We have dozens of projects that need to be coordinated across dozens of teams. If we have to generate one of these spreadsheets for every project, then the teams will get sucked up into a TON of estimation and planning. How do I get all the productivity gains if my delivery teams are spending half their time in planning meetings? Doesn’t that amount of big-up-front-planning violate the rule of progressive elaboration?”
THE QUESTION
You can imagine this was a painful situation. But the real tragedy is that this happens over, and over, and over again. Something is wrong here, and I’m going to be spending the next few posts discussing the underlying forces and how they impact the techniques we’ve been teaching and using.
So, here is my question to you: What are we doing wrong? How to we keep true to seemingly contradictory forces of “self-organizing teams” and “value vs. cost prioritization” and “progressive elaboration”?
