This page is shown in English as no translation to 日本語 is available.

Organizational Structure

How does this all fit together in an organizational structure? Of course, each organization is different, yet LeSS organizations tend to follow a surprisingly simple structure. The first difference between LeSS organizations and most traditional ones is that the structure is stable as (1) work is organized around teams, and (2) mismatch of skills triggers learning and coordination within existing teams.

LeSS Organizational Structure

A typical LeSS organizational chart looks like this:

Notice what isn’t here:

  • No project/program organization or project/program management office (PMO).
    These traditional control organizations cease to exist in a LeSS organization as their responsibilities are distributed between the feature teams and the Product Owner. Insisting on keeping such organizations will cause confusion and conflicts of responsibilities.
  • No support groups such as configuration management, continuous integration support, or “quality and process”.
    LeSS organizations prefer to expand the existing teams responsibility to include this work over creating more complex organization with specialized groups. Specialized support groups tend to ‘own’ their area which leads to them becoming a bottleneck.

Let’s examine a LeSS organization…

  • Head of the Product Group—Most LeSS organizations still have managers including a “head of product group.” They support the teams by Go See and help them remove obstacles and improve. LeSS organizations don’t have matrix structures and there are no “dotted-line” managers.
    “Head of Product Group” is called differently in different organization, here we mean the hierarchical manager of all the teams.
  • Feature teams—This is where the development work is done. Each team is cross-functional, self-managing feature team with a Scrum Master. They are permanent units that stay together for the duration of a product (and sometimes longer). Avoid lots of hierarchical layers as much as possible.
  • Product Owner (Team)—This is also commonly called “Product Management.” It can be one person but in a larger LeSS organization the Product Owner might be supported by other product managers.
    An important point in this organizational structure is that the Teams and the Product Owner are peers. This important to keep the power balanced between the roles. The Teams and Product Owner should have a cooperative peer relationship.
    A common alternative structure is when the Product Owner belongs to a different organization. This is OK though it does often require additional effort to ensure the Product Owner has a close relationship with the Teams.
  • Undone department—This department, ideally, does not exist.
    But unfortunately sometimes the teams are not yet able to create a true shippable increment every Sprint. This is reflected by their “Definition of Done” not being equal to “Potentially Shippable.” Undone departments such as test, QA, architecture, or business analysis groups should never exist in the smaller LeSS framework groups as they should be integrated into the teams from the start. On the other hand, we unfortunately frequently still see an operations or production undone department in LeSS adoptions, as they often cross organizational boundaries.