The Sovietization of Scrum
When I just finished reading Gabi Steinhardt’s The McDonaldization of the Development Team I felt angry, almost furious, and a strong urge to utter on the keyboard what a load of nonsense this is. And then I stopped and thought to myself – why am I so angry? The answer, so I believe, is that in many ways Gabi is right. That is, he is getting many of the facts wrong, but he is not alone there – similar misconceptions of Agile and Scrum are being made in many organizations and by many experts.
There must be something else. Many Agilists claim that agility is the right thing for today’s ever changing pace, need for speed, yada, yada, yada – you know the drill. So how come many Agile implementations fail to deliver? The answer must be elsewhere – or at least, in Agile and some other thing or things.
This is what made me so angry. Although Gabi’s comparison of Agile and McDonalizing is, in my view, wrong, he is right in saying that Scrum in particular, and Agile in large, are weak in addressing the notion that resistance to Agile has a meaning. That there is a meaning behind what goes on in an organization deciding to adopt Scrum on one hand and in-practice, at the same time, sabotages its own decisions on the other.
But first, let me address some facts gone wrong in Gabi’s post.
The Industrial Revolution
All the facts in this part of the post are correct. I wish to add another observation which is missing, yet extremely relevant:
Prior to the Industrial Revolution, the social structure was very clear: You could either be Royal, Noble, Knight or Peasant. The class of your parents would determine your class, and that’s it. Your professional status, on the other hand, was quite different: In the craftsmanship process, you would start as an apprentice, learn for years, and hope to become a master. You’d hope that your master would “kick the bucket” or a master in a near town would, and so you’d have the opportunity to become one. The learning process itself was not standard and not proven.
Classes were very clear; Professional path wasn’t.
Then the Industrial Revolution came: All of a sudden you could get a job that respects its owner very quickly. You’d apply to Ford, get trained, and Hey Presto, you have a profession. Your stature, on the other hand, became very unclear. Noblesse and Knighthood gradually became not strictly Blue Blood anymore. Peasants of old all of a sudden became respectable citizens.
Classes became unclear; Professional path was.
And then the Post Industrial Milieu came: Professions became complex and complicated. Becoming a great Programmer (a craftsperson, or Master) involves a lot of learning, as well as vast experience. The same goes for a master of Product Manager (where do you get a degree in Computer Product Management?). At the same time, the social structure is vague: a degree-less person can come up with an idea for a small operating system, and become the richest person worldwide, not to mention one of the most influential ones – a position once reserved almost uniquely for Kings and Queens.
Classes remain unclear; Professional path also becomes unclear again.
The McDonald Way
Nothing more to add, other than that The McDonald Brothers, descendants of Irish immigrants to the US, established a single restaurant in 1938, developed their own “Speedee Service System”, and franchised the largest food chain ever starting 1953.
Unclear class structure and unprecedented career path. Point above proven.
The Scrum Development Team
This is where Gabi’s blog post symbolizes what takes place in so many organizations: misinterpreting the original intents of Scrum and of Agility. Please don’t get me wrong – this is not a criticism against Gabi. Nor is it an attempt to say something bad about such organizations. This is a fact: Agile is failing miserably in delivering its message to the world. I would make a wild guess that about 5% of Agile transitions become successful in a reasonable period of time. Not so complementing for Agile.
Examples from the post:
“[Scrum]… guidelines are reminiscent of mild to extreme socialist-economic models…”
Agile and Socialism are very, very much apart from one another. To name one major difference, Socialism calls for uniformity; Scrum advocates “One size does not fit all” – even within the same organization and team.
“Scrum recognizes no titles for Development Team members other than Developer…”
There is confusion here between title and role. A Developer can, and is expected to take the role of, for example, a Programmer, and it will be a disaster for the team if this particular person would write technical documents – and the team, all Developers in the team, are expected to recognize that.
Coming back to the opening of the blog post:
“Over that last decade we have seen […] Agile software development methods […]” (emphasis not in original).
Agile and Scrum and other similar modern organizational concepts, do not define themselves as methods. Instead, they define themselves as frameworks, which, the organization is expected and encouraged to adjust and then inspect-and-adapt indefinitely.
“So what can we expect when we take a […] team […] of highly competitive and smart individuals?”
It so emerges that Scrum does not encourage hiding competition within the team. Nor does it suggest that competition is neither bad nor good. Instead, taking Gabi’s example, competition is there, and the team and its eco-system should practice examining whether such competition is helpful or detrimental. Thereafter, team members should decide together how to address such competition.
So where did we go wrong?
I am suggesting that there is something else lurking here. Agile is failing because practitioners do not recognize that the resistance has a meaning. Conversely, organizations that relate to this resistance as meaningful data succeed in addressing them, become successful in implementing Agile.
For example, resistance could symbolize the fear within management in light of the extreme uncertainty. Even if this organization did, with great intention, everything Gabi himself advocates, I wish to hypothesize that they would still sabotage Gabi’s advice because the uncertainty as a source of fear would still remain.
The fact that these (more or less) 5% of organizations transitioning to agile succeed is not merely because they are becoming Agile. I wish to hypothesize that they succeed because they are conscious of potential sources to make them fail.
That is why Agile is still failing, as will any other new buzzword in this industry.
Yes, business people and engineering people should communicate better. Yes, business people should have a clearer say than is currently prescribed by Scrum. Will writing this on a manifesto and advocating it help? Hell, no. Well, not until we look at each specific organization with its own unique and concrete fears, anxieties, pitfalls, etc., and stop looking for any kind of silver-bullet that will save all organizations.
Becoming agile 