> I'm not dying to hear what the person who invented Agile thinks we should do next
Agile has plenty of good ideas.
The problem is the almost religious following and, as you mention, the whole industry that has sprung up around it.
Even the initiators said that it was supposed to be a rough framework, to be adapted to your individual circumstances and teams. It was also a (much needed) counterpoint to the then prevalent waterfall model.
Now we have consultants, people strictly following something they read in a book or learned in a course, adhering to strict structure of meetings/processes, and even a big association with a single software product, Jira. ("You are doing it wrong!")
When you step back, a lot of the ideas make sense, and many teams will even implement similar workflows without having ever heard about "Agile".
> ... it was supposed to be a rough framework, to be adapted to your individual circumstances and teams.
> Now we have consultants, people strictly following something they read in a book or learned in a course, adhering to strict structure of meetings/processes, and even a big association with a single software product, Jira. ("You are doing it wrong!")
Yeah. Part of agile is that your process is an adjustible parameter. If you're doing it with a rigid process - any rigid process - then you are not actually doing agile.
When you have a large program team with mixed experience levels who don't fully understand fundamental principles, sometimes the only way to keep your sanity is to force everyone to strictly follow a defined agile methodology (LeSS or SAFe or whatever). That isn't optimal, but if you have to deliver working software right now you can't wait around to figure out an optimal process for your unique circumstances. Pick something good enough and move forward, then improve as you go
Agile doesn't ask you to figure out the "optimal process", it asks you to learn. One of the key things I've seen missed in almost every attempt at Agile/DevOps/whatever is the retrospective or the learning component.
The team/organization has to become a learning organization. That means a number of things, but the critical one here is learning from past failures and successes and incorporating that feedback into their model (ideally continuously, but in Scrums it'd be the end-of-sprint retrospective). You start down a path, and you find it's difficult. You don't press on just because it's the one you selected, that's the way of idiots. You examine the hardships you're facing, and you address them.
Absolutely. To my mind, the one vital agile practice is the weekly retrospective where the team looks at how things went, thinks a bit, and decides to try something in following weeks. Everything else is just tools people can try applying to solve the problem of the week.
I remember someone giving a lecture on software engineering methodologies who gave a pretty good summary by saying that "The methods are there to help your brain, not to replace your brain."
Haha, this was hilarious to read, mainly because, on some occasions, I've been a cowboy, at least in the context of this post. I like to think it worked pretty well, since, for what we were trying to do, the processes were fighting against us, so I just... did what I considered right technically, regardless of tickets and sprints and who's team should do what.
Whether it was right, I'm not sure, but people have been happy with my work, so that allowed me a bit of leeway.
Agile has plenty of good ideas.
The problem is the almost religious following and, as you mention, the whole industry that has sprung up around it.
Even the initiators said that it was supposed to be a rough framework, to be adapted to your individual circumstances and teams. It was also a (much needed) counterpoint to the then prevalent waterfall model.
Now we have consultants, people strictly following something they read in a book or learned in a course, adhering to strict structure of meetings/processes, and even a big association with a single software product, Jira. ("You are doing it wrong!")
When you step back, a lot of the ideas make sense, and many teams will even implement similar workflows without having ever heard about "Agile".
Common sense has to prevail though.