Live data from Hacker News

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

medium.com

311–320 of 420 posts

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

#311
post #53

Agile never gave organizations a holistic, viable alternative to Waterfall. Because there’s a difference between theory and practice. Product work is more about practice. When we complain about “AINO” (Agile In Name Only), we’re not being honest with ourselves. I agree with most of the article. Specially the keep-learning part. All Agile did was put software development teams unfairly under a microscope. I believe Ag…

I was interested in comp sci precisely because I didn't have to talk to people, an area where every interaction is a performance. I want to be alone - what's so wrong with that?

Nothing is wrong with that, but if you want to work like that, don't be a software engineer

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

#312
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.

> 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.

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

#313

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'm the same way but only about 15 years experience. I have a friend recently retired who has done a wide variety of software development since the era of punch cards (at least 40 years development) and he agrees with me entirely. I'm not sure how people can provide any reasonable estimates, especially these days when technology is shifting even faster under your feet unless it's a clone of something you've already d…

> Everyone is typically happy... the fact is, my estimates are garbage.

If people are happy with your estimates then they are good estimates.

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

#314
post #45

I was prepared for our weekly "I Hate Agile" post, but this one is actually really great. It's a lot of the arguments I make to Agile haters. The fundamental problem that drives most agile failures isn't in the team's execution, it's in the business' expectations. 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. I think this article makes…

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

In large enough orgs, internal clients can end up being just as bad as external clients, or even worse since they have a direct line to your PM, can track your feature board, etc. yet there is basically no sense of camaraderie or shared goals.

I'd say generally IME they are still preferable, but occasionally can be more painful.

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

#315
post #306
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.

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

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!

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

#316
So, Agile solved one problem when requirements are less than clear. Small batch sizes improve responsiveness, costing a bit of throughput. Like the old kernel HZ setting. Now you've got 99 problems, and responsiveness ain't one.

Yet folks expect Agile to solve everything for some reason, and forget all the other issues around bags of meat working together. Those continue to need handling and still get out of control at times.

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

#317

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…

[deleted]

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

#318
post #262
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…

I’m sorry for your bad experience, but some companies are able to do this well.

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

#319

Earlier quoted context omitted.

I think there is a way to give an estimate (have been doing it myself for a decade), even for dependencies that are not known from the start. (I mean, reasonable dependencies. No one can account for unknown unknowns, but the software engineering field is not an art, more of a skill, we do have well established processes to minimize the surprises). Is this something that HN audience is interested in?

> Is this something that HN audience is interested in? Are you teasing ? Yes, we want to know! Though frankly I'm incredulous.

No, I wasn't teasing, but I wasn't sure that people would find it interesting (at least, this was my expectation based on experience).

I tried to describe the process somewhere in this thread.

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

#320
post #262
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…

> Hope for the best, plan for the worst.

Oh dear, have you ever spoken to a finance department before?

Here's a common story I've seen across multiple companies[0].

1. The Finance department alots the marketing department with a $500k budget.

2. Marketing department blows through the $500k budget on the engineering department and has no productive app to speak to.

3. The Finance department goes back to the Marketing department asking what happen to all of the money they gave them.

4. The Marketing department says "well engineering told it was agile, which meant they didn't know when it would be done and for how much"

5. Finance department: "Ya, you're not getting a budget ever again from us"

> No estimate is clearly better.

Sorry, but this is not how the real world works. Agile assumes a perpetual budget, which is not realistic for most businesses in the world.

[0] - Personally seen among 100+ and counting.

Post reply on HN