It’s the age old debate. ‘I want self organising teams, but I need to set some constraints. I want some level of prescription, but how much is reasonable? When does it start disempowering the teams?’ This balancing act is being played out the world over in organisations adopting Agile. As an Enterprise Agile Coach and Large-Scale Scrum (LeSS) trainer, I spend a lot of time with leaders on this very topic.
There are a few scaling frameworks out there. What separates them, from what I can see, is the level of prescription and what they choose to prescribe. Most can be effective to a certain extent. They are certainly a big improvement on the 6-12 month waterfalls that they often replace. In this article, I will be talking about one framework in particular; Large-Scale Scrum, or LeSS as it has become known. In particular, I shall be discussing how using ‘barely sufficient’ prescription can allow for the most effective teams.
What is scaled Scrum?
So what is ‘scaled’ Scrum anyway? I hear this term used in a few different ways. I shall start with what I don’t mean; Multiple Scrum Teams. A Scrum Team consists of a Product Owner, Development Team and ScrumMaster all working from a Product Backlog to develop a product. Having multiple Scrum Teams working on distinct products is not ‘scaling’ Scrum, it is merely multiple separate instances of Scrum. What I am talking about here is two or more Development Teams working from a common Product Backlog against a common product. In short, multiple team Scrum not multiple Scrum Teams. This is a subtle, but important distinction.
How much should we prescribe?
People feel comfortable with highly prescriptive methods. I understand that. They are like a warm blanket to wrap around yourself, keeping you safe from uncertainty, and ensuring the reins of power and control stay out of the hands of those pesky ‘self-organising’ teams. They also ensure that all teams are working in the same way. Surely there is one approach that is best for all teams. Right? The drive to standardise stems from a complete misunderstanding of the teachings of Taiichi Ohno (the father of the Toyota Production System and indeed Lean Thinking).
Prescription can be useful. With too little prescription, teams and organisations often do not know where to start. You see this with approaches based purely on values and principles. People don’t know whether they are doing it because it is not clear exactly what it is. In the absence of something more concrete, real change is often avoided.
Too much prescription, on the other hand, is equally troublesome, but in a different way. Approaches that prescribe many roles, structures, processes and techniques can be difficult to comprehend, inhibit learning and are not adaptable to different contexts. Teams end up in a sort of zombie process with nobody thinking about why things are done this way or how it could be done better. Everyone just follows the rules without question.
Ultimately, the more complex the rules, the less people use their brains. The more prescriptive the process, the less teams take ownership of it. Whilst some prescription is necessary, every time a rule is prescribed, the team is that little bit less empowered to own their process. At some point, the balance tips too far and teams are no longer self-organising. It is a difficult balancing act, especially when working with multiple teams. There is huge complexity in large-scale product development. The only way to truly succeed in that context is to have those with the most information making most of the decisions around how to work i.e. the teams.
How much does Large-Scale Scrum (LeSS) prescribe?
LeSS is one of the least prescriptive of the popular scaling approaches. Rather than tailoring down a process from a large buffet of options, LeSS seeks to build up the process from few rules plus experimentation. Learning the lessons from Scrum, LeSS gives teams just enough to get going, then leaves the rest up to each organisation to fix. Of course there is guidance in the form of things you could try, but ultimately, each context is unique and the approach should reflect that. A cookie-cutter solution will only get you so far. If it could be summed up in one sentence, it would be: start simple and add complexity only when it is necessary.
So what are the kind of things LeSS prescribes?
1) The Scrum roles, artefacts and events still apply. Large-Scale Scrum is Scrum scaled. It is not, like some other scaling approaches, a heavyweight process that just happens to use Scrum at the team level. 99% of what holds true for one-team Scrum is also applicable to multiple-team Scrum. Anyone who is familiar with Scrum will feel at home using LeSS. There are, of course, some extra tools and techniques to deal with the added complexity, but these are kept to a minimum and mostly decided by the teams.
2) Build real teams. Teams are the fundamental building block of organisations. In product development, we aim for high-performing teams, but often do not provide the environment to achieve it. In LeSS, the majority of teams should be dedicated, long-lived, self-managing, cross-functional, cross-component and co-located. The Scrum Guide states that teams should have ‘all of the skills as a team necessary to create a product Increment’. At scale, it is necessary to take that further and insist on feature teams over component teams (look out for my next post on feature teams). Teams should be able to fully implement customer-focussed features within a sprint with minimal dependencies on other teams.
I appreciate that the above is very hard to achieve, especially in large organisations. It is prescribed for a very good reason. Compromising here will dramatically reduce an organisations agility and will result in teams achieving only a fraction of their potential. It does not need to be in place on day one, but a commitment, and a plan, to achieve it absolutely should.
3) For each product, there is one Product Owner and one Product Backlog. This is the rule that often sends people into a tail-spin. What? Not a Product Owner per team? Sacrilege!! Well, as you would expect, it is a little more nuanced than that. The Scrum guide was written from the perspective on one-team Scrum. It has the PO working directly with the team. One team one PO right? Well, maybe. Another way of looking at it is one Product Backlog one PO. Let’s refer back to the Scrum Guide. It states that; ‘The Product Owner is the sole person responsible for managing the Product Backlog’. Is also says; ‘The Product Owner is one person, not a committee’. If you think about it, the PO owns the product vision, does all prioritisation and decides when to release. Does that sound like a job for 20 people? Think of the Product Owner as the person who owns the product. An apt name indeed.
Now. Allow me, if you will, to address the elephant in the room. If there is only one PO, how can she work with the teams throughout the Sprint to answer questions and accept backlog items? And therein lies the challenge of scaling the PO. The PO broadly has two day-to-day responsibilities; prioritisation and clarification. Back to the Scrum Guide ‘The Product Owner may do the above work, or have the Development Team do it’. In LeSS, the PO remains responsible for product strategy and prioritisation, however, they may not do the day-to-day clarification and Backlog Item acceptance. Putting teams in direct contact with customer or subject matter experts who can clarify Backlog Items not only allows the PO role to scale, it removes an unnecessary hand-off in the value-stream.
4) One synchronised Sprint cadence. To put it another way, the product sprints not the teams. If teams all start, and end, their Sprints on different days, when will the product be truly shippable? When will you hold the overall Sprint Review? With everything synchronised, these things do not become an issue.
5) One common Definition of Done for the product. There must be a shared understanding of what ‘Done’ means for the product. That is not to say that teams may not strengthen it, but, in the interest of transparency, there must be a minimum DoD that is understood by the PO and stakeholders.
6) An integrated, shippable product at the end of each Sprint. This is straight out of the Scrum Guide and does not change at scale. If this is not the case, you will have to focus on strengthening your DoD until you are able to achieve this. Employing modern engineering practices is not mandated by LeSS, but I will go as far as to say that without continuous integration, a focus on clean code and high levels of test automation, you are almost certain to forever have very low levels of agility. There is no substitute for discipline. Good Scrum is inherently disciplined in this way. You will be surprised how taking a few small steps each Sprint will make a huge difference.
Scaling is hard. Really hard. It is often tempting to search for an off-the-shelf approach that will work everywhere. Unfortunately, every context is unique and requires a different approach. There are however some patterns that can be employed to speed up your learning.
As for prescription, you must strike a balance. Too much, and you will end up with an inflexible solution that does not take into account your context and disempowers teams. Too little, and people will be lost when it comes to getting going and will probably not change anything. My advice, prescribe as little as you can, and use experimentation to guide you towards something that works for you. Empiricism shall prevail.
Follow on Twitter: @KarimHarbott