Hacker News Reader

Comment by mihaigalos | Hacker News Reader

I loved this article.

Countless times I had to estimate Jira "tickets" (actually called issues in Jira terminology) in hours. To this day, I fail to understand why and I haven't gotten a pertinent answer other than "the business needs it for planning, they're paying us, so you do it."

Yet this contradicts at least 2 Agile Manifesto pillars:

1. People and interactions over processes and tools (fostering the estimation ceremony + booking time rather than actual interaction or developer happiness).

2. Reacting to change over following a plan (plan-the-work and work-the-plan over reacting to change).

How do you even "do" estimates?! Clean Agile (ISBN-13: 978-0135781869) says "Estimates are never commitments. They are guesses."

So it seems the business is trying to get a commitment out of an estimation, at hour granularity.

What are your thoughts here?

View on HN

Businesses want to be able to forecast and goals are often set aggressively and ahead of knowing whether they are achievable. There are three basic levers to wiggle at that point. Money, time and project scope.

Money can only really be applied early by staffing up, adding more people to a late project will invariably make it later. Thanks Mythical Man Month.

So for anything in flight that looks like it will miss a desired goal you can only really change the delivery date or reduce project scope.

But you also need to know you’re going to miss so you need some idea of how much work is left and how quickly you’ll get through it. Detailed estimates are a reaction to this along with the idea of measuring ‘velocity’. I’ve never seen either work well but people seem to cling to the idea that next time it’ll help them get it right.

One of the funniest Agile meetings I’ve been in had a producer explaining the state of the project. Slide 1: Velocity doesn’t mean anything outside of the team it’s for, comparisons don’t make sense. Slide 2: A line graph plotting each teams velocity against one another. Cue any useful discussion derailed because people want to know how we can get everyone’s velocity up to what looks like the best teams.

There’s a lot of dysfunction in business and a lot of winging it without really trying to understand why things are being done. You get a lot of odd practices spread around because project success is not necessarily because of “good leadership” but often project success is the measure used for leaders. A couple of wins and you can gracefully fail upwards believing in your own bullshit.

Indeed. This is the best description of the conundrum of Agile I have read so far

Reply on news.ycombinator.com