81–90 of 271 posts
Lucky me, I've never had to say Hi Agile in a first place. It is a tumor. Been in programming since 80s. Mostly on my own except 6 years long stint at the company. Quit in 2000 from position of CTO
But if agile is criticized... only worse alternatives are given, if at all. Here, spec-driven development is inferior, as in most cases the goal is only vaguely known. Cyclical development is not some hollow mantra, it is how life works. All the rituals around it were just to faciliate more communication. A lot of people in this field just hate that, they want their tickets and to be left alone.
Now that implementation cycles are even shorter, there is even less manual need for coding, agile methodologies will be actually more prevalent.
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…
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.
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?
Earlier quoted context omitted.
My favorite Agile-ism is when Agile is defined as “the process that works for the team”. If a team adopts agile (in any variation) and doesn’t like it, the Agile defenders will appear and argue that the team wasn’t actually doing agile. Agile is defined as the process that works, so if it didn’t work it couldn’t have been agile. If only you read The Agile Manifesto you would understand!
> My favorite Agile-ism is when Agile is defined as “the process that works for the team”. What compels you to believe it isn't? I mean, read the Agile Manifesto. All it does is basically define a set of values and principles. Things like "customer comes first" or "we welcome changes in requirements" or "software must be delivered frequently". What leads you to believe Agile implies a fixed set of precise, rigid rule…
My thoughts when PE forced Agile on my employer were dismissed as "you're the technical expert, we're the process experts".
As someone without decision power, you read words of empowerment but your reality is a different one, and you're left resolving that dissonance on your own (quietly, otherwise you get pushed aside).
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…
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…
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…
Depends. There are companies [1] making loads of money out of it. Charging for certification and imposing the idea that either you are certified, or you are going to fail. They are even eating the lunch of PMI, as PMI (PMBoK) is turning into an Agile manual. Where I work is being expended literally millions per year in Agile.
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…
This is the horseshoe theory of Agile. If you do Agile hard enough you end up at SAFe which is basically waterfall.
Agile, as implemented in every big company that I've worked for, was a lie. It was really telling at a smaller company that was trying to behave like a big company. I asked a coworker (who had great metrics) what the secret was for dealing with the middle-management-heavy and quite dysfunctional environment. He told me how he did it. Paraphrased: "It's easy. During each sprint, I work on the next sprint's work. Once…
How did he see into the future to know which work he'd be doing on the next sprint, and how did he also finish the current sprint's work with a bullseye thus allowing the next sprint's to begin and match 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 venting with no actionable outcomes
- etc etc
Every time I've introduced Agile to a team or project that was new to it I was always met with skepticism. But 6 months down the line noone on the team/project wanted to go back to the "old" way of working. I don't even really care about any text book definitions. These are the only things we try to stick to:
- Short, daily standups
- Planning based on risk reduction
- Estimates based on complexity (ties in with risk reduction)
- Actionable retro items
- User demos every sprint (makes it easier to pivot - users rarely know what they want)