The battle I’m sick of fighting
Hey all – I know it’s been forever since I’ve posted. I feel like I should have went back to the just showing up post a few times. As some of you know I’m getting my masters degree (done in May) and have switched companies (a few times). Life is crazy, as many projects are. On a side note – I’m working on a research project on women’s involvement in the Agile community (to complement #WomenInAgile), so stay tuned over the next couple months for more details on the results and how you (even if you’re not a woman) can participate in a survey to help — I promise it’s less time-consuming than the State of Agile survey.
Anyway back the reason for this post. I’m going to rant a bit. <rant> I am so sick of having estimating battles. Sure #noEstimates can work if the team understands what they’re doing, has good leadership, a decent product definition, and oh so many other things that can affect estimation and delivery. I love the ideas of cycle time, smaller chunks and limiting WIP without having to put a number on it, but in my practical experience it can be harder than estimating and management doesn’t go for it. For most teams, especially starting out together on a new product, with a new product owner, with BIG ideas and who wants ALL the things (you know the ones I’m talking about), #noEstimates is not viable. End of story — to be discussed in another post of when I get torn apart in the comments or bombarded with #noEstimates success stories and tweets, I’m sure.
So let’s skip that “to estimate or not to estimate” battle for now and say I won you over and the importance of estimation gets through – or you’re just curious about what I have to say and decide to continue reading for the mere entertainment of my passionate and slightly annoyed tone. The next obstacle often turns into the points versus days battle – that’s another old friend. The purpose of this post isn’t to say what is right or wrong – my consultant answer (if I were a consultant) is, “it depends”. Again, it depends on the team, the org, the product, the complexity etc.
I just find this battle at every company I’ve worked at and it chooses unsuspecting (sometimes) times and avenues to rear its ugly head. Honestly I don’t care if you estimate in baboons or dassies (I just got back from South Africa) as long as you’re estimating and comparing work items to one another utilizing past experience– because realistically most teams need to estimate in some form. Even if they don’t NEED to, most management want some type of metrics to relate to predictably versus a promise of having it done. They want a plan, a good guess, an estimate with something to back it up — remember trust is built on prior interactions and history. Once teams can start providing this consistently, showing their predictability and transparency, and earning a reputation and trust, then talk to me about #noEstimates. Until then, measure something, estimate something, and adjust as necessary (and I guarantee adjustment will be necessary). The act of estimating is something I won’t budge on and will advocate and battle to the end (even though it can turn into an earworm that just won’t get out of your head, i.e. now)
agile cycle time delivery estimate ideal days MAOL metrics no estimates predictability purpose of estimating relative estimates relative estimating research project scrum story points team maturity transparency women in agile