Large Scale Scrum (LeSS)

 Large Scale Scrum (LeSS) takes a completely different approach to scale. In fact, the term that LeSS uses is NOT scale, but De-Scaling as the pinnacle of the scaled organization for Scrum and Agile.

Where other frameworks look to align the Agile approach to teams within a Traditional Organization, or show how those people can now "fit" within the organization; the LeSS approach is to say 'no.' No more "pretend Agile" or "Fake De-Scaling" where all the parts of the products that come together are considered independent and managed independently. 

This leads to trap where teams try to act as independent teams within an organization:

• "Independent Teams" need a portfolio manager to ensure alignment of efforts, because otherwise they'll diverge
• Portfolio Management leads to integration and dependencies,
• Dependencies re-introduce the need for the Program Management Office (PMO) to institute rules of coordination
• Rules remove ownership and power from the Scrum teams, and quickly lead to additional complex teams to manage them

To avoid all this, the LeSS system provides two types of scaling of Products to remove other potential roles:

• LeSS - used for up to eight (8) teams of eight
• LeSS Huge - used for up to thousands of teams delivering products together in single increments

This way the organization can avoid unnecessary "dotted lines" that take away power and control from the Scrum Teams which in turn zaps productivity and pride of workmanship.

 

 The LeSS system provides two types of scaling of Products to remove other potential roles:

• LeSS - used for up to eight (8) teams of eight
• LeSS Huge - used for up to thousands of teams delivering products together in single increments

This way the organization can avoid unnecessary "dotted lines" that take away power and control from the Scrum Teams which in turn zaps productivity and pride of workmanship.

According to the philosophy behind LeSS, Scrum works as it is designed for one team. And it shouldn't be changed for one team. No matter the complexity of the product, it should remain that there are three roles:

• Product Owner (PO)
• Scrum Master (SM)
• Development Team Member (DT)

And in the LeSS these roles persist and remain the only roles for up to eight (8) teams. It's important to note that LeSS suggests that teams be aligned to features to maximize their ability to "specialize" on the architecture of a product and work independently.

Beyond eight (8) teams only one additional role is added to support the Product Owner. This role is the Area Product Owner, and they are needed because of the pressure on the Product Owner to manage such a large backlog is too great:

• Area Product Owner (APO) - provides a buffer of work definition and act as intermediaries to help manage an "area" of requirements
• Product Owner (PO) can have up to ten (10) APOs working with them to manage requirements, forming the Product Owner Team
• Can manage up to eight teams
• Cannot override the prioritization of the product backlog items - this still belongs to the PO

At this point there is enough "scaling" that it can handle global operations of product development. Sites can have multiple teams, and areas can include anywhere from five to ten teams. When multiplied this allows a single Product Owner to manage up to a thousand or more team members.

But why create such large structures of Scrum?

The answer is using Large Solutions to De-Scale the organization.  Organizations looking to create smaller, more independent teams to Scrum will drive towards an model that performs "Fake De-Scaling." These ideas are as follows:

• We create "independent" teams with internal and external markets, everyone has customers and are consumers of Agile teams
• For larger products, "independent Teams" need a portfolio manager to ensure alignment of efforts, because otherwise they'll diverge
• Portfolio Management leads to integration and dependencies because there are real-word physical dependencies in products
• Integration and dependencies drive the need for rules so teams can stay independent
• These rules re-introduce the Program Management Office (PMO) to control coordination
• Rules remove ownership and power from the Scrum teams, and quickly lead to additional complex teams to manage them

So what does the organization then look like for the LeSS company?

For those that there will be an enabling leader who is the "Head of Product." This person will provide coordination and support using the Servant Leadership model of management. The responsibilities include managing:

• Site Locations - ensuring the teams are supported with facilities, people, etc.
• "Undone Departments" - those departments that are still functionally aligned or separate from Scrum Teams
• Support Teams - these teams provide a lean service of support to the large teams (such as delivery or DevOps)
• Product Owner Team - led by the PO in charge of the product, this team develops and prioritizes the backlog
• Competence & Coaching - the functions of training and coaching to ensure continuous improvement

Higher levels of management are intended to provide similar types of "servant leadership" support for the organization. The goal being to enable teams to work according to the LeSS principles:

• Large-Scale Scrum is Scrum - LeSS is just dealing with the unavoidable scale of some products, but remains scrum
• Empirical process control - processes should be subordinate to the product and market needs
• Transparency - required to drive fear out and improvement into the workplace
• More with Less - gain better teams, ownership, and reduced waste with less process and control
• Whole-products - focus on the product in delivery, not just the part of the product, so efforts are aligned
• Customer-centric - by focusing on the customer, everyone aligns to the priorities and needs while reducing waste of other distractions
• Systems thinking - understand that the system is the focus, not the local performance of a team, so waste is reduced and flow is optimized
• Lean thinking - continuous improvement and the Go See approach to management drive a respect for workers and continuous improvement
• Queuing theory - understanding that long queues increase cycle time, reduce feedback speed, increase variability, and result in multi-tasking

To learn more about these concepts go to: https://less.works/

Sources:

• De-Scaling Organizations: https://less.works/blog/2015/05/08/less-scaling-descaling-organizations-with-less.html
• How too many rules at work keep you from getting things done: https://www.ted.com/talks/yves_morieux_how_too_many_rules_at_work_keep_you_from_getting_things_done#t-983376
• Requirements Areas: https://less.works/less/less-huge/requirement-areas.html
• Area Product Owner: https://less.works/less/less-huge/area-product-owner.html
• LeSS Organizational Structure: https://less.works/less/less-huge/organizational-structure.html
• More-with-Less: https://less.works/less/principles/more-with-less.html
• LeSS Role of a Manager: https://less.works/less/management/role-of-manager.html
• LeSS Principles Overview: https://less.works/less/principles/overview.html

Additional Great Video Resources:

• Scaling Agile with LeSS Large Scale Scrum: https://www.youtube.com/watch?v=dKEIaJ7qBew
• Introduction to LeSS (Large-Scale Scrum): https://www.youtube.com/watch?v=1BZf_Oa7W94