Scrum is for managers

I’ve been pretty critical of Scrum in the last years and I’ve spotted a trend in the reactions I’ve been getting on my blog posts.

Some people agree and chip in their own ideas as to why Scrum is bad for productivity. Others disagree strongly and give all kinds of reasons why Agile is great for delivery. The first group tends to be predominantly developers and designers. The last group consists mostly of managers, Scrum Masters and Agile coaches.

This fascinates me.

The “builders” seem to hate it, while the “managers” seem to love it. It feels like the closer you are to the actual end product, the more Scrum gets in the way of getting things done.

Back when I was a Project Manager, I was OK with Scrum. It made sense to me and gave me a feeling of productivity and direction. Now that I’m back in a software developer role, I don’t see the point in most Scrum ceremonies. They are counterproductive.

I’m obviously not the only one feeling this way.

Software development is rock’n roll. It’s a chaotic process of experimenting, discovering and learning. We’re studying the problem while figuring out a solution and both of these change constantly. That’s what the PDCA cycle is all about: we can’t know up front. So the “builders” are used to experimenting, messing, refactoring and reordering until a solution emerges. It’s a creative process.

The “managers” tend to look at things with a factory line mentality. There is a step-by-step process and if we can streamline this, we’ll get great results. They will always opt for adapting the process and not for allowing more chaos. They design a flow that feels productive to them. That’s where those awful standardised JIRA workflows come from. It’s an attempt to specify the ultimate software production machine.

Both paradigms are right and wrong. Of course, you can’t mess around until you think it’s done. There are budgets and timings involved. Of course, there is no such thing as “scope” and “functional analysis”. Growing a solution is an organic process.

Builders embrace change and chaos. It’s how they improve things. Managers crave stability and predictability. It’s how they control things.

Scrum is really great at pushing that feeling of predictability. Every two weeks we’ll be 15 story points closer to “done”. It’s a perfect conveyor belt. On one side User Stories go in while on the other working software comes out. It’s tailor-made for managers!

For builders, this feels like a very naive abstraction. A UX designer that comes up with a great idea for a contact form, will want to implement that on all forms. She just discovered a way to improve the entire product, not just a part of it! For her, the next logical step would be to apply this new insight to all the interfaces. She doesn’t feel that the other forms are ready, even though they were marked as “Done”.

Developers also struggle with these desperate attempts at specification. To feed the factory line, analysts work hard to “run at least one sprint ahead of development”. By the time a dev opens the JIRA ticket, it’s either incomplete or irrelevant because the system has changed. That leads to frustration in the entire team.

The solution to productive software development lies somewhere between pure chaos and strict control. Scrum does not feel like a fair middle ground. It’s framework put in place by managers to try and control the process. We used to call that micro-management.

If we want to benefit from self-organising teams, we’ll have to empower the builders too. We’ll need a workflow that takes into account the chaotic nature of design instead of punishing it. We need something based on discovery rather than analysis.

Lean comes to mind. So does XP. But Scrum? Nah, we’ve tried that one. And half of us doesn’t like it.

Building software is hard, but don't let that stop you.

If you're building a product and feel like you could use a supportive techie in your corner, let's set up a quick chat to see if I can help you.