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

301–310 of 420 posts

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

#301

Post by freshhawk »

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.

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 the last decade to treat them as promises. So don't do the thing that you know will have a bad effect.

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

#302

Post by majikandy »

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.

I wouldn’t say Standup is terrible but one where you go round the room giving updates is almost useless. It’s not just you, most developers can do 8 hours work in an hour if they aren’t interrupted with meetings.

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

#303

Post by kryogen1c »

lazyasciiart wrote: post #292
kryogen1c wrote: post #184

Earlier quoted context omitted.

Im not a coder, so maybe the domain is different in a way i dont understand, but I agree with you 100%. Refueling nuclear aircraft carriers have projections start to finish, a half decade long. There are countless pre and co requisites with interrelated projects, not counting the mundane issues like material and manpower. I simply do not accept it is impossible to project a timeline for software. If someone stops you…

I'm not a nuclear aircraft carrier refueller, so maybe the domain is different in a way I don't understand, but it's ridiculous to need a five year plan to just refuel something, people refuel cars in five minutes everyday. I simply do not accept that it is impossible to refuel in a week or so, assuming it's a couple orders of magnitude more complex than refueling a car. Thats about how your comment sounded.

+1

However, your comment didnt help me understand. It doesnt help because even if i embark on something i have no idea about, even in total ignorance i can _bound the problem_.

I dont understand how a professional coder can approach even a problem and have no idea - you have to DO the problem, so what is your approach? Just start coding and somewhere between 5 days and 5 years you stop?

Planning meetings dont happen in a vacuum, so what kind of problem can you research but have literally no guess about its solution? Bear in mind, we're not talking edge cases (research grants or whatever), but coders hired to do a job.

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

#304

Post by rayanm »

kybernetikos wrote: post #158
rayanm wrote: post #112

Agile was dead to me when I finished my PhD and joined a company that paid a Scrum consultant more than they paid me to help us move tickets without knowing what was the project about.

You'll probably find that the most highly paid people in most organisations only have a fairly abstract understanding of the work being done. This is nothing to do with agile.

I am perfectly fine with paying more for a technical project manager, or a team lead who can help us glue things together and see the big picture. But I am not fine with hiring a consultant who doesn't know anything about our product and thinks that Agile has some magic to deliver products.

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

#305

Post by darkr »

ehutch79 wrote: post #201
kryogen1c wrote: post #184

Earlier quoted context omitted.

Im not a coder, so maybe the domain is different in a way i dont understand, but I agree with you 100%. Refueling nuclear aircraft carriers have projections start to finish, a half decade long. There are countless pre and co requisites with interrelated projects, not counting the mundane issues like material and manpower. I simply do not accept it is impossible to project a timeline for software. If someone stops you…

False equivalence. You planning 'how to put fuel in a nulean aircraft carrier'. For most software projects the equivalent question being asked is 'can you put some fuel in this thing we have'. When asking things like * what kind of fuel * is the thing a container or a vehicle * etc The response is often 'isn't it obvious, you're the developer you should know'. Can you tell I'm in the middle of training coworkers to o…

Very true; to expand on this metaphor, past experience has lead me to ask “does this thing actually need fuel, or is it in fact a bicycle?”; aka: please give me the full context - what are you actually trying to achieve and why?

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

#306

Post by bb88 »

gomox wrote: post #288
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…

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.

There's two issues right?

1. Inability to estimate effort. Admittedly an academic issue, and should be taught to all engineers in college.

2. Inability of management to deal with delays due to bad estimation. This might be caused by a "bozo explosion", say, (where inept managers hire more inept people underneath them.)

Edited to add:

3. Why do we keep making assumptions that management must be infallible? In any dysfunctional organization, it might just take one bad manager high up in the chain that causes pain for the entire organization beneath him.

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

#307

Post by ericmcer »

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…

If you are a good engineer and a valuable member of the team people will know, whether you hit your estimates or not. It’s almost like the better you are at actually producing the less you need to worry about the red tape. If you are invaluable and crushing projects no sane manager is going to fire you over your estimate accuracy, but if you are doing poorly and not producing they may point to it as a problem area. I have only worked for small-mid size teams though so maybe it is not like that for huge ones.

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

#308

Post by ryanthedev »

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…

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 earned per year or quarter. Look for trend.

IT leadership looks at amount of open stories and tasks that were moved from iteration back to the backlog. Over the span of all iterations.

This will ensure teams are breaking down work into actionable goals.

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

#309

Post by disqard »

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…

This was a good analogy!

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

#310

Post by bitwize »

gomox wrote: post #288
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…

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.
Post reply on HN