LeSS Structure for Enterprise Agility
Although LeSS is a framework for enterprise agility in large organizations, it counters the traditional hierarchical structures found in many large organizations. The term “structure” is almost a misnomer. A better term might be “roles and teams.”
A Scrum team is a self-managed, cross-functional group of three to nine people who do it all, from writing code to producing documentation, to creating a part of a product and integrating it into a functioning increment of the product. In LeSS, numerous teams work in parallel and together on a single product with the common goal of delivering a shippable product at the end of a given sprint. Each team has the following characteristics:
- Each team member is dedicated to only one team; a person can’t be pulled off a team to work on another team.
- Teams are cross-functional, meaning each team contains all the skills needed to produce a shippable product.
- Members of each team work together in the same space to promote communication, cooperation, trust, and shared learning.
- Each team remains together for as long as possible to improve the ability of team members to work as a unit.
Feature teams are cross-functional, cross-component, stable, and long-lived. They take customer-centric features from the product backlog and complete them to deliver a potentially shippable product increment.
The “feature” in “feature team” highlights the difference between feature teams and component teams:
- Feature teams: A feature team has all the knowledge and skills required to build a feature, such as a feature in an accounting program for producing an accounts payable report (to show which customers owe money and how much).
Think of a feature team as a small, flat organization within the larger enterprise. Everyone on the team works together to deliver the product. Everyone in the rowboat rows, just as they do on any agile team.
- Component teams: Component teams handle various aspects of a feature. For example, to produce an accounts payable report, you may have a component team that works on the database, another that works on the user interface, and a third that focuses on presenting the data in a report. In this example, three component teams would be involved in delivering the feature, and they would need to work closely to coordinate their work.
The component team model results in a lot of dependencies, as shown by the arrows from the items in the product backlog (in the column on the left). Because each work item requires two or more teams to complete it, one team may need to wait on another team to complete its work before it can move forward on that item. It also requires a great deal of cross-team coordination and communication, as shown by the double-headed arrows connecting the teams. No single team has the knowledge and skill set to complete a work item on its own.
In contrast, each feature team can choose one item from the product backlog and complete it without the help of another team. As you can see, none of the teams is connected to another. They all have the knowledge and skills required to work on each component of the product, so Team Wei can complete Item 1 by working on any and all Components A, B, or C, without depending on any other team to complete its work.
The Scrum Master has a deep Scrum understanding to guide and coach the organization on Scrum principles and practices, so they have a better understanding of how to deliver value to customers. Each Scrum Master has four focus areas:
- Product owner
- Development practices
Don’t think of the Scrum Master as team leader. The Scrum Master serves more of a role as advisor to bring everybody up to speed on Scrum, to educate and coach teams in self-management and shared responsibility, and to prepare product owners for their role and facilitate their interaction with their teams.
Communities of practice
Communities of practice (CoPs) are groups of people that gather informally around a certain functional area of expertise, such as software development, analysis, or testing, to share their knowledge and expertise and discuss their challenges. Essentially, they gather to talk shop. CoPs cross team boundaries, which can improve communication and cooperation across teams. For example, Scrum Masters may decide to meet as a group to share what they know about Scrum and exchange ideas of how they can help the teams, product owners, and organization overall.
Although organizations don’t form these groups, you can encourage their formation by providing time and space for the CoPs to meet, information technology infrastructure, learning materials and other resources, and perhaps even snacks and beverages.
The LeSS organizational structure is flat. The head of a product group is a product manager who works to support the product owner and teams in their efforts to produce a quality product and the perfect system for developing it. The head of a product group may help the team remove obstacles or improve its knowledge and skills.
Note that the organizational chart includes an Undone Department. Ideally, the nature of cross-functional teams makes this department unnecessary, but sometimes a team lacks the knowledge and expertise, such as testing, quality assurance, or business analysis, to complete a shippable product. When that happens, the undone department must complete the work.