Agile is a manifesto, a movement. The movement created/adopted/popularized a pile of tools from standups to storyboarding to kanban. You’re meant to pick and choose what fits your needs to help you get in sync with your clients/customers – and change your choices if they need change, when the goals change! That’s agility.
Scrum is prescriptivist management that takes on the facade of Agile. It’s rigid, conformist, and designed for managers to have control over the processes and output. The absolute opposite of agility.
You can’t have it both ways. Either Agile is a prescriptive system that can be implemented, described, analyzed and criticized.
Or it’s a lofty goal, like “balance”, “correctness” or “wealth”, that by itself doesn’t give you any meaningful guidance on how to get there.
Agile proponents seem to be perfectly fine talking about their pet system as a panacea that will Rid us of Bureaucracy and Bad Decisions, but when criticism comes, they quickly turn the tables and shout YOU WERE DOING IT WRONG.
Scrum can be implemented well IMO, but it’s rare. Often it’s a top-down mandate from management seen as a silver bullet to solve their productivity problems (hint: it’s not a solution, it may even make things worse). I’m at a small startup and we’re using a very loose version of scrum (2 weeks sprints, story pointing, etc.). It wasn’t mandated, we decided it was a decent rough framework to keep track of our productivity and plan out milestones and we don’t follow it to a T if it’s not working for us.
I tend to think of this as “Scrum can be agile, in spite of itself, but it’s rare.”
There is even a church about Agile:
“Scrum is the opposite of Agile”
I can’t disagree with that. Instead of the word “agile”, many times I use the phrase “dynamic process tailoring”, because that really captures how it works more than anything else. There is no standard for agile. It’s a marketing term. It labels the place in the bookstore you go to find current cool dev practices. Not having a standard is not a bad thing, actually, because there’s no one way to do everything.
[paraphrasing] “I’ve been in projects where I could see where the design was headed in three months, and instead of taking a week or two and coding that, the team spent three, six months and still never got completely there”
This is one of the reasons I’m spending so much time on “how to talk about the solution” Good teams have good conversations and Scrum “goes away”. The code “goes away”. Instead they just solve the problem quickly and move on to the next project. Bad or average teams get hung up on the details, whether in the tooling or in the process they’re using, and the more they get hung up the longer everything is going to take.
While true, my statement above is not descriptive enough for people to grok it who’ve never seen it work in practice. More work needs to be done.
I’m intrigued but you’re right that “just solve the problem and move on” sounds to me more like a description of what is wrong with many software teams. Getting hung up is of course not good, but constantly keeping one eye on possible improvements in tooling and process is in my experience necessary in order to not get stuck with diminishing returns. Sure, balance is needed.
Yup, for such a simple thing there’s a lot of depth here that I don’t think the industry has adequately described, either to current practitioners or new folks entering the field. I know some of the advice I got really early on led me in the wrong direction. So many things in tech seem impenetrable/silly, until one day you get it, then it’s so trivial you don’t bother (or can’t) explain it to the next guy. The real meaning of OO was like that for me, or the beauty of well-designed databases. This is another one of those things.
You have to stay on top of the tooling infrastructure changes or you’d still be coding with stone knives and bearskins (Star Trek joke). While the result is perhaps one we can all agree on, getting there is something else entirely. I wrote a book on this, took a chapter and wrote a blog on it the other day, and plan on following up with another book on infrastructure/architecture. Shameless link: https://danielbmarkham.com/for-the-love-of-all-thats-holy-use-ccl-to-control-complexity-in-your-systems/
In my experience, the method of process management is not nearly as important as people make it to be. A team can deliver quality work with just about any method, because the method is not the important ingredient. Having a group of motivated, skilled people that know how to communicate well is the important ingredient. Whatever you agree on after that, ways of working, how to cut up work, report progress, etc. are just implementations details.
Now, when people get frustrated and the process becomes more important than everything else, that clearly is a sign of a problem. But attacking the process is not very useful, because that is symptom of the problem, not the problem itself. Usually, one of the ingredients listed (skill, motivation, communication) is missing in some part of the company. But in general it is really hard, or impossible, to improve that if you’re not the boss. So we’re a bit stuck here. Everyone keeps bashing the same things over and over again, just to let their anger out.