Top 10 Typical Cases of Misunderstanding LeSS

Many companies, in their attempts to become more product centric and customer-focused (THANKS!!!), jump on the idea of experimenting with Large Scale Scrum (LeSS), as the mechanism to deliver incremental value to their customers and users/stakeholders. However, due to the lack of qualified guidance and in a high-pace pursuit of fast results (e.g. chasing a next level of maturity year-end goal or managerial pressure), companies frequently derail in their initial attempts to adopt LeSS properly and digress into old habits that are mixed with a new terminology.

Below, are some (top 10), most frequently seen, examples of least desirable, from-the-start, omissions in understanding LeSS that lead to piled up problems, in later phases of LeSS adoption:

1 – Definition of LeSS

• Typical Misunderstanding: LeSS is an improved Scrum – a “methodology”/”operating model” that can work effectively under multiple layers of traditional organizational structure.  LeSS is an approach that technology teams (R&D) use, to increase efficiency, productivity and speed of delivery.
• Improved Understanding: LeSS is Scrum-based, organizational design (in itself!) system that is used to deliver customer value, by building and shipping product (large) features incrementally to external customers and/or internal users. Adoption of LeSS requires deep rethinking of organizational design, reporting structures, budgeting, site strategies and HR norms. In LeSS, business and R&D are not separate competing/conflicting organizations. In LeSS, biz & tech are truly together (part of the same reporting structure).  LeSS organizational structure is the first-order factor that defines system dynamics and it does it differently from a traditional organization.  Reference.

2 – LeSS Adoption Principles (All 3)

• Typical Misunderstanding:  LeSS adoption involves only lower parts of an organization (bottom-up only approach).  LeSS adoption involves thousands of people from a get-go, and is based on teams’ alignment in some ‘agile’ tool, while following enterprise-wide sprinting schedule (broad & shallow approach).  LeSS adoption decisions are made by first- or mid-level managers on behalf of teams/developers (sometimes, hardly promoted by internal agile centers of excellence) – by creating teams and assigning people to teams.
• Improved Understanding:  LeSS adoption involves many organizational levels: from teams/developers to executive management (top-bottom and bottom-up approach).  LeSS adoptions, at least initially, involve a limited number of developers (around 50, or so) and 2-8 teams.  LeSS adoptions are deep & narrow and by volunteering. Reference.

3 – Step 1 of Adoption: Educate everyone

• Typical Misunderstanding: “Let’s send all team members and mid-level management to LeSS training. Senior executives do not need to re-learn organizational design. They already understand it well (this is why they are executives).”  And then: “Lets our trained managers and agile leads teach the rest of an organization what LeSS is, by creating a lot of internal documentation (decks, wiki pages, etc.)”
  Improved Understanding: One of LeSS adoption principles is “top-bottom and bottom-up”. It means that senior executives (top) MUST re-learn, as much as teams/developers (bottom – sounds horrible, we know!) do. Executives should not exempt themselves from learning, by delegating it to the layers below.  Reference.

4 – Step 2 of LeSS Adoption: Define ‘product’

• Typical Misunderstanding: “Whatever is defined today, as a component team’s scope of work or a horizontally defined component (application, infrastructure, platform, shared services, ‘tech for tech’) – is our product.”  “Le’t rename a budgeted project, program or portfolio into our product.“
• Improved Understanding: Simply speaking, something that, if sliced thinly (vertically) into small, relatively independent features (multiple integrated components), could be shipped to external customers or internal users (and monetized, generate ROI).  Reference.

5 – Step 3 of LeSS Adoption: Define ‘Done’

• Typical Misunderstanding: ‘Done’ – is how each component team signals their completion, when they reach a sprint-end. DoD can vary widely, from one user story to another, from one team to another, from one team backlog to another team backlog. When a ‘Closed’ button is clicked in our agile project management tool, a user story is ‘done’, despite the fact that it may take additional multiple steps (sprints) and other teams’ work, to get a user story to production. “DoD – will, most likely, remain consistent over time.“
• Improved Understanding: ‘Done’ is a minimal (and gradually widening, a.k.a. maturing) internal agreement between multiple teams that work on the same product, out of the same product backlog, for the same Product Owner. DoD should be as broad/inclusive as possible, to minimize any ‘Undone’ work that prevents from releasing a feature.  In LeSS, each team, internally, may work on continuous improvement of its own DoD that is more inclusive than a shared, by all teams, DoD.  Reference.

6 – Step 4 of LeSS Adoption: Properly structured teams

• Typical Misunderstanding: Delivery team. Component team. Single-function specialty team. Geographically distributed team. Managed by the same manager team.
• Improved Understanding: Long-lived, cross-functional/cross-component, self-managed, co-located/co-time-zoned team. A product team = Feature team (a team that can work on various features of the same, widely defined product).  Reference.

7 – Origins of PO:

• Typical Misunderstanding: Senior Project manager. Senior Program Manager. Senior Portfolio manager. Technology Manager.  Someone, who manages a large body of work, loosely coupled with a real product definition.
• Improved Understanding:  Mini-CEO of a product.  A person, with a very broad range of authority and capabilities that include control of a budget, vision, mission and strategic goals.  A person, whose traditional organizational title could be a Product Manager, Head of Business Operations, Head of Marketing/Sales, senior user.  Reference.

8 – Requirement Area

• Typical Misunderstanding: Development Area. Architecture. Code ownership per sub-system. Technology language. Shared services. Platform. Infrastructure. Component/Application. Body of work that is supported by very few (e.g. only one or two) teams.
• Improved Understanding: Large area of customer-centric requirements. Customer-focused (spoken in customer language) product domain. Large body of work that usually requires closely coordinated work of 4-8 teams (C/F product teams). Reference.

9 – Area Product Owner

• Typical Misunderstanding: Ex-Business Analyst. Ex-Product Analyst. Ex-Systems Analyst. Ex-Project manager. Ex-Program Manager. Ex-Portfolio manager. Someone, who manages output (not real business outcome) of incorrectly defined (as per above) ‘Requirement Area’. Someone, who is a part of traditional organizational reporting structure, frequently (mistakenly) rolling into Research & Development R&D, instead of a line of  business (LOB).
• Improved Understanding: A real Product Owner (properly positioned organizationally) who has authority, empowerment and control over strategic decisions, vision, mission and budget of a large [Product/Business] Requirements Area, of a much larger product. A person’s traditional organizational title could be a Product Manager, Head of Business Operations, Head of Marketing/Sales, senior user. Reference.

10 – Motivation and Incentives

• Typical Misunderstanding: Individual performance appraisals (IPA) and monetary incentives that tied to them, do not cause teams’ morale deprecation, individuals’ unwillingness to learn from/teach each other, own/work/deliver together, share & care for each other. Adaptive product development, such as Scrum and LeSS, can be done successfully, even without changing a company’s HR norms and policies.
• Improved Understanding: Individual performance appraisals (IPA) are mostly ineffective and harmful. They lead to system gaming and inability to ‘read’/guide/improve the system (organization). In adaptive environments (e.g. Scrum, LeSS), IPAs should be abolished (or, at least, minimized in impact), in favor of teams’ self-governance/assessment and team-level incentives.  Reference.