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

321–330 of 420 posts

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

#321

Post by Redsquare »

ryanthedev wrote: post #308
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…

Features and stories should be completable in the span of an iteration. Epics and Features are prioritized by the business and product. They can be expected to slide from iteration to iteration. Any User Story or task should be expected to be completed an a single iteration. If you keep having open stories stop bringing in a complete story. Just assign tasks. Features and Epics are pointed. Business looks at points e…

So said the 2 day scrum master

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

#322

Post by karmelapple »

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…

What is plan for the worst in a scenario with literally zero estimate?

“It may take 0 to 3 years” ?

“We literally have no way of knowing?” “Not even a ballpark?” “No.”

This is what you’ve proposed with no estimate, and this seems extremely unhelpful towards the goal of helping all groups at least have some idea when certain “next steps” can be accomplished.

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

#323

Post by loup-vaillant »

xwdv wrote: post #199
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…

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…

> You must never turn estimates into a promise,

Whoever asked you for that estimate will do that for you…

> always remind people they are estimates.

…even if you remind them. I mean, the reasonable ones won't, but many people aren't that reasonable.

I've been in an interview last week where they told me the teams were strongly committed to the features they planned to do each sprint. Which I interpreted to mean that their estimates are promises.

> Want to give fast estimates? Here’s how:

My, this looks like it could actually work. I'm going to try it right away.

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

#324

Post by mixmastamyk »

b_tterc_p wrote: post #49
quadcore wrote: post #13

Agile never gave organizations a holistic, viable alternative to Waterfall. Because there’s a difference between theory and practice. Product work is more about practice. When we complain about “AINO” (Agile In Name Only), we’re not being honest with ourselves. I agree with most of the article. Specially the keep-learning part. All Agile did was put software development teams unfairly under a microscope. I believe Ag…

> You have to realise that before Agile, a fair portion of the software development projects that were started would simply bust and never get shipped. The code is a complete monster or the budget is nuked. This still happens, all the time?

When that point is reached much more quickly, it saves $$$.

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

#325

Post by ehrm2017 »

xwdv wrote: post #199
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…

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…

Great you know how you work best.

There are other ways. The best of humanity have a wide range of methods they use to get shit done at a level most of us dream of.

So I have a hard time taking a straight jacket process like you suggest as some sort of panacea. It’s essentially another manifesto. What’s the expiration date on this.

Everyone goes on about the value of writing less code, and here we are incentivizing manufacturing line processes for crafting more code?

Note the authors of things like the Phoenix Project: rich Silicon Valley types. We’re just discussing how to be better assembly line workers for tech aristocracy.

Figure out how to build your business in such a way it works for the business. Google didn’t get big because it has perfect process; it can and often is a mess. It got big solving it’s problems and monetizing the solution (every company will need to search for digital files, send email, edit docs, etc).

Figure yourself out, compare with others. There’s is no one size fits all to thinking about problems and even the biggest winners don’t have all the customers there is. Why isn’t Gmail the only email solution?

There’s never a perfect process.

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

#326

Post by theptip »

snarfy wrote: post #270
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…

You go to the mechanic and tell them your car won't start - nothing happens when you turn the key. You ask them how long it's going to take to fix and how much it will cost. They don't assume it's the starter and tell you it will be $400 for parts and labor. They tell you it will be $150 diagnostic fee and the diagnostic will take two hours. Then they call you and tell you the cost to fix and time it will take. For w…

> software engineers don't have the luxury of doing a diagnostic

These are called "spikes" in the agile community (no idea why), and "prototypes" elsewhere.

If you feel that the error bars are too wide on your estimate, you should build the minimum prototype required to reduce the uncertainty to tolerable levels.

I like to schedule these at least a sprint prior to kicking off the main task, so that you can benefit from the improved estimate accuracy when actually scheduling the thing.

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

#327

Post by theptip »

dymk wrote: post #186
matthewhartmans wrote: post #162

Earlier quoted context omitted.

I think this is where a 'spike' solves your problem. By creating a spike, you can do some initial investigation into how the code is written, what's involved, how long it will take, etc. Once you have completed your spike, you can come back to the original piece of work and give a better estimate based on your findings.

Maybe a spike takes a week. Maybe a spike takes an hour. I can't estimate that. Which would be fine, but then management or the PM expects me to loop back around when a spike is complete. I'd rather just continue engineering a solution when I'm done investigating, which is the natural progression of things. I'd rather treat {get requirements, investigate, implement, debug, deploy} as a single atomic task, rather than…

> Maybe a spike takes a week. Maybe a spike takes an hour. I can't estimate that.

Timebox it then! If you think the spike is going to take a day, and it turns out you'd need a week to even get the prototype working, then that's a successful spike -- you dramatically increased the lower bound on your estimate.

(Sadly by the asymmetry of estimation it seldom happens that you think it's going to take 5d and it ends up taking just 1d).

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

#328

Post by [deleted] »

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…

[deleted]

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

#329

Post by bsder »

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?

Except that you're wrong.

We predict quite well, thanks. The problem is that everybody ignores the predictions.

Most people predict approximately where the 50% probability is with maybe a little fudging. And they tend to be pretty good at it.

The problem is that everybody just adds those up. And that's the disaster from a statistical viewpoint.

Things can only come in so early, but they can come in infinitely late. A blown schedule on an early dependency throws everything out of whack far more than a late dependency would.

We can roll these up in a proper way. We can run Monte Carlo simulations and get "real" numbers. People have done this and the results are remarkably accurate.

The problem is that someone in management will always undercut the realistic estimate for personal gain. And then wind up longer than the estimate at the end.

And, the worst part is that this is RATIONAL. The only way to get a project completed is to start and get the sunk-cost fallacy rolling in the powers-that-be.

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

#330

Post by [deleted] »

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…

[deleted]
Post reply on HN