[dead]
Saying goodbye to Agile
131–140 of 271 posts
Re: Saying goodbye to Agile
#132Earlier 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.
> 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. A concept older than agentic software development is bad workmen blaming his tools. I mean, if you can't possibly hammer a nail then is it reasonable to blame the hammer?
You can use brick as hammer. Doesn't mean brick makes a good hammer or that person who tells that brick is a bad hammer and doesn't work from them is bad workman.
Re: Saying goodbye to Agile
#133The problem is reality. I've found that Finance, and the Tax Office of any government, rarely care about your Agile processes. They have their yearly cycles, and C-Level will always want to follow _those_ cycles. Then, for those that have schoolgoing kids or work with people that have schoolgoing kids (aka: everyone everywhere): there is the school vacations cycles. These too rarely care about your scrum rituals or P…
Then don't use it in those environments. Agile is not a silver bullet, nothing is.
Re: Saying goodbye to Agile
#134I've written something similar https://blog.dochia.dev/blog/waterfall-returning/ As code is less expensive, specs are the new bottleneck.
Getting the requirements right was always the hard part. Hence agile.
Re: Saying goodbye to Agile
#135When Agile came about to company (large American corp) I work for, around 2015 (arguably quite late), I was quite skeptical. In my opinion, a decent waterfall (basically a sort of compromise) worked pretty well, and I didn't like fake "innovations" like Scrum or renaming everything in project management terminology.
Then I read Steve Yegge's Good Agile, Bad Agile. It basically says, Agile is just a Kanban queue. And I think I got it, and I think that's working very well. At least from the project management side.
There are IMHO three management angles to look at any engineering project - product, project and architecture. If you are building a house, you need a blueprint to tell where to put what concrete, you need a render (or paper model) that you show to a customer, and you need a BOM and a timeline to make the investors happy. The software is not different. But that's also where there are misunderstandings in what Agile is - the product management, project management and engineering all have different ideas what kind of "plan" is needed.
So in the case of software, specs are like the house's blueprint. In some cases, specs might be useful prototype, in some cases not. It's just not the type of plan that the project or product management cares about.
Regarding the project management angle, for me Agile today is clearly Kanban, and almost everything else is wrong or not required. I often make an analogy with computers. In the 50s and 60s, people tried to plan the work that the computer calculates by creating some scheduling algorithms that plan ahead the use of resources, avoid conflicts and such. Eventually, we found out that simple dispatch queues work the best, don't estimate at all how long the task will take. Just give it a priority, a time slice, and let it run. And I think the same applies for the SW development. And I think it's time that project management people take note from computer scientists - they already know.
Doesn't mean SW development time cannot be estimated if you need to, it's just not a very efficient to do so (it takes extra time, depending on how good estimate you want).
Re: Saying goodbye to Agile
#136Oh no, the kids are going to invent agile again aren't they?
Stay hopeful, maybe Nu-Agile will become annoying in new and interesting ways!
Perhaps needing to estimate tasks in cloud credits? That would be a new one. And then of course mapping those credits uselessly to time needed.
Re: Saying goodbye to Agile
#137TFA first claims that agile invented none of the things it encompasses, seems not to challenge those claims, but then just jumps to agile is dead because LLMs can code based on spec. This is just a confusing and confused article. Agile just finally embraced that specs are incomplete and can even be wrong because the writer of the spec does not yet really know or understand what they want. So they need working softwar…
> Agile just finally embraced that specs are incomplete and can even be wrong because the writer of the spec does not yet really know or understand what they want. So they need working software to show the spec in action and then we can iterate on the results.
I agree, but what you describe is agile, not Agile (capital A).
Agile (capital A) is Scrum (capital S) where you have Backlog Grooming (patent pending) where the team clears any ambiguity to define a spec (ticket).
Deviating from said spec is seen as Scope Creep (gasp) and might lead to complaints during Sprint Review (trademark).
So yes, agile prefers working software over detailed spec. But typical manifestations of Agile (capital A) are exactly the opposite.
Re: Saying goodbye to Agile
#138There's a problem with any formalisation of patterns like Agile and other things like SOLID, Design Patterns (GoF) etc.: if you never saw the world before them, you will never appreciate why they exist.
Is anyone actually doing true waterfall development any more? How would that even work with the amount of open source software in use? The world is fundamentally different now than it was 25 years ago.
Stuff like SOLID and Design Patterns etc. are such good ideas that they've been incorporated directly into the design of modern languages and frameworks. It's natural that someone would pick up Design Patterns today and think it's all pointless. That's because the book was written in 1994 and it wasn't pointless to say it back then.
I guess this is why history tends to repeat itself. Many people can't internalise why something is bad unless they've experienced it themselves. Many more don't even read about it in the first place. Scary to think.
Re: Saying goodbye to Agile
#139If you've never built a complex thing out of wood, I highly recommend it. There's an interesting curve of experience. First you try to build basic things, and it seems kinda easy, everything just works. Then you start trying more advanced things, and it seems like everything gets screwed up constantly. Finally you master the advanced things, and you screw up less and it gets easier. The same is true of software. At f…
And that's why agile is not a set in stone process, that imposes tools and process upon the devs, but states: "Individuals and interactions over processes and tools". Basically, it tells you, that you will need to figure out what works for this project and this set of people.
Re: Saying goodbye to Agile
#140Earlier 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!?"
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.