My Agile Team: On Time Estimates

February 23, 2009 by mattgrommes

Picture courtesy of John-Morgan on flickr

Welcome to the second installment of my new series, My Agile Team, where we're following my team's progress in getting more Agile and in moving from one project to multiple projects. Right now, we're still trying to put out fires and finish up the big project. We hope to start adding in things from our other projects in a couple more sprints.

The fires I mentioned are our term for the emergency stuff that pops up and has to be taken care of Now. This is usually things that customers will see; their bill being the most important. These seem to still pop up every couple of days so we have to drop our Sprint tasks and take care of them quick, fast, and in a hurry as my Dad says. It looks like we've probably stomped out the bulk of the underlying problems causing the most important fires so this coming week I'm hoping will be a little less crazy (of course now that I've said that, we're in trouble). Once we all have some distance on these issues my goal is to do a deep retrospective just on these issues that have come up since Go Live and see if we can root out anything we should have differently for next time.

One thing I'm struggling with right now is trying to get the Higher Ups to understand why we shouldn't use real time estimates on the stuff left on the big project. Read on for my thinking on this and how I'm trying to influence things.

One of the big problems I talked about in the My First Agile Project series was lack of management buy-in on our project. They all knew we were doing Scrum and supported our efforts, but I don't think the real nuts-and-bolts of the process sunk in.

One of the places I'm sure we didn't do enough education is on putting estimates on tasks. Our manager wasn't a part of the Scrum team during the big project so she doesn't really know what we used to do. Now that we're trying to finish up, she wants real time estimates on tasks to tell others in the company when we'll be done. I appreciate the idea behind this, but I'm not sure about the best way to give her and the company what they're asking for. I gave her my copy of Mike Cohn's Agile Estimating and Planning with some relevant chapters picked out but that's obviously not going to be enough on its own.

Obviously part of the point is that we don't know how long these last things will take. All we can do is put rough "ideal time" estimates on them but then as Cohn notes in the book, you run the risk of people not differentiating between "ideal time" and "real time". Since we really have very little in the way of big items left on the backlog, our compromise for now is putting ideal estimates on with the understanding that there are fires to be put out that seriously affect those times. Then we have to hope that this understanding gets communicated up from our manager to those higher in the chain. This isn't optimal but I'm hoping once we're a couple more sprints out and putting in other project tasks into the backlog that we can come to a better understanding on estimates and communicate that across management.

This is a tricky time for our team. On the one hand, we launched the product finally and people like it. On the other hand, we were very late and we're still putting out fires. Our official manager is now back to officially managing us and hadn't really had a lot of immersion in the Scrum process during the project. So we have to educate her, get back some lost credibility due to the lateness of the project, get back on track with Scrum, and finish up the last issues. We had a joke in the department that Only 3 Things Can Be Top Priority but we've recently increased that to 10 as having 3 Top Priority things is now seen as kind of a luxury. I fear if we don't get our act together on multiple fronts all at once, the company could really start to see the Scrum/Agile process as a failure and we could go back to our old ad-hoc, somewhat random task assignment process which none of us wants.

My biggest piece of advice for trying to turn your team into an Agile team is to get on the same page as a team and educate the heck out of everyone. Each other, managers, everybody. Have your books, articles, presentations in order and bring them out at every opportunity. If you have to give in on a piece of the Agile process, make sure everybody knows what the tradeoffs will be. Speak up. If the process is important to your team, it's important enough to speak up about, even to management.

Well, that's it for this installment of My Agile Team. I'll be back next time with what I'm seriously hoping will be the last sprints of cleaning up the big project and putting out fires. Thanks for reading and as always, if you have advice or comments please make them below. I love hearing from everybody and obviously, I need the help. :)

Previously in My Agile Team
My Agile Team: On The (Scrum) Road Again

Permalink