Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dear Agile, I’m Tired of Pretending (2018)

medium.com

Post reply on HN
Print view View original

281–290 of 420 posts

Re: Dear Agile, I’m Tired of Pretending (2018)

#281

Post by TheOtherHobbes »

50656E6973 wrote: post #269
bb88 wrote: post #262

Earlier quoted context omitted.

> Even bad estimates are better than no estimates. No estimate is clearly better. Here's a common story I've seen across multiple companies. 1. Marketing management asks Engineering management how long it takes to do feature X so they know when to launch the online ad campaign. 2. Engineering management then asks potentially good coder how long it will take. Coder replies with a time and "it's just an estimate." 3. E…

>1. Marketing management asks Engineering management how long it takes to do feature X so they know when to launch the online ad campaign. Why can't Marketing just wait until the feature has been built to launch their campaign?

Because campaigns have to be planned ahead too - anywhere between a few weeks and a year or so, depending on the size of the project and the company, and often timed to match big trade events.

And there's always the possibility that if you announce too late competitors will eat your lunch.

One way to handle this is to spend some time on a formal estimate. Two to four weeks of R&D to scope a project can help narrow estimates to something approaching realism. You'll still be wrong, but you're less likely to be hopelessly wrong.

Asking someone for an instant opinion is madness. That's not an informed estimate, it's just a guess, and usually worthless.

Re: Dear Agile, I’m Tired of Pretending (2018)

#282

Post by humanrebar »

matwood wrote: post #265
xwdv wrote: post #199

Earlier quoted context omitted.

No. Even bad estimates are better than no estimates. If you are having meltdowns your reputation is being tied too closely to your ability to give estimates. You must never turn estimates into a promise, always remind people they are estimates. Want to give fast estimates? Here’s how: 1) first determine the scale of the task? Is it a year, month, week or day kind of task? 2) Then, it’s just 3 of those units. The smal…

> Even bad estimates are better than no estimates. I disagree. The only bad estimates that are ok have to error on the high side. I have found that biz side may not like the longer estimate, but they much prefer that over missing a date.

Right. If they asked for a 95% confidence number, they would get something to depend on more whole heartedly. But that date will be too far in the future to be comfortable.

So they look for more of a natural median. And then are shocked when dates are missed more than half of the time (!).

So if you want honesty, ask for estimate ranges or 95% sure estimates. Then pareto your plan to hell and back so everyone understands the risk. Then reestimate periodically as you home in on completion.

Re: Dear Agile, I’m Tired of Pretending (2018)

#283

Post by humanrebar »

shados wrote: post #126
bougiefever wrote: post #88

I've been developing software for over 20 years, and I still can't estimate how long something will take me when I've never done it before. This uncertainty needs to become more than just a stick to beat developers about the head and shoulders with. Most of the time the PMs understand this, but there have been many projects where they just don't get it. I have suffered great anxiety from being forced to give estimate…

> Can we stop pretending we can forecast the unknown Within reason. Ive worked in orgs where there is no estimate at all, and that bring a different set of problems (unbound projects and no work getting done because of the complete lack of pressure). Now you're totally right: software engineers rarely do the same thing (or even similar things) twice, so estimating is somewhere between "very hard" and "impossible". "S…

> unbound projects and no work getting done because of the complete lack of pressure

Actual demos seem to help a lot here in my experience.

Re: Dear Agile, I’m Tired of Pretending (2018)

#284

Post by ScottFree »

rch wrote: post #274
50656E6973 wrote: post #269

Earlier quoted context omitted.

>1. Marketing management asks Engineering management how long it takes to do feature X so they know when to launch the online ad campaign. Why can't Marketing just wait until the feature has been built to launch their campaign?

Because if they launch on the original schedule with Partner X they get Massive Benefit Y that could make or break the product. For example.

This. Most developers either don't want to or can't understand that there are real and valid reasons for wanting a predictable software production schedule.

That said, I've only ever seen one software project consistently meet production deadlines. Is there benefit to committing to the original schedule with Partner X if there's no way you can deliver on schedule? Or is it one of those things where Partner X has committed itself and they have no real choice but to work with the sliding deadlines?

Re: Dear Agile, I’m Tired of Pretending (2018)

#285

Post by mizchief2 »

shados wrote: post #126
bougiefever wrote: post #88

I've been developing software for over 20 years, and I still can't estimate how long something will take me when I've never done it before. This uncertainty needs to become more than just a stick to beat developers about the head and shoulders with. Most of the time the PMs understand this, but there have been many projects where they just don't get it. I have suffered great anxiety from being forced to give estimate…

> Can we stop pretending we can forecast the unknown Within reason. Ive worked in orgs where there is no estimate at all, and that bring a different set of problems (unbound projects and no work getting done because of the complete lack of pressure). Now you're totally right: software engineers rarely do the same thing (or even similar things) twice, so estimating is somewhere between "very hard" and "impossible". "S…

estimating is either easy or impossible. You either have done it repeatedly and have data to show how long it took, or you have no fucking clue.

Focusing on the most important features of each module first, and then the most important of the next then the next with a focus on progress towards something useful is the only way to go.

When you have a consistent team and some tracking data to compare task size to hours required to complete, then you can start doing estimates for future work, but you never have to ask the dev team to estimate other than setting some relative size between tasks and trying to stick to the sizing system. I prefer Fibonacci story points, but it can be anything that has a number.

Re: Dear Agile, I’m Tired of Pretending (2018)

#286

Post by inlined »

inlined wrote: post #244

I’ve been a tech lead for 6 years and Agile has given me a lot of imposter syndrome because I can’t seem to make it work for me. The biggest point for our org is to cost work items and realize a consistent throughput for our team on which we can make scheduling predictions. Unfortunately my tasks tend to be nebulous. They involve investigating very large potential systems and breaking out smaller tasks, many of which…

To expand a little, since the org wants accurate estimates we need to accurately measure throughout and the total quantity of work. Though throughout trends stabilize pretty quickly, the system falls apart when one task reveals another. Accurately breaking down and costing every sub task at sub-week granularity for a multi-year project is an almost insurmountable task. It requires effectively doing all the work in your head.

I’ve seen one compromise and benefit to the system:

Compromise: push back on scheduling until the date you give for coming up for a date of completion. This works best during the final phases of development.

Benefit: with weekly throughput info, it’s easy to tell if someone is trying to do too much in a sprint.

Re: Dear Agile, I’m Tired of Pretending (2018)

#287

Post by ahelwer »

bobm_kite9 wrote: post #279
bobm_kite9 wrote: post #275

Earlier quoted context omitted.

I think this comes down to the idea that estimates are really for coordination. At least, I think that’s the best reason for using estimates. I wrote something about this here: https://riskfirst.org/Estimates

Actually I don’t really understand why all the HN posts on agile just devolve into a discussion about the difficulty of estimating. Surely there’s more to it than that?

Well, standup is also terrible. In addition, there's the general agile assumption that developers are capable of consistently producing X hours of work per day. Maybe it's just me, but I'm a bit more burst-y with my work habits than that.

Re: Dear Agile, I’m Tired of Pretending (2018)

#288

Post by gomox »

bb88 wrote: post #262
xwdv wrote: post #199

Earlier quoted context omitted.

No. Even bad estimates are better than no estimates. If you are having meltdowns your reputation is being tied too closely to your ability to give estimates. You must never turn estimates into a promise, always remind people they are estimates. Want to give fast estimates? Here’s how: 1) first determine the scale of the task? Is it a year, month, week or day kind of task? 2) Then, it’s just 3 of those units. The smal…

> Even bad estimates are better than no estimates. No estimate is clearly better. Here's a common story I've seen across multiple companies. 1. Marketing management asks Engineering management how long it takes to do feature X so they know when to launch the online ad campaign. 2. Engineering management then asks potentially good coder how long it will take. Coder replies with a time and "it's just an estimate." 3. E…

Oh come on. Any decent project manager understands the difference between an estimate and a deadline and plans and communicates accordingly. It's not rocket science. Stuff gets shipped on time all the time.

Re: Dear Agile, I’m Tired of Pretending (2018)

#289

Post by alexanderdou »

Perhaps I've just always been extraordinarily lucky, but I've never heard the developers I work with complain about our Pointing and Development cycle (and I'd like to think I do try my best to 1) proactively ask them for feedback and 2) recognize and squelch any of my own reactionary defensiveness that comes from feedback).

One thing I see a lot in the comments is about time estimates and the amount of pressure that that brings and the rarity in which it works.

In my teams we NEVER talk about time of delivery with Engineering. I've always been trained to think of pointing as an estimate of "complexity" (e.g. 1 point is roughly the complexity associated with a copy change).

Then, by getting a track record of historical points completed in a week, we can transform our way from feature => complexity => time.

Re: Dear Agile, I’m Tired of Pretending (2018)

#290

Post by ScottFree »

chrshawkes wrote: post #232
JustSomeNobody wrote: post #173

Earlier quoted context omitted.

Well here's the thing. Often I'm asked for my estimate in the same meeting I first see the story. I have no way of researching before giving an estimate. > ... and then if PM/boss don't understand there is not much you can do but probably look for a better gig. If only it were that simple.

It's even worse when your lead is giving timeframes for you...

I used to think that too, but is it really? If estimates are always wrong, then is there really much of a difference? Besides, the lead often has business related information that informs his decision of "this feature must take no longer than X amount of time or we're going to have problems with Y" where Y is often political and not technical.
Post reply on HN