Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Agile at 20: The Failed Rebellion

simplethread.com

Post reply on HN
Print view View original

41–50 of 320 posts

Re: Agile at 20: The Failed Rebellion

#41

Post by AndrewKemendo »

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 that the amount of time the customer has, and clarity about the problem they want solved is orders of magnitude more ambiguous than is required to actually build and deliver something to their satisfaction.

In my opinion successful products, and I mean ones with significant flywheels with customers and viral growth and stickiness are with few exceptions - accidents. It was someone who had an interesting thought and a lot of people for whom the product was good enough for their desire that they often didn't even know they had

You can't write down how to do that, it's like asking a nobel prize winner how they came up with their discovery. It's not repeatable. Some people have better intuitions than others and these are the people who are repeatably successful with products. But it doesn't generalize.

That said, the fundamental problem isn't wrong in theory, it's just naiive in practice.

Re: Agile at 20: The Failed Rebellion

#42

Post by catmanjan »

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…

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

Re: Agile at 20: The Failed Rebellion

#43

Post by jordanbeiber »

brundolf wrote: post #32
throwaway290232 wrote: post #18

Agile is a generic umbrella term that involves a vast array of complex, subtle knowledge and skills. It's like saying "Engineer", or "Chef". Each has a shared skillset, to be sure. But each category's members can't just work the same way at all jobs, and there's no book on how to be an Engineer or Chef everywhere. The Agile Manifesto is a failure at trying to make Agile happen because it can't tell you how to make it…

The product and engineering managers I've had in the past have generally been humble, acting as a touchstone of coordination for the folks on the ground rather than a controlling force. And the engineering managers have all just been former engineers who decided they preferred doing this kind of facilitation work instead of writing code. Maybe this isn't the norm?

Most places buying these process frameworks are enterprise shops where that absolutely is NOT the norm.

Wich makes it all a glorious Catch 22.

These companies, that rely completely on software, are unable to make the required leadership changes. It’s cultural.

Re: Agile at 20: The Failed Rebellion

#44

Post by invaliduser »

koonsolo wrote: post #36
ipnon wrote: post #10

Earlier quoted context omitted.

This is how revolutionary Marxism functions. Nobody knows what the hell Marx wrote in those books, or what any of it means, but it cannot be argued in communist regimes that there is a system in place, and that the vanguard knows whats best. Replace Marxism with Agile, communist regimes with corporation, and vanguard with management, and you have the recipe for soulless employment.

> but it cannot be argued in communist regimes And here lies the difference: agile includes retrospectives. I It's the only thing you need for agile. And if you don't have that, you don't have agile.

Well, it depends. I have seen many teams where retrospectives are basically a lot of personal mea culpas, people talking about what they did not do right, and it was mostly about how they should have done things differently rather than how the process or organisation could be adapted. The overall feeling is that agile works great, scrum works great, so if something went wrong it's because of the human factor and that's what should be fixed... I don't know about communism, but at some places the implementation of agile sounds like a regime.

Re: Agile at 20: The Failed Rebellion

#45

Post by smitty1e »

rualca wrote: post #38
lalos wrote: post #13

Agile got widespread adoptions because of the micromanagement undertone of it, starting with the daily scrum. It's a slippery slope, way to easy to over do. The risk is it starts something to be gamed/incentivized instead of actual progress.

> Agile got widespread adoptions because of the micromanagement undertone of it, starting with the daily scrum. I would put things differently: micromanagers leveraged the agile and scrum buzzwords to justify and convey an aura of legitimacy to micromanaging. I mean, how many orgs forced daily meetings where workers are forced to enumerate what they did and delivered in a short time frame, but mysteriously left out t…

Agile lives and dies by communication. Both amplitude and SNR matter, and have always been present in the proper ratios in the best engineering.

Agile is very open to attack when it veers from a list of useful practices to try out in a given context and instead turns into dogma.

Re: Agile at 20: The Failed Rebellion

#46

Post by jnwatson »

andi999 wrote: post #29

If nobody does something there is a chance it doesn't work. The most problematic point to me seems to be point 3 'customer collaboration'. Does anybody know how to do that in real life? What does the sales team sell then? And more important how do you prevent feature creep from the customers side wanting more and more things during the process? To me I only see this working if you sell working time instead of a produ…

The sales team sells what has already been delivered.

In my experience, the customer collaboration happens through a proxy called the product manager. It is their job to hold meetings with customers to figure out priorities.

You don’t “prevent” feature creep ever. It is part and parcel of development. You can, however, manage it by restricting when the goalposts change. In Scrum, that’s at sprint boundaries. The most important bit is that the customer chooses priority but the developers choose velocity.

Re: Agile at 20: The Failed Rebellion

#47

Post by nerdponx »

disk0 wrote: post #40
ipnon wrote: post #10

Earlier quoted context omitted.

This is how revolutionary Marxism functions. Nobody knows what the hell Marx wrote in those books, or what any of it means, but it cannot be argued in communist regimes that there is a system in place, and that the vanguard knows whats best. Replace Marxism with Agile, communist regimes with corporation, and vanguard with management, and you have the recipe for soulless employment.

People (read: Twitter users)[0] have discussed the parallels between Maoist/Marxist theory and both Agile and extreme programming—albeit less fever-dreamy [0] A couple of said theory tweets, from memory https://twitter.com/mmabeuf/status/1352450003231506432 https://twitter.com/mmabeuf/status/1323758677099270147

But this is a joke... right? I hope?

Side note: I have never actually read anything written by Mao before. That stuff is a very unsettling combination of stone-cold and unhinged. Maybe it's just because we know the "full" history now, maybe it's just the phrasing of the translation. Yikes.

Re: Agile at 20: The Failed Rebellion

#48

Post by undreren »

beermonster wrote: post #30
undreren wrote: post #21

Earlier quoted context omitted.

Agile is (maybe a bit oversimplified) about releasing as often often as possible. Delivering sooner, not faster. To do this, decision makers must be close to the team, and ideally a part of the team. Either managers are part of the team, or the team a given the authority to make product decisions. Full time managers lose power and influence either way, and I think this is the real reason Big Corp never really bought…

> Delivery sooner, not faster Well delivering sooner with less in it.

Precisely :-)

Re: Agile at 20: The Failed Rebellion

#49

Post by RandomLensman »

Senior management in a lot of places is by now trained and groomed to see everything as a process, so principles don't cut it.

Similarly, consultancies need to sell "products", i.e. implementable processes and change, so again principles are a problem.

Lastly, in a lot of places the actual users or product owners from the business side are only involved via representatives, so there is no closed loop to run.

Re: Agile at 20: The Failed Rebellion

#50

Post by jnwatson »

axegon_ wrote: post #16

I never really understood the hype around (f)ragile (as one famous google engineer called it in a small closed circle a few years ago). I think the main problem is that in the past 7-8 years it has become more of an evangelism effort rather than anything. > The important piece that gets forgotten is that Agile was openly, militantly anti-management in the beginning. Yet here we are: The process just became an endless…

Using story points for evaluating developers goes against the ideals of Agile. It also makes story points useless. See Goodhart’s law.
Post reply on HN