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

271–280 of 420 posts

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

#271

Post by matwood »

Isamu wrote: post #157
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…

>That's when I knew it was time to leave that team Currently in that situation. My "agile" estimate blew up by a factor of as much as 10, just because the ask was conceptually very simple, even to the domain experts I consulted. And by bad luck the way I was implementing the story it happened that the issues unfolded one-at-a-time, rather than somewhere in the beginning where we could have broken things up into more…

In retro we would have asked 'what happened and could we have avoided this?'. Then we would have broken up the now expanded unfinished work, and asked the PM if they want to continue knowing it is 10x more work than expected. If yes, cool we pull in the tickets next sprint and keep going. If no, we wrap up anything in progress and maybe come back to it later.

Shit happens. The end of a sprint is there to highlight issues like this so the business side can re-evaluate if continuing is still a good idea.

I don't want anyone on my team working nights and weekends to finish a sprint task (system going kaput is the only time I would reach out for help). Anyone letting their team work normal sprint tasks on nights/weekends is not going to keep their team very long. They will either quit or burn out and stop working.

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

#272

Post by marapuru »

lordleft wrote: post #7

The best way I've seen agile described is "designing code in a way that acknowledges change.' I think there's a lot of value in understanding that you may have to go back to the drawing board when designing parts of your program. I have little regard for the entire industry that has risen up around agile, however.

Yeah, coming to the point where it's never completely finished. You just always anticipate on going back.

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

#273

Post by bb88 »

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?

Lots of reasons:

1. Marketing management is full of idiots.

2. The coder's estimate is used to tell the CEO when a product will be rolled out. Who then questions why it didn't get rolled out on time.

3. Marketing gets a bonus for rolling out ad campaigns on time.

4. Marketing is using this for their big trade show coming up and wants to make a big announcement for maximum impact.

Why do you assume management is always competent?

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

#274

Post by rch »

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 if they launch on the original schedule with Partner X they get Massive Benefit Y that could make or break the product. For example.

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

#275

Post by bobm_kite9 »

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?

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

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

#277

Post by thrownaway954 »

I just always double what I think it will take. I've been doing software now for 20 years and I have NEVER seen something come in on time. If I think it will take a month, I say it will take two. This has saved me more than I can count since I pad for the unseen circumstances that will occur.

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

#278

Post by galaxyLogic »

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…

I usually reply: Give me a week to look into it then I will have more insight into how long it might take.

But you are right the problem is you can't estimate (correctly) how long it will take to do something your organization has never done before, that's what should be made clear to them.

At the same time it is true that estimates get better as we start working on it, and the work can start by focusing on the unknowns to figure out how difficult they are to do. If that is a plan they agree to.

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

#279

Post by bobm_kite9 »

bobm_kite9 wrote: post #275
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?

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?

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

#280

Post by mizchief2 »

The whole point of Agile is to force the entire organization to recognize the fact that we don't know how long it will take to crate a satisfactory product. That doesn't mean just dev time but also figuring out what you want it to actually do throughout the process.

Instead of thinking you can write a perfect requirements document, then can just design and build it (waterfall) doesn't work.

The idea that you can have any sort of meaningful estimate even when you don't have perfect requirements is insane. Having an estimate with perfect requirements doesn't even work.

The most effectivly analogy I've used lately is: "Take your car to a mechanic and say "My car is making a funny noise, how long will it take to fix?" and see what kind of response you get"

Post reply on HN