Hi Matthias,
Often I hear excuses for Scrum such as “bad Scrum implementations”. For a long time I agreed: They must not be doing it right. And then I started to question if the practices of Scrum are actually the problem.
The founders of Scrum were management consultants. They surely were hoping that their creation “would once be used (or rather abused) in the majority of big corporations today”. They were not programmers — at least Sutherland wasn’t. They were trying to sell something. I think it was Schwaber who was first to create a Scrum certification mill, in an effort to monetize Agile, and — IMO — almost destroying the Agile movement in the process. It was greed, I believe.
Yes, an understanding of the product goals is important for everyone to have. But that is not the same thing as everyone knowing what everyone else’s tasks are.
Collaboration does not always increase agility. More is not always better. One needs “the right amount”. Most programmers are introverts: they want to code, not collaborate. They reach out when they need to. SMs tend to be extroverts, and want everything to be a game, and every exchange to be face to face. Programmers are not like that.
Agility is a complex thing. It comes from the right balance of design cohesion, the right amount of collaboration in forms that are appropriate for the issue (verbal for simple things; written+verbal for complex things, etc.), creating the right safety nets for early error detection, using tools that are simple, and not making things overly complicated.
You might be interested in an article that I wrote about business agility: I think that the Agile community often over-simplifies the topic.
Someone I worked with one said that first one should give someone a prescriptive process, and then when they have learned, allow them to adapt their process. Yes — if the person prescribing is thoughtful, and truly considers what is needed, instead of prescribing some standard process.
The fact is, Scrum is not the right process today for most Agile teams. For one thing, it does not well accommodate behavior-driven development. Here is an article that explains why.
Things have changed. Scrum was introduced to the Agile movement at a time when most apps were monolithic three-tier systems. Today they are not, and we need another approach. Feature teams cannot work unless there is comprehensive on-demand automated integration testing, and unless the stack is not too deep — today’s stacks tend to be very deep. Microservices need strong cohesion, which calls for component teams — at least for core services.
Scrum tries to be a one-size fits all, and it doesn’t fit most situations today.
Scrum’s failure to address technical practices is also a failure — not a win. Here’s why: organizations expect that if they adopt Scrum, then they are Agile. It is normal for them to think that. By providing a prescriptive process, they have sent a message that Scrum gives you Agile. If there had been no Scrum, companies would have only XP and the Agile Manifesto. XP makes you consider technical practices, which is good, because you cannot be Agile without the technical practices. The Agile Manifesto has no practices, and so to adopt that, you have to think — you cannot follow a process because there is none.
Scrum is to blame. I am sorry, but that is the reality. I lived through it. And I think it was greed: the greed and arrogance of a doctor who learned a little IT, and who seems to think that programming is like sports — but it is not. And the greed of a consultant who created a certification mill so that he could monetize Agile and in the process ruin it.
It was DevOps that saved Agile. The Agile movement should have evolved into DevOps, but instead DevOps evolved independently because Scrum cemented the Agile community into a set of extreme prescriptive practices, causing it to get stuck intellectually. The irony is that today the Agile community claims ownership of DevOps, jumping on the DevOps bandwagon. The truth is, Agile is out of date. XP makes no sense today, given today’s architectures. TDD is a waste of time for distributed real time systems — which is what microservices and event oriented architectures are.
