Live data from Hacker News

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

medium.com

381–390 of 420 posts

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

#381
post #332

Earlier quoted context omitted.

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.

I work as a sound mixer for film and estimating how long it will take is always hard, but I never really got a bad reception when I just said: I canlt tell you unless I see the thing. Hell if you ask a mechanic to fix your car they will also have to check the thing first before deciding how long it is going to take. This is the professional thing to do: gauge the situation, take tour time to figure out the scale of t…

Right, but there's a big difference between "Don't estimate until you've done your due diligence" and "Don't estimate".

It's perfectly reasonable to say "This is a big project, it'll take me a week to know where we stand"- there, you've provided an estimate of the scoping task and promised an estimate in the future as well.

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

#382
post #296

Earlier quoted context omitted.

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 is…

I've had to give estimates for my entire 20 year career, half of which wasn't 'Agile'. So first, Agile has nothing to do with this, in fact, Scrum tries to over come this by splitting up tasks into smaller chunks with frequent demoing, re-prioritization etc. It was much worse before this. But to everyone, if management is going to beat you up with your estimates, maybe find a place where management doesn't? The patho…

> Its the managers who beat up employees.

Agree completely. There is a difference between management pushing and beating up though. Sometimes I wonder if people get upset at normal pushing/asking for clarification. I've seen both from management, but have also seen engineers get unreasonably upset at simple questions around an estimate.

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

#383
post #342
post #331

Earlier quoted context omitted.

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.

They did? In what way? When I look at the online ecosystem for buying things in the EU, Amazon is consistently the one that can't promise I will get what I order, can't promise when it will come and can't make it easy to give them money. The only thing they do right is that they're theoretically cheaper, but then because you might get a product that doesn't work (and it's very hard to solve that issue to a standard that you'd expect as someone in the EU) the cost saving benefit goes right out the window.

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

#384
post #299

Earlier quoted context omitted.

I want to work where you do, where friction is negligible, cows are perfectly spherical, wind resistance is never a factor, all functions are continuous and differentiable across their entire domain, and all project managers are decent.

I'm not saying the story is implausible, but I dispute the idea that estimating software development efforts is an intractable problem that is better left unattempted.

Estimating things is important and valuable, but as soon as you get large corporate structures and multiple levels of people communicating involved it becomes a really bad idea. That's why it shouldn't be attempted in those kinds of situations.

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

#385

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…

I'd be more inclined to give the credit for less software flops to the rise of the internet and the ability to update easily.

Even traditional software projects are now much more incremental due to the ability to update once a week (FF, chrome, etc).

That's had an effect regardless of agile.

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

#386
post #270

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…

Often, you think it is a car, and then when you start to work, you realize it is actually an octopus

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

#387

You don’t hear the name Joel Spolsky much any more, but he was pretty influential in software process thinking in the 90’s - not really for being particularly insightful or original, but more because he was one of the first people who thought of writing a blog about software design. One of his early “observations” about software project management was that “you wouldn’t buy a pair of jeans without knowing how much th…

managers and business leaders make decisions based upon those estimates.

Imagine if that cable guy coming your house said between 1 hour and 2 weeks. Good luck making anything approaching a good decision surrounding the cable guy's visit.

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

#388

Earlier quoted context omitted.

In the spirit of that second paragraph - focusing on outcomes, not specific implementations - here's a rewrite: Original: > So…what’s the way out? It’s a smart focus on clear outcomes, not output, with roadmapped outcomes replacing planned milestones, with trusted product teams, not project teams, empowered to vet assumptions and discover the minimal path to value. Rewritten: > So… what’s the way out? It’s a focus on…

Interesting, I’d interpret “roadmapped outcomes replacing planned milestones” to mean there should not be predetermined dates and deliverables (planned milestones), but rather, a sequence of value-delivering outcomes (roadmapped outcomes).

A relative order of outcomes could also work, yeah. You'll have a date in there somewhere, though, even if it's not driven off the amount of work. Could be "and if we can't achieve this outcome by X date we give up on this whole outcome".

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

#389
post #342
post #331

Earlier quoted context omitted.

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.

They were the first that made online retail work. Plus there's the whole AWS thing.
Post reply on HN