Live data from Hacker News

Agile Is Dead

agilepilled.com

51–60 of 99 posts

Re: Agile Is Dead

#51
post #13

The old manifesto is fine, isn't it? --- Individuals and interactions -- over processes and tools Working software -- over comprehensive documentation Customer collaboration -- over contract negotiation Responding to change -- over following a plan --- I still like it. The problem is not the lack of a good manifesto, is that people don't get it. Anyway, I like that someone else apart from me is thinking about these t…

I like it too, but was always a problem for me: > Customer collaboration -- over contract negotiation Customer is often too busy with his own work to collaborate meaningfully.

If the customer doesn't think their project is important, why should I?

Re: Agile Is Dead

#52
post #13

The old manifesto is fine, isn't it? --- Individuals and interactions -- over processes and tools Working software -- over comprehensive documentation Customer collaboration -- over contract negotiation Responding to change -- over following a plan --- I still like it. The problem is not the lack of a good manifesto, is that people don't get it. Anyway, I like that someone else apart from me is thinking about these t…

[deleted]

Re: Agile Is Dead

#53
I had a manager that secretly but obviously asked chatgpt how long a task should take and how to do it, then assign it to engineers. Can you imagine the state of their code?

Re: Agile Is Dead

#54

> It's for those who believe that skilled engineers are the true drivers of innovation and creators of meaningful products. Maybe the only thing I feel iffy about here. Just feels a bit naïve, I've worked together with some really talented designers. Also worked with some really talented product owners. Can't say I've agreed with every marketer/PR person I've worked with but they've saved our ass a few times. While I…

I think we need to reverse the roles or how they play out in companies in day to day life. We need other people than engineers to _ask_ for certain changes or _make suggestions_. Not a product manager, who takes ideas from other departments as law and _makes demands_ out of that for the engineers, and then by the might of their management position push the changes through. We could be better off with for example a de…

Just make the Designer the Product Manager, or get rid of the PM title entirely. After all, the process of navigating features and fixes to move the product forward is really a design job, not a management function. Also, the more the technical and design people understand the business side, including Marketing and Sales, the better. Ideally, technical and business sides work together, with design as the cartilage that holds them together.

Re: Agile Is Dead

#55
post #45
post #13

The old manifesto is fine, isn't it? --- Individuals and interactions -- over processes and tools Working software -- over comprehensive documentation Customer collaboration -- over contract negotiation Responding to change -- over following a plan --- I still like it. The problem is not the lack of a good manifesto, is that people don't get it. Anyway, I like that someone else apart from me is thinking about these t…

Agile was introduced as a way for coders to empower themselves, and make changes to the software process for themselves. But management came in and started mucking it up. They added more bureaucracy, added silly requirements such as mandatory velocity increases every sprint (numbers go up!). And added even more ceremony than was required with things like "Big Room Planning." At one F500 company we were mandated to do…

Exactly.

Velocity was supposed to reach an equilibrium and then remain constant. Not over taxing the team is essential. If the meetings are a drag, there's something wrong. If people are burning out, there's something wrong. Those are very old lessons.

Re: Agile Is Dead

#56

I happen to believe you get "quality software" by giving devs "ownership" of a piece of the software. And by ownership I mean they come back to it on every revision of the software. They add the new features, they fix its bugs ... they can burn it to the ground if they like for reasons of technical debt (or because they feel like it). "But what if that engineer leaves and no one else understands the code?" I hear you…

I mean, that works if you give them ownership of the budget and revenue targets.

That means if the product does not meet the revenue targets, the development team decreases and the development team has to decide which of their developers are losing their jobs.

That way, when the dev wants to burn it down, they are playing with their own consequences. Autonomy comes with consequences.

Re: Agile Is Dead

#57
post #35

Earlier quoted context omitted.

Oh, well if Agile is just a vibe then count me in.

it's more than a vibe, the challenge is it's "Here's a bunch of things that can help; pick and use what works but don't be dogmatic about it". This is impossible to scale, as by definition it's anti-scale, which is why companies run into massive problems and pervert agile into whatever they have now.

If that's the problem, then it's easy.

Do not think about the tools. Think about small improvements that can move the team in a more productive and sustainable (agile) way.

Simple things. Like putting a timer on long meetings until people get used to not extending it. Or putting a limit on the work pipeline between the developer and the tester to avoid overwhelming testing sessions.

In my opinion, you are not supposed to start from scratch. The chaos often comes from this "let's blank slate everything and adopt all agile things we can find". Once again, the same mistake of focusing on tools instead of interactions between people.

C'mon, it's not that hard. Doesn't need to have strict rules.

Re: Agile Is Dead

#58
What actually works are the development models proposed by Royce, the spiral model, DSDM, XP, and something like kanban (pull based) with the manifesto -- all based on the same core essentials: build to the outcome, prioritize learning, build through the unknowns, and deliver what you learned, all in a long term risk and long term RoE weighted way.*

Scaled Agile for Enterprise (SAFE), SCRUM, etc., generally don't accomplish this. Any methods that take waterfall and relabel it and add roles until executives are bamboozled into thinking it's Agile™, don't.

This is where waterfall probably came from:

- Royce, 1970: https://www.praxisframework.org/files/royce1970.pdf

While it's where "waterfall" came from, seems to be because someone stopped reading when they saw Figure 2.

Figure 2 is what not to do, he says it doesn't work. By contrast, he already understands principles such as prototype what works then document it, then build it again (Fig 7 Step 3 says make one to throw away) or ski with your customer (Fig. 9 Step 5 says keep tight with the customer), etc. Myth has it the DOD got excited about Figure 2 and ran with it. Most damagingly misunderstood software development paper ever?

- Spiral model: https://en.wikipedia.org/wiki/Spiral_model

Prototypes with iterative scope and rigor until it's good enough. Sound familiar?

- DSDM: https://en.wikipedia.org/wiki/Dynamic_systems_development_me...

Look at the 8 principles and especially the core techniques...

- XP: https://en.wikipedia.org/wiki/Extreme_programming

"Pairing" is why LLM code copilots "work".

* Easy to say.

Re: Agile Is Dead

#59

> It's for those who believe that skilled engineers are the true drivers of innovation and creators of meaningful products. Maybe the only thing I feel iffy about here. Just feels a bit naïve, I've worked together with some really talented designers. Also worked with some really talented product owners. Can't say I've agreed with every marketer/PR person I've worked with but they've saved our ass a few times. While I…

"The 5 Laws of Holistic Development" at the bottom reeks of being written by someone who is bitter and falling into the "us vs them" trap.

I get it, I used to get really upset when business "overruled" engineering advise and decided to adopt a subpar solution, such as reaching for a 3rd party vendor or telling me what library they want me to use.

Then I realized that the job of a really good senior engineer is to offer options, be able to discuss the tradeoffs of each and to empower the business to make informed decisions that take ALL of the context into account: budgets, timelines, market pressures, planned shelf-life of the application, what "quality" means to end users etc.

It is the business' role to do cost benefit analysis. Engineers tend to get into the mindset of "there is one, 'right', way to do something." The reality is that there are many possible solutions to a given problem, each with their own tradeoffs. The business hired you to be able to provide solutions that align with business goals, objectives and budgets.

If a manager is telling you that they like a particular tool and would like you to consider it, that's a sign that you have failed at communicating. You have not communicated the fact that you have already explored various options, you have not communicated the fact that you understand that there are tradeoffs to be found among various options, you have not communicated that there are options at all. Most likely you did what engineers are inclined to do: you told them what you think is the 'right' way to do it, and they don't like that because it is too expensive and you didn't give them a single "out" so they are looking for them themselves (even though that was your job).

"Synergy: Value genuine, purpose-driven communication over forced meetings and rigid processes."

That's no different than "people over processes" from the original Agile manifesto.

"Adaptability"

What do you think 'agile' means?

"Courage: Foster an environment where taking risks and learning from failures lead to breakthrough solutions."

Courage is a value that companies either hold or they don't. At my current employer we embody this as "Normal sucks" in our core values. This tends to be a culture problem when companies don't value courage. I don't object to this one, but it suggests that the author is bitter having worked at companies that don't value this and want to maintain status-quo.

"Mastery: Cultivate engineers who combine deep technical proficiency with a clear understanding of the product vision."

Here's the catch-22 when it comes to business:

You want to hire a team of super experienced and talented engineers who can develop your application to an incredibly high standard in a very fast time.

Your first problem is that the labour pool for software is already tiny. That's why wages are high. So you have a hard time just finding these engineers in the first place. Once you've invested weeks into trying to recruit them, some Fintech company with a bigger budget snatches them up from under you.

Now say you did manage to hire a few. These are middle-aged individuals with families who cost a small fortune and have very low tolerances for bullshit. They will not work weekends. They may be willing to work the occasional overtime but only if that's a rare occurrence, they participated in getting the team into the weeds and the overtime is guaranteed to get the team back on track.

This senior engineer isn't looking to get promoted, they are already earning enough comp that more money no longer motivates them. Some of them are approaching retirement while others are looking to move into leadership positions.

Whereas you have less difficulty hiring someone with 5 years experience. This is a young person in their mid-twenties who has something to prove. They want to get promoted so they want to impress you. They are not married with children and so they are way more willing to give up weekends and churn out mediocre pull requests like it's no ones' business.

What the younger engineer needs is guidance and mentorship. They need the people that you want writing the code teaching them how to write the code that you want.

That's another culture issue. But hiring is difficult especially if the person doing the hiring is not an expert in the domain they're hiring for. This will be the case for virtually ALL tech startups that aren't being co-founded by an engineer ... you need to trust that the top engineering talent you are hiring is competent to do the tech hiring for you.

Re: Agile Is Dead

#60
post #24
post #13

The old manifesto is fine, isn't it? --- Individuals and interactions -- over processes and tools Working software -- over comprehensive documentation Customer collaboration -- over contract negotiation Responding to change -- over following a plan --- I still like it. The problem is not the lack of a good manifesto, is that people don't get it. Anyway, I like that someone else apart from me is thinking about these t…

Agile is like communism - it sounds like a great idea. Except it never seems to work anywhere, and everywhere that it turns into a train wreck consisting of 45 minute daily stand-ups and 3 hour meetings arguing about T-shirt sizes or whether points are equivalent to time or not, the only explanation anyone ever proffers is, "well, you weren't doing Agile right". No fucking shit. Nobody can do Agile right. I would arg…

Agile works very well for small projects. When you have less than 10 developers it gets rid of a lot of overhead. However those are situations where project management isn't really hard and so they didn't need it. Companies doing projects with hundreds of thousands of developers are hurting because nobody can do project management. Agile seemed to help and so they jumped in. However painful experience with agile has shown there really was a good reason for all those processes agile go rid of! They are back to waterfall because at the end of the day they have real problems and all solutions end up pushing them to do a lot of pre-work planning to have a chance. Not that waterfall is good - it isn't - but everything else is worse as painful experience keeps showing.

Note that while we call what they are doing waterfall, in fact it isn't. All (nearly all?) projects are doing releases. They do go back and change things made in the past, just that the timeline is very long. They do discover things are not working and stop - sometimes they don't realize this in time to stop early, but they do stop.

What the world needs is a process for large numbers of people to develop software without stepping on each other. I do not have an answer to this problem - I'm not even sure if it exists.

Post reply on HN