Edit: I initially was asking about the agile methodology, but I was really referencing the scrum framework.
IMHO Scrum was a prescription of how to be agile because being agile is a kind if philosophy and it is hard to make it work quickly without huge investment in the growth of each individual.
Its main lets say purpose (not by its creators) was to disrupt Waterfall at scale and it managed to do that no matter if it works or not.
But while Scrum worked well for the innovators adopting it it does not work at scale (nor does Safe or any other framework trying to fix it by adding more processes and roles). Actually most implementations of Scrum at scale are anti-agile, are rigid and products and teams will collapse (productivity wise) if tomorrow someone takes scrum out. Because they are trained to follow Scrum not to be agile.
Agile means thriving in a fragile environment and Scrum does not teach people that.
There are some new frameworks in the making. Solving some of the issues we encounter now but it is hard to predict which one will win if any.
I for example really like Shape Up. I feel it allows teams to be agile while not being so focused on daily work.
The problems arise when the "I need agile!" meme becomes reality and leaders adopt it for the sake of showmanship. If your incident responders are able to plan the incidents they'll work over the next sprint, you are clearly managing a team of saboteurs.
If you are are talking about the agile industrial complex, it should all burn in a garbage fire.
The business of telling people you are doing agile wrong.
If someone leads retro/planning activities but his full time role is business analys/QA/dev that is how it should be - just one of team members gets a function and ideally it could be handed over periodically.
There are less than 20 authors in the manifesto, go check what they were up to. Next to the management framework, there is a lot of engeneering techniques and ideas. A sibling comment talked about XP whose technics work well along scrum, but there is also clean code, refactoring, crystal methods, agile as a cooperative game, liberating structures, devops (no, not the job offer),...
They all had blogs (archive. org is your friend for some of them), wrote books and gave talks. I like to get lost on http://wiki.c2.com/ where I found lots of insight about how to make the thing work. So yeah, I think it work pretty well when you learn how to use it.
To begin with, Agile isn't a methodology. It's a way of thinking about development—a philosophy—that's defined at agilemanifesto.org.
There are a bunch of methods that follow the Agile philosophy. Scrum and Extreme Programming are the most well known. Extreme Programming was popular in the early 2000s, but has since been eclipsed by Scrum.
There are a bunch of companies and methods that claim to follow the Agile philosophy, but don't. SAFe ("Scaled Agile Framework") is the most well known. Additionally, because Scrum is so popular, most of the companies who claim to be "Agile" are actually using some cargo cult version of Scrum.
So you'll get a lot of people complaining about Agile, when they're actually complaining about crappy Scrum and SAFe implementations.
Personally, as someone who's been involved with the Agile community for a few decades, I would love to see Scrum replaced with Extreme Programming. My experience is that XP works much better than Scrum in practice, because it emphasizes engineering practices, whereas Scrum puts too much focus on Scrummasters and planning. Although Scrum has some good ideas, they're very nuanced, and tend to be misunderstood in a way that leads to micromanagement.
Edit, since the OP was changed:
Yes, Scrum works when done correctly. But most people don't do it correctly, because it's very bare-bones, which results in people layering their own preconceptions on top of it, most of which are distinctly anti-Agile. Additionally, Scrum pioneered the "Certified Scrummaster" (CSM) and "Certified Scrum Trainer" (CST) certifications, which were so lucrative that they attracted a lot of incompetent people into teaching Scrum. The CSM course is also too short and shallow to really teach people how to lead Scrum teams effectively, but is marketed as a panacea.
The result has been a giant garbage fire.
"Planning is essential, but a plan is useless." ~~ Dwight D. Eisenhower
Would you say that practicing the agile philosophy generally looks different on a team-by-team basis?
Read this:
https://github.com/rayfrankenstein/AITOW/blob/master/README....
Agile (https://agilemanifesto.org/principles.html) is not a formalized process or methodology. It is a set of simple principles:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
These are pretty reasonable principles. Do they work? Better than what they were reacting against, which was the "specify and document everything in detail up front" methodologies.
Agreed. Scrum is only a subset of Agile like Kanban (that has a different approach than Scrum), but they are both Agile.
In terms of theory for agile practice, one typically sees discussion of industrial control theory and analogies based on thermostatic controls, but it seems surface-deep to me.
I don't disagree with you, which is why I say that the manifesto is really just actually asking you to exercise your best judgement, given the set of values it proposes. The pragmatic attempts to provide a methodology only give you a list of "thou shalts" that remove the need for people to exercise best judgement in the first place (which is somewhat defeating).
There is some software engineering literature that attempts to provide a theoretical foundation, as I mentioned, but while interesting, I haven't found them terribly useful: people just want a list of commandments to follow.
Is that the manifesto's fault?
Personally, I think the manifesto is probably best used like a diagnostic check-list to understand how screwed up your current work context actually is.
https://www.jamesshore.com/v2/books/aoad2/what_is_agile
The rest of the theory is spread throughout the book, in "key ideas" sidebars (which you can find in the index) and the "Experiments and Alternatives" sections at the end of each practice.
I'm not aware of any books that are purely about the underlying theory, but these books swing the pendulum more towards the theory side of things:
Lean Software Development (Mary and Tom Poppendieck) - if you only read one, this is the one to read
The Principles of Product Development Flow (Tom Reinertsen)
Agile Software Development, 2nd. ed. (Alistair Cockburn)
Extreme Programming Explained, 2nd ed. (Kent Beck)
The Lean Startup (Eric Ries)
MVP. I would argue when you bring up agile, most people are thinking of the allure of a small scrappy startup with 2-pizza size teams who by herculean effort create a Minimum Viable Prototype in record time. Nevermind, the MVP was built with little concern for scalability, security, or enterprise integration. Speed to market is the driving force behind startup culture and trying to grab market share. The idea is that once you get market share and more funding, then you can think of documenting and optimizing your code.
Agile Project. In practice, most people are really running "Agile Projects". They invest considerable time upfront to interview, document, and get signoff on project requirements… before they even start coding. Does this sound like waterfall? After they get the requirements, then they develop using scrum practices and ceremonies. (Nitpick, "ceremony" is a terrible word choice as it means those activities have no meat or value [1]). E.g. 18F's Agile based project approach requires "We conduct discovery research before we build anything. Depending on the complexity of your problem space, this can take up to 2 to 3 months." [2]
[1] https://turboscrum.com/the-fascinating-origin-of-the-term-sc... [2] https://agile.18f.gov/18f-agile-approach/
"Retros" are useless 98% of the time. I'd often feel like I was being forced to participate and provide bullshit answers just so someone could fill out a spreadsheet and file his TPS report.
It's rigid, hierarchical, proscriptive and weirdly bureaucratic. If you follow all the rules they promise you'll end up in a better place. If you dont, it's because you didnt follow the rules precisely enough.
They both believe in all the same sort of wishy washy stuff though.
BINGO! I'd posit that a LOT (maybe most) teams that claim to be using Scrum or another "agile" methodology are totally screwing the pooch for this exact reason - management doesn't really "get it" and layers all of their shitty bureaucratic nonsense on top of the core agile methodology. That's the fault of shitty managers, not the fault of the methodology.
There is a fundamental, total disconnect between the world of PERT charts and the agile world. That disconnect happens somewhere. If your manager gets agile, does their manager? Their manager's manager? Somewhere there has to be someone who can go both ways - who can be "agile down" and "non-agile up". If you don't have that person, then you get some flavor of "PERT chart agile", which isn't actually agile at all.
No
Now there clearly are people doing something that they call "Scrum" which is some shitty made-up process they cobbled together themselves like Frankenstein's monster, with FSM-only-knows what kind of bureaucratic elements. But that's not pure Scrum per-se.
[1]: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Gui...