Dear Agile, I’m Tired of Pretending (2018) • Hacker News Board

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

#401

Post by jboy55 » Tue, Jul 02, 2019, 4:47 PM UTC

matwood wrote: post #382

jboy55 wrote: post #296

Earlier quoted context omitted.

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.

What I've found is that when engineers are sensitive to giving estimates its a symptom of some sort of insecurity around their work. They're probably also feeling that they are 'outside' the decision making/power structure.

What helps is first identifying why an engineer is feeling insecure about their job, imposter syndrome, some sort of life events you may not know about. If the engineer hasn't been having issues delivering, then you want to really talk with them and find out what it is. Why do they feel they're going to get in trouble or 'beat up' if they don't hit the estimate. If they have been having issues, then you should be identifying why those issues have been having, but that is a whole different set of issues than what I think this thread is talking about.

If they are feeling outside, this is probably evidence that this engineer feels that they've been shut out giving input for the 'how' or 'why' questions surrounding the design of the project. They also maybe having resistance to opting into what the goal/product is. Perhaps the goal isn't clear, perhaps the goal isn't well defined, or there is some bigger issues.

Finally, if you as a manager aren't constantly getting estimates as the project is progressing, especially if you aren't using an agile framework, then you need to. If you are using it, have you pointed your backlog without input of the team? Are the scores stale and if you repointed, with new info the scores would be much different?

If you (anyone reading this) are a manager and you think your job is to get an estimate and drive your engineers towards that, then you are only doing only a superficial part of the job.

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

#402

Post by Redoubts » Tue, Jul 02, 2019, 5:09 PM UTC

freshhawk wrote: post #301

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…

> You must never turn estimates into a promise, always remind people they are estimates. The person giving the estimate isn't the one who does this. Other people turn them into promises, because that's what they were actually asking for when they asked for "an estimate". Giving some kind of uselessly vague estimate isn't particularly useful from an engineering perspective and everyone else has been trained by scrum t…

> The person giving the estimate isn't the one who does this. Other people turn them into promises,

Why is that your problem? If someone tried to hold me to such an estimate, I would simply say "I never promised this, in fact I explicitly didn't promise this. I'm sorry X lied to your face about this." Don't own other people's failures.

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

#403

Post by fuzz4lyfe » Tue, Jul 02, 2019, 6:20 PM UTC

TheOtherHobbes wrote: post #281

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

Sounds like marketing needs to be agile

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

#404

Post by chris11 » Tue, Jul 02, 2019, 6:22 PM UTC

jacques_chester wrote: post #73

In my experience, these discussions boil down to anecdotes at twenty paces. I've seen software development done very poorly and done very well, sailing under a variety of flags. But on an eyeballing there are far more bad experiences than good that get labeled "Agile". Whether this is because of causal differences or because it's easy to affix any label to anything (and most experiences suck regardless of the label)…

How do you like agile at Pivotal? I'm curious, they have some really strongly heard opinions about how to do agile correctly.

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

#405

Post by andyroid » Tue, Jul 02, 2019, 9:27 PM UTC

celticmusic wrote: post #385

Bartweiss wrote: post #101

Earlier quoted context omitted.

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.

That’s a point, and I agile development would not be possible without the internet. But working incrementally based off of customer/user input is only possible after the first release. What was observed here was the huge number of projects that would previously fail without ever getting that point.

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

#406

Post by notyourday » Tue, Jul 02, 2019, 10:10 PM UTC

karmelapple wrote: post #322

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…

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.

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

That's when the engineering lead or whoever was giving that as the answer is told that his services are no longer required.

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

#407

Post by notyourday » Tue, Jul 02, 2019, 10:11 PM UTC

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…

> No estimate is clearly better. Here's a common story I've seen across multiple companies.

As strange as it may sound to developers, the salary is paid by the customers, current or future.

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

#408

Post by dragonwriter » Tue, Jul 02, 2019, 10:16 PM UTC

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…

> Even bad estimates are better than no estimates

Bad estimates are worse than no estimates, but if you are doing work complexity estimation and measuring velocity (which you need to do to evaluate internal process changes, manage workload, and for lots of other purposes), you are incidentally gathering the info you should need for excellent estimates, which are not necessarily hyperprecise but are excellent instead because they can explicitly quantify uncertainty as well as mean expected delivery time.

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

#409

Post by dragonwriter » Tue, Jul 02, 2019, 10:21 PM UTC

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.

> 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

It's actually a better estimate than most software estimstes, because it isn't just an expected time but a range that results will usually fall within. It would be better if it included an explicit degree of confidence that th actual result would be in the range, and if it was centered around the average time it would take for events in the class.

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

#410

Post by dragonwriter » Tue, Jul 02, 2019, 10:24 PM UTC

bitwize wrote: post #310

gomox wrote: post #288

Earlier quoted context omitted.

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.

Any decent project manager who wants to keep their job will acquiesce to people further up in the org chart who want deadlines, not estimates, and who consider the difference between the two to be as fuzzy as it needs to be.

And any decent engineering team will accept that a project has deadlines and raise progressively more serious risks with appropriate explanations up the chain as the confidence that completion will occur before the deadline declines below near-certainty.

Deadlines can be legitimate project requirements as much as functional requirements are. Identifying practical conflicts between requirements is part of what an engineering team does. Managing resolution of those once they are identified so that the customer gets the best result achievable is what a PM does.