June 2017 Archives

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.

Team design vs Coaching.jpg

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.

Different context, same resource thinking

Almost a year ago, I wrote about "Seeing the underlying resource thinking". It was in the context of large-scale product development. In my recent training and coaching, I face more holistic product development including not only software, but also hardware, mechanical, supplier chain, etc. It is a different context, but we see the same resource thinking underneath their common practices.

In my view, resource thinking can be illustrated by the below assumptions and practices.

  1. People can only work on their speciality, i.e. they cannot learn or learning means inefficiency.
  2. Due to point 1, it is common to have partial allocation, in order to fully utilize people's specialty.
  3. Due to point 1, and work is dynamic, it is common to have temporary group, assuming that people are interchangeable parts, thus, no cost incurred by moving them around.

Putting these into the context of holistic product development, it adds more challenges than software product development.

  • There are more specialities involved. It could even be 20+ functions involved for holistic product development. Many of them only have minor allocation as the need for their speciality is limited.
  • Cross-learning is more difficult. Think about it is relatively easier for back-end developer to learn front-end development, while it is more difficult for mechanical engineer to learn software development.
  • Temporary group is even more loosely organized, it is often not clear who are in the group.

Scrum provides an alternative approach based on different assumptions than resource thinking.

  1. People can learn. The more learning, the better they learn. And the learning helps efficiency.
  2. Due to point 1, every team member is fully dedicated. When there is mismatch between work and skill, people cross-learn and expand skills.
  3. Due to point 1, and believe that team stability is necessary for team's high performance. Stable team is created and it continuously improves.

Considering the context of holistic product development, it is indeed more challenging to apply Scrum literally. We need to think about the principles and apply the art of the possible here. One possibility could be:

  • Identify core specialities necessary for the holistic product development, build a core team around those specialities by having members fully dedicated. Treat the rest as external dependency and support.
  • Keep the core team stable, so that they could continuously improve as a team.
  • Create cross-learning among core team members, at least enable some members to develop themselves into generalizing specialists. I have indeed seen people who could work across hardware, software and mechanical engineering, even though it is rare. For many, it is possible to expand a bit, but that would already be helpful for the flexibility.

Once you learn to see resource thinking, start to apply different sets of assumptions and principles. With the art of the possible, you will find a way forward in whatever context.

About this Archive

This page is an archive of entries from June 2017 listed from newest to oldest.

March 2017 is the previous archive.

October 2017 is the next archive.

Find recent content on the main index or look in the archives to find all content.