Live data from Hacker News

Saying goodbye to Agile

lewiscampbell.tech

141–150 of 271 posts

Re: Saying goodbye to Agile

#141
post #43

Earlier quoted context omitted.

I can't count how many times I've seen "agile" projects that were just actually waterfall due to demands from stakeholders.

Absolutely! "You're going to do agile .... and this list of features will be ready on September 20th." "Oh, feature no 32 is going to take months and we realised that users can just...." "No"

> "You're going to do agile .... and this list of features will be ready on September 20th."

That's OK, the latter is not incompatible with the former. Agile vs waterfall is orthogonal with having to commit to deadlines to deliver features.

Re: Saying goodbye to Agile

#142
post #13

There's an interesting phenomenon that Agile (capital A) has exposed me to, and once I saw it due to Agile I've seen parallels elsewhere. In that: if it fails, it is only considered evidence that you were not doing it enough . The solution can never be at fault, it's your execution, or your devotion to the process (in this case) that was faulty. It's also true for Cloud providers; that they're not suited for certain…

> if it fails, it is only considered evidence that you were not doing it enough.

Or not doing it properly. And I understand the suspicion, I really do; but in hindsight, if you honestly tried to review how an organisation was operating, would you sincerely be able to say that it was adhering to a certain agile methodology/framework/mindset/strategy/whatever?

I have so far not see an organisation that would be following scrum, as it is described in the scrum guide; or kanban, as it is described in the kanban guide. I have seen or heard about various organisations that use these words, but they have little resemblance to what was actually proposed. So I can't really say if agile (or any of its particular variants) work or not. I have not seen honest experiments properly run.

Re: Saying goodbye to Agile

#143

I've come to dread any formalization of Agile. Agile development is fine. I've built a 40+ engineering team with it. I can vouch for its effectiveness when applied to small, excellent teams. For reference, here's all the Agile you need, it's 4 sentences: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding t…

> Working software over comprehensive documentation

this is 100% backwards for anything safety-critical or that needs to be maintained past a butterfly's lifetime. this is what encourages yolo-driven-development instead of considering what actually should be done, and this is why agile or Agile or whatever formalization or bastardization of it can not be considered software engineering, but merely code monkeying.

Re: Saying goodbye to Agile

#144
I think that Agile in principle is a good idea, keep iterations small and work on the issues together and deliver working products. The missing piece I think is that PDCA (Plan/Do/Check/Act) cycle isn't being done correctly. The idea is not just to improve the product but to improve the process of creating the product. This may mean you stray way of the path of the Agile system but that doesn't matter, the standard Agile process is just a starting point, it's your shop, create it how you like.

I like a saying from the LEAN manufacturing culture - "The Process is the Expert" but that comes with a caveat, each and every team member is a Process Engineer!

Re: Saying goodbye to Agile

#145

I personally have never worked in a team where Agile (the concept) has failed. But I've also seen it fail all around me. Especially when it's mandated without buy-in. Or when people just don't "get it". e.g. - 45 minute "standups" (!?) - PI "planning" that consisting of deadlines and glorified multiplayer MS Paint - Rigid adherence to ceremonies or processes that add zero value - Retros that focus on complaints and v…

Venting is important. When you don't, tension builds and then explodes. It's necessary to give people a way to air complaints and be heard. And if your team has people with some organizational and social skills, you can channel that into action.

Re: Saying goodbye to Agile

#146

Earlier quoted context omitted.

It is difficult to explain to a division director that they do not have sufficeint capacity (enough qualified programmers) to compete features within a set time budget. The old joke goes, "It takes one woman nine months to produce a baby. But: what if we just put nine women in a room for one month!?"

In my professional consulting experience I've found most of those purported "hard deadlines" as mentioned above were usually arbitrarily defined, in other words: completely made up.

That's an important point. It may be a hard cut-off when the switch happens, but the date for the switch may be malleable.

This is crucial to get surfaced early, along with how painful it is to actually move said date if possible.

Re: Saying goodbye to Agile

#147
Spec driven ddevelopment.. ahh yes, because the formal methods era of computer programming was so quick and successful!

Let me find my: Requirements Specification Requirements Analysis ...

The circle will turn once again when people re-realise that by tue time you've written what should happen in enough detail, you've written the software, and English isn't that great at avoiding ambiguity.

Re: Saying goodbye to Agile

#148
LLMs and AI coding do not change anything to the validity and wisdom of the Agile Manifesto and principles. It's only a new tool in the tool box.

It is difficult to take the author seriously after his claims that the Agile Manifesto is only "platitudes" and "near devoid of meaning"...

Re: Saying goodbye to Agile

#149

Earlier quoted context omitted.

> "You're going to do agile .... and this list of features will be ready on September 20th." Well often the real world forces it upon you. As in customer will switch invoicing system on September 20th, integrations have to be ready by then. We have a lot of this, and hard cut-off is very frequent. If we ain't got all those deliverables implemented by then we will lose customers.

It is difficult to explain to a division director that they do not have sufficeint capacity (enough qualified programmers) to compete features within a set time budget. The old joke goes, "It takes one woman nine months to produce a baby. But: what if we just put nine women in a room for one month!?"

Yeah that never gets old. But it may be some features can be delivered in stages, maybe some can be solved other ways than intended that require less work.

If the org focuses on the customers one can work together to find a way.

Re: Saying goodbye to Agile

#150
post #58

Earlier quoted context omitted.

This is a great point! Reminds me of Agentic software development. When it doesn't work out it's only evidence that you could have used more agents. You can never use enough tokens.

Which also conveniently makes you spend more money on tokens. With agile, at least no one was charging you for it. Like sure, there’s a cost to the process. But there wasn’t direct agile.com profiting from you. Meanwhile agentic workflows every solution to the problem is giving more money to the ai companies. Model is bad? Made more expensive model. Still bad? Here’s an infrastructure that reads huge text files again…

> With agile, at least no one was charging you for it.

Charging people for Agile via his company ThoughtWorks (which sold for 785M) is how Neville Roy Singham made the money to fund far left groups in the US from his base in China.

Post reply on HN