Parallel organizations

Context

There is a rule in the LeSS Huge framework - "LeSS Huge adoptions, including the structural changes, are done with an evolutionary incremental approach".

In the 3rd LeSS book, there are three related guides for LeSS Huge adoption.

• "evolutionary incremental adoption"
• "one requirement area at a time"
• "parallel organizations"

The "evolutionary incremental adoption" guide is an overarching one, which describes two approaches.

1. gradual incremental adoption over the whole product group
2. focused deeper adoption at a part of the product group

The "parallel organizations" guide provides a major technique to support the 2nd approach, while the "one requirement area at a time" guide is an instance of "parallel organizations".

Definition

What is a parallel organization?

"This means you keep your existing organization as it is and gradually build the new organization next to it, starting with a few feature teams or one requirement area."

"A parallel organization is not a pilot, and one consequence is that the line of organizational reporting must be separate from the traditional organization."

This guide was developed from the below experiment.

Try...Transition from component to feature teams gradually (in the 2nd LeSS book)

"Note!--Team Red is not a temporary project group formed only for the purpose of feature-M. We are not suggesting the traditional practice of resource management with resource pools for short-term work groups. Rather, Team Red is a new stable team that will stay together for years; feature-M is but the first of many features they will eventually do."

Therefore, parallel organizations here mean two different structures in reporting line.

Risks

There are a couple of risks or weaknesses associated with the approach of parallel organizations.

1. without common vision

Parallel organization is a change strategy, rather than a pilot to test whether this is the direction we would like to go. Thus, parallel organizations happen after you have established a common vision - eventually the whole organization will move into the new mode.

"Communicate very clearly that eventually everyone will be in the new organization. That's an important message so that people in the old organization do not focus on rivalry."

However, shared vision is not a one-time process, but a continuous process. The extent of the commitment to the new vision would vary among the people in the current organization. This is also why using volunteering is a powerful adoption principle. We provide a chance for people who are more ready to volunteer into the new organization now, while for people who are less ready to temporarily stay in the old organization. However, it is not an option to forever stay in the old organization. The really available option is getting some extra time to learn and digest the new mode so as to get more ready (or eventually decide to leave the organization). This fits the nature of various paces that different people have, thus, shows the respect for people.

2. additional complexity

Parallel organizations do introduce additional complexity. The complexity of making two modes co-exist may be more than the complexity of making the new mode work.

At the code level, the individual code ownership simply prevents the adoption of feature teams, while the adoption of feature teams simply breaks the individual code ownership. Continuous integration is not continuous integration any more when only part of the organization is practicing it. "Don't let the parallel organization branch the codebase as that will lead to merge-hell. They are separate organizations but work on the same product and the same codebase."

As there are two different organizations, each involves its own organizational design. In light of Star mode, they may have different strategies, structures, processes, rewards and people practices. These add complexity on the management too.

Alternatives

LeSS or LeSS Huge seem binary, while in fact it is a continuum. We may split LeSS Huge into small LeSS Huge and big LeSS Huge to explore the alternatives. Let's get back to the root of LeSS - experiments, as we shall experiment to explore.

1. Small LeSS Huge

Small LeSS Huge is perhaps between 50 and 200 people.

Try...Feature teams - transition (in the 1st LeSS book)
Reorganize into broad cross-component feature teams

This is an "all-at-once" approach. In the LeSS framework, it becomes a rule. While in the LeSS Huge framework, it is recommended to take an evolutionary incremental approach. However, it doesn't mean that you could not experiment it in the context of LeSS Huge, especially when it is a small LeSS Huge case. It avoids parallel organizations, thus, reduces the associated complexity. Meanwhile, it increases the risk of either superficial adoption (the law of raspberry jam - the wider it is spread, the thinner it gets) or overwhelming problems from everywhere.

Try...Feature teams from single-specialized to multi-specialized
Try...Feature teams from being led by Team Leader (TL) to self-organization without TL

I worked with an organization of ~150 people to adopt LeSS. When presenting them with parallel organizations, they disliked it. They concerned that it would be confusing to maintain two different reporting structures. They used to be structured in functional and component teams. They wanted to form cross-functional feature teams, and change the reporting structure all at once.

However, considering that the challenges could be overwhelming, we thought about limiting the change scope elsewhere. We still had product backlog per feature team, still had Team Leaders (no ScrumMasters) in some teams, and etc. Over time, we reduce the number of product backlogs and nurture the self-organization. Along the way, we don't have parallel organizations in the sense that there are two different reporting structures. Nevertheless, this is still an evolutionary incremental approach.

2. Big LeSS Huge

Big LeSS Huge is perhaps above 200 people.

Try...Feature teams - transition (in the 1st LeSS book)
Gradually expand teams' responsibility

This experiment could mean to merge small-component teams into big-component teams. Suppose that we have four component teams - A, B, C and D, instead of creating full feature teams by mixing all components, we take smaller step to first create bigger-component teams - A/B and C/D, each having two teams sharing one bigger-component backlog.

This experiment could also mean to expand the Definition of Done (DoD) over time. The expansion of DoD and product definition often goes hand in hand. This experiment was actually developed into the guide of feature team adoption map.

Try...Reduce #component backlogs and #functional backlogs over time

The essence of adopting cross-functional feature team could be boiled down to the reduction of #functional backlogs and #component backlogs. Please refer to "number of backlogs and multi-learning" for more details.

While we merge small-component teams into big-component teams, we reduce the number of component backlogs. Besides that, we merge fine-grained functional teams into course-grained functional teams. For example, UX, UI and BA teams could be merged into a product design team; various specialized testing teams could be merged into a generic testing team. While doing this, we reduce the number of functional backlogs.

Try...Feature areas having teams with various extents of functional, component and customer domain specialization

To avoid parallel organizations, try to establish feature areas all at once at the highest organizational level. Feature areas consist of multiple teams, and can complete customer features from end to end. However, team structures within the areas vary. In some areas, those are still functional and component teams. In other areas, those are feature teams, but single-specialized, thus having their own product backlogs. In still other areas, those are multi-specialized feature teams sharing one product backlog. In that case, those areas are already requirement areas, though static. The adaptiveness would increase further by making those requirement areas dynamic.

...

We continue to experiment towards perfection.