Scrum is a successful and widespread framework, but at some point almost everyone started to talk about scaling. Large organizations want to spread this miracle and Agilize everyone. Many consider agilizing large organisations as bad, and some say it is inevitable. In any case, opinions are often negative about “big Agile”.
But what exactly is being scaled when we talk about scaling in Scrum or Agile software development? It seems that most imagine growing something larger, usually the number of people, or painting everyone in fake Scrum colours. “I see task boards, task boards everywhere!”. :-)
Naturally, this triggers negative reactions from the Agile community.
“Why would you want to deliver and support a product with multiple teams, when one team is so much more effective?”
The first purpose of LeSS (Large-Scale Scrum) is actually descaling through organizational change. Descaling the number of roles, organizational structures, dependencies, architectural complexity, management positions, sites, and number of people. LeSS is not about scaling one team into multiple teams. LeSS is about scaling up Scrum itself in order to achieve organizational descaling. Just to be clear, looking for a scaling framework to “buy and install” and to organize lots of people for the sake of “painting agile or Scrum onto our big group”, is just plain wrong.
A major purpose of LeSS is to expose the pain of being large, wasteful, and slow.
Here’s a common thought that people have when they learn and like the idea of descaling, rather than “big Agile”:
Why should an organization scale up Scrum? Why not just have many independent Scrum teams, each dealing with their own product and own users?
This leads to a very important question: What should be the definition (or scope) of a product?
Bas Vodde, the co-creator of LeSS (Large-Scale Scrum), gave this nice explanation:
Having multiple ‘fake’ small products that don’t deliver any real value is not better. Neither is losing the overview due to many small products.
Contrast these situations:
Small independent products
We take the large product and split it into smaller ‘independent’ products, with a few dependencies. This is nice as smaller is better. However, now in the organization we’ll need to figure out which of the products the teams need to work on. So therefore, we’ll need to add “portfolio management” so that we ensure the teams work on the high value products.
Not only that, we have now dependencies between the products. These are outside the products and hence it is probably more difficult to see when they happen and harder to coordinate by the teams themselves. Thus, we’ll need to add some project/program management to ensure the features in different products are synchronized.
Where do we put all that. Probably a PMO which we’ll need to create for that.
Large product definition
Now, the alternative. We define product broader. This means we’ll more quickly end up with LeSS Huge… but… we don’t need any additional portfolio management nor any project/program management to deal with all the organizational issues and different resource allocations :)
Though, we have a large-scale product… all these things are managed within the LeSS framework and … thus actually much less complex. Less roles, less management and a better overview.
Hence, we prefer a broader product definition, unless the products are truly independent products
A similar comment could be said about users and customer, since they are very much connected to definition of a product. A team dealing with a fake small “product” is likely to have fake users. “Our user is another product, and our customer is an IT application manager”. Or even worse, “Our user is the QuotingEngine,” where the so-called “products” are just architectural components, and other components are fake users. You don’t make any money from another internal component!
Just like Scrum, LeSS removes your organizational band-aids that apparently solved the problems, but actually masked them and didn’t address the root causes. “We have a quality problem, let’s create a quality manager, and then the pain is gone… for now.” Scrum is a band-aid removal system on a team scale, while LeSS is a band-aid removal system on a multi-team and organizational scale. With LeSS, transformation happens along two dimensions:
Create organizational flexibility to always work on the most important goals from the overall customer-perspective product level, based on recognizing a world of learning and change. LeSS replaces big-batch and rigid portfolio management practices and decisions, where investments are matched to objectives, often for a year or even longer. The traditional project and portfolio management model also implies a fixed allocation of teams to specific programmes and projects, also for a long time.
In contrast, an example of the LeSS solution is one Product Backlog and one Product Owner for a whole product. Based on feedback and learning, a Product Owner can change direction and assign new goals with increased flexibility at a low cost of change, since teams are not fixed within boundaries of projects and programmes.
Each cross-functional feature team grows capability and responsibility for taking care of the whole value stream. Ideally, all teams co-create and maintain value together with the end-customer. The Definition of Done is far-stretching and all teams deliver each Sprint one single potentially shippable product increment for all involved teams. The foundation for this is made up of technical-excellence practices such as continuous integration, ATDD, TDD, etc.
During a LeSS adoption, along both dimensions of “do the right thing and always the most important thing” and “do things right”, it becomes painfully evident that parts of the original organizational structure are not needed. For a single product, a LeSS organization does not need portfolio, programme, or project management. It does not need a separate analysis, architecture, UX, or QA/test group. It probably does not need a separate operations group.
In LeSS, the basic organizational building block is the cross-functional and cross-component feature team. Most people will simply become regular members of feature teams, delivering running, tested features and a shippable product every Sprint. It’s very simple. There are no fancy titles, no release trains, no layers of management. But some people will also leave because they do not fit in this new value-driven organizational structure that emphasizes hands-on making solutions over status and “managing”.
We often have a gut feeling that there’s untapped potential: what if our organisation can create value with fewer teams, or even with a single team? If that possibility is present, how would we know what to look for? LeSS gives us the means to see this potential, and act upon it.
A goal of LeSS is to create a learning organization with a high level of collaboration and knowledge sharing through communities and other means of coordination. This is important to prevent duplication and the potential architectural chaos of having many empowered but potentially disconnected teams. But a learning organization doesn’t happen overnight. An organization that grows this culture, driven by the LeSS framework, will take time.
In short, LeSS is a scaled up Scrum framework, which enables descaling of the organization.
Also posted on leanarch.eu blog
RSS feed