“Don’t do it! If you can avoid it, do not use a scaling framework!”
Imagine how puzzled I felt once the trainer kicked off the Scaled Professional Scrum course with this sentence! My enthusiasm dropped immediately but the curiosity grew even stronger: Why does he mean it like this? He got me!
The 2 days-course was great and very insightful but my main take-away was the perception change on using a “silver bullet” solution to scale Scrum. It was like a paradigm shift with lots of “Aha” experiences, which actually showed how bound I was to my initial perception about scaling Scrum.
So what is “scaled” Scrum about?
It is still Scrum but with more than 3 Development teams working from a common Product Backlog against a common product. At the end of every sprint, a potentially shippable product increment should be available. Having multiple Scrum teams working on distinct products is not “scaling” Scrum, it is merely multiple separate instances of Scrum.
This article is not about comparing the existing scaling frameworks. I think of any “framework” as a set of practices, principles, roles that…should be applied wisely. Some of them come with a lot of material, other with very little. I don’t know which is better but I know that different people and organisations have different needs, depending on what they already know, their culture, their software, their business model etc.
What do we think it will help us? How much should we prescribe?
Some will need very little guidance, some need all the support they can get. Some are happy to experiment what will work best for them (embracing inspect and adapt) and some are reluctant to figure this out and block initiatives of this kind.
I can understand why people feel comfortable with highly prescriptive methods: they keep us safe from uncertainty. They also ensure that teams are working in the same way by using an identical approach. Too much prescription though, about roles, structures, processes and techniques, can be difficult to comprehend, inhibit learning and are not adaptable to different contexts. It kills creativity and the desire to challenge the status quo. Everybody is following the rules without questioning them.
On the other side, with too little prescription, teams and organizations often do not know where to start. The lack of concreteness will make people avoid the change. You might have dealt so far with situations where you had to do something without knowing exactly what that something is.
Ultimately, the more complex the rules, the less people use their brains. The more prescriptive the process, the less teams take ownership of it. Large-scale product development is extremely complex and the only way to succeed in it is to have those with the most information making most of the decisions around how to work.
Before choosing to implement a scaling framework, the leaders in the organisations should start thinking about answering these questions:
- Why scale? What are we trying to achieve? Do we expect that by adding more teams we will get greater results? What’s the goal? Is it increased productivity or maybe more value?
- How can we do more with the current setup (automation, training, removing organisational impediments, increase the focus on value)? Everything that hurts in single team Scrum, is going to be painful at scale.
- How often is the work going to be released?
- What techniques will be used to integrate the work to that frequency?
- What will be done to measure and manage the work and its integration?
- What overhead is being absorbed to achieve this integration and delivery?
- Are the cost and benefits of delivery frequency balanced by value returned?
- How is the cost going to be systematically reduced?
Scaling is hard. Really hard, but not impossible. We should not compromise autonomy, desire for continuous improvement, and professionalism just because we are working at scale.
References:
Scaling Scrum https://www.scrum.org/resources/blog/scaling-scrum
