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

341–350 of 420 posts

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

#341

Post by sopooneo »

RogerL wrote: post #172
avgDev wrote: post #153

Earlier quoted context omitted.

I feel as you should be able to provide an estimate even if it something that you have not completely done before. One should spend some time to gauge how much of this new thing is really "new" and what parts should be easy to figure out. Then, try to look at resources about those unknown parts, and that should allow to provide a rough estimate. And when road blocks come up just communicate early, and then if PM/boss…

Great! Please let us know when cancer will be cured. In other words, "I don't know" is sometimes a complete answer. I don't know. Period. This is supposedly one of the main points of this religion (agile). Some things are unknowable. So you move ahead a bit, and reassess. If you are scrumming, that is usually 2-3 weeks, and don't get me started on that arbitrary limit. But, you try to move forward for a bit, learn so…

More than a day but less than a millennium. I am 99% certain on that.

Granted that’s more broad than a PM (or humanity) would want, but it is SOMETHING.

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

#342

Post by Aeolun »

bb88 wrote: post #331
redhale wrote: post #315

Earlier quoted context omitted.

I cannot believe how much I love the term "bozo explosion". I see this situation all the time as a consultant, and now I have a fantastic term for it. Thanks for sharing!

I'm a consultant as well. You go through enough companies and you can see how much of a problem this actually is. As much as I did not particularly care for the management style of Steve Jobs, as far as I know, he was the one that first used the term. https://guykawasaki.com/what-i-learned-from-steve-jobs/ Edited to add: This just happened recently. Maybe you'll appreciate it. 15 years ago or so (before the term "tec…

> If you ask customers what they want, they will tell you, “Better, faster, and cheaper”

Amazon took that to heart. Seems to have worked out for them.

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

#343

Post by Aeolun »

ahelwer wrote: post #287
bobm_kite9 wrote: post #279

Earlier quoted context omitted.

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.

Shouldn’t it average out over 2 weeks?

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

#344

Post by bb88 »

sopooneo wrote: post #338
bob33212 wrote: post #334

Earlier quoted context omitted.

My advice would be to live in the real world. We don't know how long it is going to take. Just like if you go to turn on your car and it doesn't start. Maybe it was a minor issue and the next time you turn the key it will start. Maybe there was a short circuit and the car is totaled. A passenger asking you when you are going to get moving is no help.

If your car won’t start, it will take more than a second, but less than a year to fix. That is a bad estimate, but better than no estimate for a space alien that doesn’t know what a car is. PM’s are space aliens.

The only tool the space alien's PM has is a deadline. "Do X by this date or else." Because he has no hope for understanding the true problem domain before the project deadline -- just like a space alien can't be expected to learn english in 4 days.

A PM with a deep understanding of the software process, can ask insightful questions, identify and possibly mitigate many of the issues beforehand. So when it gets to the software lackeys, many of the resource/architectural issues may have been solved.

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

#345

Post by ksenzee »

madeofpalk wrote: post #219
Bartweiss wrote: post #123

Earlier quoted context omitted.

> One side is signed up for incremental delivery, and one side is set up for a fixed scope and deadline and the result is misery. This is a brilliant summary, thank you. The best 'agile' experiences I've had are situations where the 'clients' are directly involved, often within the same organization. Instead of a hard scope or deadline, there's just a shared interest in producing a valuable product efficiently, and t…

> waterfall contracts, developed by an internal simulation of agile. We call this wagile

We call it scrummerfall.

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

#346

Post by bb88 »

mbesto wrote: post #336
bb88 wrote: post #333

Earlier quoted context omitted.

I'm sorry, but if you're spending $500k or more based upon one engineer's "estimate" (for which you're paying $10k/month) then something is more fucked up in that company than what appears on the surface. But I agree with you, if the engineering management can't budget and prioritize work to get done, that's a larger issue.

> but if you're spending $500k or more based upon one engineer's "estimate" (for which you're paying $10k/month) The $500k was just a random number I came up with. Budgets wildly vary based on whether they get allocated weekly/quarterly/yearly/etc. And also it's never "one engineer's estimate", it's usually a project manager who works with N number of engineers to come up with an estimate.

And that's the way it should be.

But keep in mind that if a developer is in a sprint, he might start adding tickets to the epic because of technical/organizational issues. Suddenly the epic might look 3x more work than was originally planned. Note this is not theoretical, as it's happened 3 times to our team already this year.

But meanwhile in the example I gave, the developer gets held accountable still for not making the correct estimate. Management just passes it up the chain rather than trying to increase the confidence around the estimate.

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

#347

Post by sbov »

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…

I do something similar, except don't assign to a number. My back of the envelope estimates are: hours, days, weeks, months.

This gives people enough information as to whether or not a change is worth it. If the difference between, say, 2 and 5 days makes or breaks the feature it's probably not worth exploring in the first place.

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

#348

Post by DigitalSea »

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, always remind people they are estimates.

Herein lies the problem. Many companies that do "Agile" fail to realise that estimates are just guesses, they're not accurate and yet, the issue is companies taking these estimates and holding developers to them. That's the real problem.

It's all well and good to say, remind people they're only estimates, but many of us who have been in this industry longer than a minute knows that estimates nine times out of ten are taken as promises and that's when we get crunch and burnout as developers are forced to achieve the impossible with excessive hours.

Deadlines need to drop dead. Code quality suffers when you put a timeframe on it.

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

#349

Post by bb88 »

Aeolun wrote: post #340
bb88 wrote: post #312

Earlier quoted context omitted.

> Any decent project manager who wants to keep their job will acquiesce to people further up in the org chart In my book, that project manager is not "decent". A decent project manager would recognize the situation for what it is and leave.

Then there won’t be any good project managers, as I’m fairly certain most executives do this shit.

That's the problem I've been seeing in non tech based companies. IOW when tech isn't what they're selling.

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

#350

Post by braythwayt »

Bartweiss wrote: post #101
andyroid wrote: post #59

Earlier quoted context omitted.

The difference is that of ivory tower planning and the following phases of development, testing and a “big bang” release (waterfall) vs working with an MVP with the purpose of releasing as soon as possible and then work in iterations based off of actual feedback and demand (agile). If you manage to nuke your budget or create a monster of a code base already at the MVP stage no methodology is going to save you.

I really do believe agile (or at least "not waterfall") has reduced the rate of major software flops. But I'd be fascinated to know how often it turns failures into successes, versus revealing failures earlier in the project cycle. Both are valuable, obviously. It's just interesting that part of Agile's value is in revealing engineer dysfunction or fundamentally bad ideas at the MVP stage instead of the completion st…

Revealing failure early is at least as valuable as succeeding more!

Imagine a system that couldn’t help you pick winning stocks, but It could cap the losers at 10% loss, maximum. You’d get rich. Very, very quickly.

Post reply on HN