Agile at 20: The Failed Rebellion • Hacker News Board

Re: Agile at 20: The Failed Rebellion

#101

Post by rlonn » Sun, Jul 25, 2021, 7:50 AM UTC

AndrewKemendo wrote: post #41

The fundamental problem with Agile is the fundamental problem with all product development: The customer doesn't know what they want Agile assumes as a first principal that including the customer throughout the development process will align the building team and the customer to come to the same conclusion. This is almost never actually true. Having built and managed a lot of products I can state fairly confidently t…

You’re right that customers don’t know what they want and that can make it a bad idea to include them in the dev process directly. But is that what Agile is about? I thought it was about iterative development. As a long time product dev I know that you want to follow your own vision when building your product. You let your vision be influenced by customer feedback for sure, but you should always second guess the feedback, never take it at face value, never just build something because a customer asks for it - that would be Henry Ford trying to breed faster horses.

Re: Agile at 20: The Failed Rebellion

#102

Post by feoren » Sun, Jul 25, 2021, 7:52 AM UTC

ipaddr wrote: post #84

hyperman1 wrote: post #70

Earlier quoted context omitted.

I'll give 2 examples. One was a CEO who hadn't any technical background, but he knew what ICT could and could not do for his company. One day we rewired all of our network, a massive weekend job. He was there, even if the only thing he could do was pulling network cables out of bags and straightening them. He saw who and what worked or not, he saw where we struggled even if he didn't understand a word of our technica…

That's not a CEO job. His job is to make sure the enterprise is funded and sets a vision. The first example must be a small company. 2. This sounds like a manager in an enterprise level company If you choose to work where a multi-level manager structure exists you should give that manager respect because he has to navigate a political landscape that takes certain skills. Besides managing people and knowing what custo…

And how many hours per day does it take to "set a vision"? How do you develop this vision if you know nothing about the company you're running? This is how you end up with these awful celebrity CEOs who wouldn't notice if you swapped the company they're running with one that produces toothpaste. They're too busy on CNBC and Fox Business talking about their amazing "vision".

Re: Agile at 20: The Failed Rebellion

#103

Post by brakmic » Sun, Jul 25, 2021, 7:53 AM UTC

The problem was described more formally as "Dark Agile" some time ago.

http://darkagilemanifesto.org/dark-side-of-agile-janes-succi...

Re: Agile at 20: The Failed Rebellion

#104

Post by tablet » Sun, Jul 25, 2021, 7:56 AM UTC

There is an article that explores the same problem "Post-agile process agnosticism" [1]

The main idea is that (as a programmer):

"You don’t give a fuck about process name, until you have full rights to modify and change the process."

[1] https://medium.com/fibery/post-agile-process-agnosticism-d4a...

Re: Agile at 20: The Failed Rebellion

#105

Post by watwut » Sun, Jul 25, 2021, 7:58 AM UTC

outsomnia wrote: post #100

baxtr wrote: post #97

Earlier quoted context omitted.

It’s easy to blame management. In my experience the radicalism of some agile coaches and scrum masters helps to fuel the divide significantly.

You know why it's "easy" to blame "management"? Because they often don't understand the technology question or even what the issue is, but insist to intercept every decision.

But agile project get effed where management is not messing into internal process too. Developers make agile into hell too.

Re: Agile at 20: The Failed Rebellion

#106

Post by sorokod » Sun, Jul 25, 2021, 8:01 AM UTC

The basic premise of Agile is that it is a part of an adversarial system. The adversaries are "devs" on one hand and "business" on the other. While the purpose of the devs is to be an executive arm of the business, the actual goals of each are coined in different languages to the point that they are frequently not aligned.

It is important to recognise this, and carefully manage the necessary give and take. Finding the right balance is tricky and higly context-specific.

Re: Agile at 20: The Failed Rebellion

#107

Post by lugged » Sun, Jul 25, 2021, 8:03 AM UTC

rlonn wrote: post #101

AndrewKemendo wrote: post #41

The fundamental problem with Agile is the fundamental problem with all product development: The customer doesn't know what they want Agile assumes as a first principal that including the customer throughout the development process will align the building team and the customer to come to the same conclusion. This is almost never actually true. Having built and managed a lot of products I can state fairly confidently t…

You’re right that customers don’t know what they want and that can make it a bad idea to include them in the dev process directly. But is that what Agile is about? I thought it was about iterative development. As a long time product dev I know that you want to follow your own vision when building your product. You let your vision be influenced by customer feedback for sure, but you should always second guess the feed…

It's probably better to phrase it being a development method that focuses on a tight feedback loop with all stakeholders.

You push decisions as far out as possible and gather feedback from individuals every step of the way.

This is what allows the greatest amount of flexibility.

The biggest problem with agile is that it assumes all problems can be put off to the last minute.

I'm frequently finding myself in situations where it is 100x better to hammock program it out for a few weeks before pushing any code. Those systems last ten years. Those systems are able to be modified simply and quickly when business needs change. Those systems do build up legacy code, but it's at a slower rate than other systems. Those systems have fewer hacks over time and fewer bugs as a result.

This isn't a dig at agile, it's a dig at using agile as a design process, for which it is utterly inept. Agile is great at pushing products, terrible at pushing thoughtful system design. (On average, sometimes working a problem works too but more often than not you don't get the chance to redo middle sprint 5.)

Re: Agile at 20: The Failed Rebellion

#108

Post by tablet » Sun, Jul 25, 2021, 8:06 AM UTC

chmod600 wrote: post #12

I'm not an expert on this subject, but I feel like "agile" could be summarized as "a process for actively incorporating feedback early and often". That doesn't mean you need points or tshirt sizes or constant status meetings. You just need channels of communication with the right people and a chance to adapt to what they say.

I'd say agile is more about "shortening feedback loops" everywhere.

Re: Agile at 20: The Failed Rebellion

#109

Post by heisenbit » Sun, Jul 25, 2021, 8:07 AM UTC

pjmlp wrote: post #53

catmanjan wrote: post #42

Earlier quoted context omitted.

I thought agile hedged against that by getting product in front of customers early - they may not know what they want but if you show them 100 things they don't want you'll probably be close

That is the theory, except on the customer side you actually need the people that will use the product. Usually what happens is that you get a customer team, that is supposed to voice how the organization wants the software to be. So the same mismatch is bound to happen anyway. And when they do involve the people from the field, depending on the company culture, they might even be quite positive on the demos (cause b…

Agile willfully closing eyes to skill mismatch is a wider problem. Complex projects have a need for specialization and I cringe every time when new teams or scrum ‚masters‘ ignore that.

Re: Agile at 20: The Failed Rebellion

#110

Post by watwut » Sun, Jul 25, 2021, 8:07 AM UTC

ipnon wrote: post #11

ARandomerDude wrote: post #6

Earlier quoted context omitted.

Low-level drone with 8 different bosses here. I hate being micro managed as much as the next guy, but I've also had way too many coworkers over the past decade who can't seem to just sit down and get the job done. They fiddle and tinker and explore way too much. It's helpful to do that at times but many lack the discipline to produce software without a PM to answer to. I wish it were different, but it isn't. My curre…

This is why Agile has a love hate relationship with the engineering public. For some engineers its a hindrance to dedicated work. For other engineers, they have the realism to see that many programmers need direction and direct feedback to be profitable for their companies.

The thing is, some people needed direction should not imply everyone get punished and loose any semblance of autonomy. Which is literally agile approach. Some people are issue, therefore everyone is subject to elaborate system of autonomy and individuality removal.

Plus minus subtle intra team politics that allows you to circumvent the above.