Meanwhile Scrum becomes very popular development process. Why ever.
There are nice things about Scrum and there things which are not that nice. Let us discuss one unnice thing – issue of scalability. It is not that trivial and there is no common opinion regarding the issue. The majority believes the possibility of Scrum in big-scaled projects it could be the а question of maturity of the organization, but I don’t believe.
It happens when management tries to implement Scrum for large projects and multiple teams. That phenomenon has different names, e.g. Scrum-of-Scrum. Typically experts discuss how technically Scrum-of-Scrum can be realized and the sociological aspects are ignored. But what if the core reason of scrum success is the sociological one?
I have experience with Scrum under different conditions and with different results. On the one hand an example where Scrum leaded to a great success – there was a team responsible for a sub-system of a large-scaled system. The sub-system caused only problems for very long time until the team implemented Scrum as its development process. In couple of months the team made the delay good of last two years and finished their part of the project in-time. BUT the sub-system was a loosely-coupled from the rest of the system and the team managed Scrum independently from the rest of the project and other teams. On the other hand there are several examples I experienced when managers rolled out and forced Scrum-of-Scrum for multiple teams. They tried it for years but it won’t be a success despite all the consultants and trainings. In fact it wasn’t better then the old good V-process we had before, I believe it got worser.
But why? Why didn’t we have any success? Did we something wrong? Or probably it’s really a characteristic of Scrum?
I tried to understand it for years – and once I’ve noticed some parallels between the successful Scrum teams and those successful communes at the end of the 19th century which leaded to the belief the communism will be the most successful social order ever.
I grew up in the country where people tried to make it real – the communism – was supposed to bring the heaven on the earth. I also spent a lot of time trying to understand the reasons why it could never be a success.
Let us check:
We have a prove – the communes can work, people work together, help each other, spend their whole energy for the common goals and have fun. It does not work always and you can not implement it by force, but it definitely can work. And we have very similar situation regarding the Scrum teams, sometimes it works fabulous, sometimes it does not work. But in both cases: neither the communes-of-communes (communism) nor the Scrum-of-Scrum (common Scrum for multiples teams) works well. At least I do not know even one real success story.
Today I came to believe the phenomena of commune and Scrum cannot scale just because of restrictions of the human nature. To be successful the participants of a commune or a Scrum team need to share a common goals between team players – the people you well know and trust and empathize. The problem is – humans are not able empathizing with hundreds of people, such feeling is restricted to couple of persons you really well know, people cannot share one goal across different teams, every team has it’s own goals, even if common meta-goal is known, members of other teams feel like competitors regarding the resources achievement of milestones, etc. – all in one – the human feelings does not scale – that’s the reason.
Summary
In my experience, a successful Scrum team – it is always a commune of comrades who share the goals and tasks, help each other and have fun of work. In that case the product owner is a person responsible for goal definition and the scrum master is responsible for the team spirit and for the conflict resolution. It’s a cool experience. What is not cool at all – if somebody tries to implement such approach by force and to apply it to big organizations, because the communism is a nice in dreams but horrible in reality.
However some of the Scrum attributes – like iterative development, backlogs, user stories may be used for large-scaled projects, why not, but not Scrum itself.
Hi!
Interesting article and quite good message. If you think, scrum can/will not scale for bigger projects, I really would like to read about your opinion about SAFe – http://scaledagileframework.com/
Thanks,
j.r.
@J. R. Hermes: I need to correct myself, actually the agile framework addresses the scalability, because the business analysis and the architecture (both) come before the teams backlogs in that framework. Nevertheless it proposes how to organize the whole organization. Why it should be helpful? Why every development department needs scrum? Imagine you have different supplier companies, should you try to define how they have to work? I don’t think so.
@J. R. Hermes: thanks for your comment!
I’m not sure if I understood well the scaled agile framework. However here is what I understood:
1. It’s not scrum, scrum just a sub-sub topic of its framework
2. It requires a lot of roles => you need to change your organization, what is risky and without a guarantee of success
3. The framework tries to define an organization where the teams should be able working using scrum => scrum seems to be set already as the best development approach – really?
4. The whole pro-argumentation is build on the comparison with the waterfall model – too weak
And finally i did not understand why it should scale well It tries to adress the organizational issues, but not the socialogical, it describes which preconditions which have to be fulfiled (e.g. how management has to act), but not how to achive it. What qualities are required to adress the scalability is not described at all.
I believe if the authors are able to improve an organization, it will happen due to their personal experience and qualities but not due to the described framework.