Scrum is not Agile
I touched on this subject lightly in multiple articles.
I think by now, literally everybody has experienced Scrum. Engineers roll their eyes when you talk to them about another sprint planning, estimation meeting, backlog grooming, etc. And their sigh about never-ending standups consuming more and more time.
I always found it pretty puzzling how far diverged the spirit of Agile vs. the letter of Agile (methodology).
We all learned to love (and mostly hate) Scrum. Way too much process, way too many artifacts, while having a lot of gaps (plugged by each company differently).
Take a look at this Agile manifesto (which represents the spirit).
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
In no way does Scrum follow the first two lines. Scrum is more about processes and tools (vs. individual and interactions). It heavily emphasizes documentation (maybe not in a long Word document, but tickets, artifacts, estimation, story description, etc.).
Why? WHY? WHYYYYYYYYYYY?
This is my standard question. Stating something is simple. Figuring out why it’s like that is way more complex (and interesting).
I would say there are two main reasons:
- Invented in Ivory tower and implemented in the trenches
It’s easy to discuss Agile principles when you have a dozen of the world’s best thinkers in the room (take a look at some of the signators of the Agile manifesto: “Kent Beck,” “Robert C. Martin,” “Martin Fowler,” etc.).
They have tons of knowledge, experience, and a high IQ. They spend decades musing on these subjects and writing books about it.
It’s way different when you are part of an unknown co and part of a team of three junior engineers who are touching first-time production code.
You can take almost any (bad) methodology, and great people would pull off risky projects. You can use the best methodology, but a mediocre team with mediocre management won’t find a way out of a paper bag.
- Business needs
Software engineering doesn’t exist in a vacuum. We are not doing this as a hobby; instead, we are working as part of business enterprises, getting paid for it, and so on. As a result, we can’t ignore the business needs.
Unfortunately, business needs don’t match well with the Agile manifesto.
First, businesses have limited resources and limited brand recognition. Many companies have problematic hiring practices and end up with mediocre teams. As a result, they are forced to use methodologies that work for a mediocre team. (If you have Mcdonald’s level talent, you better put a very rigid process in place, as McDonald’s does).
Business requires some level of predictability. So here goes collaboration and response to a change and comes back negotiation and following the plan.
Summary
The bottom line. The agile manifesto will work best in a team of great people, with business owners who recognize the benefits of being Agile.
And Agile will be dismantled and replaced by Cargo cult Agile (ahem.. I meant Scrum) in environments where the amount of talent is smaller, and business owners need way more predictability.
