Team-first or Organization-first

When adopting Scrum, we usually take the team-first approach by looking at which teams to pilot Scrum. However, the problem with this approach is that quite often the existing teams are not properly designed for Scrum. So, the alternative approach is organization-first by looking at which part of the organization to pilot Scrum or LeSS when multiple teams are involved for the same product.

Scrum adoption without organization design

Many Scrum adoptions start with giving trainings and finding a project team to pilot. This approach often overlooks the need for proper organization design, which includes:

• all work comes from product backlog
• one product owner deciding overall priority for all the work
• cross-functional team with common goal and shared responsibility
• SM as coach not having delivery responsibility

Instead, they do poor organization design, which looks vaguely similar but deeply different.

• only feature work is in product backlog
• PO only responsible for feature, manager still responsible for maintenance and other work
• cross-functional team members only work in their own speciality, do not cross-learn, partially work on this project, etc.
• SM (renamed from project manager or team leader) still responsible for delivery

We often receive limited benefits, if any, from this approach. Even coaching does not seem matter too much. This is best illustrated by Richard Hackman's work. In his classical book <<Leading Teams>>, the below picture showing the relations among team performance, team design and coaching is insightful. In short, well-designed structure and effective coaching together create best effects, but organization design is first-order factor.

Scrum holds very different leadership approach, but training does not seem help too much either. The HBR article "Why leadership training fails" illustrates this clearly. "If the system does not change, it will set people up to fail."

LeSS adoption with organization design

LeSS has strong focus on organization design, as it is the first-order factor to influence for change. LeSS is further defined in two frameworks - LeSS (2-"8" teams, roughly 10-50 people) and LeSS Huge ("8"+ teams, roughly 50-1000+ people).

Look at LeSS rule:

"For the product group, establish the complete LeSS structure 'at the start'; this is vital for a LeSS adoption."

Continuous improvement is more effective once proper organization structure is in place. However, organization structure itself is not sufficient, coaching is necessary. The challenge after proper organization design is still big, when you consider backlog management, development practices cross-team coordination, etc. This is the reason why LeSS Huge takes a different approach.

Look at LeSS Huge rule:

"LeSS Huge adoptions, including the structural changes, are done with an evolutionary incremental approach."

LeSS takes all-at-once approach, while LeSS Huge takes incremental approach. Requirement Area is the technique that enables incremental approach in LeSS Huge. The key is to find a relatively independent area, within which you can do LeSS adoption - complete organization redesign.

My consulting approach

During the past few years, unless there is only one team of less than 10 people for the whole product, I try to find a group of 20-40 people, do proper organization design in creating well-designed teams, and coach Sprint practices from there.

For external consultant, the approach of doing proper organization design first makes sure that further coaching on Sprint practices will be focused and more likely effective. If we falter in proper organization design, we also know that the change is unlikely going very far. Then, the decision on whether to engage is better informed.

However, for internal champion, this means that you need to apply the art of the possible before reaching to the point where the experiment can be done on the proper level of organization. Unless your organization is very simple, this usually means certain product area and involving a few functional/component teams for which you need to redesign.