The Odd-e Blog

 
The Authors
 

Seeing the system dynamic: coordination role vs. self-organization

Introducing coordination roles is a very common choice made by many organizations to deal with coordination complexity. I realized during the recent course that this quick fix is seen by many as the only solution while it is hard for many to even image that there is another fundamental solution. Therefore, I decide to write down this dynamic to help see it.

In scaling environment where multiple teams need to coordinate with each other, it is so tempting to introduce coordination roles for them. Those roles are often called project/feature coordinators/managers. When I asked why teams could not directly work together, that possibility seemed so far  from reach. I know that the burden has been shifted.

The below is the CLD (Causal Loop Diagram) for this dynamic. 

Organize time - coordination role vs self-organization.png

This is a typical "Shifting the burden" system archetype.

There is a related dynamic of solving this complexity by coordination vs. by organization design, which was illustrated in another article. In this article, we assume that the complexity is still manageable through coordination.

When we face coordination complexity, it is easy to introduce a role and give him/her the responsibility to coordinate that complexity away. When he/she is successful, the complexity decreases. This forms B1-loop.

The more fundamental solution is to build the capability in self-organization so that teams can work together and coordinate directly to reduce the complexity. The capability building will take time thus a delay is involved. This forms B2-loop.

The more interesting characteristic in this dynamic is the additive R-loop. The success of coordination roles increases the organizational appreciation on them, and then, the dependence on them. This dependence shifts the focus away from building capability in self-organization, which makes it more relying on coordination roles.

You see the additive loop in play when you hear people say that there is no way for teams to directly coordinate with each other as their capability is not sufficient.

LeSS vs. SAFe

It is interesting to compare LeSS and SAFe on this regard.

  • SAFe defines PI planning (aka big room planning), where teams identify and coordinate dependencies by themselves. That is in line with the principle of self-organization.
  • LeSS defines joint Sprint planning, where teams coordinate directly with each other. That is in line with the principle of self-organization too.
  • SAFe defines SoS (Scrum of Scrums), where SMs participate to coordinate cross-team issues. This is the solution of having coordination roles. In fact, it is even worse, as it alters SM role. SM is never a coordination role, but a facilitation and coaching role.
  • LeSS defines many coordination mechanisms, with the preference over decentralized ones. Even for SoS, that is not participated by SMs, but team representatives.

I feel sad that SAFe takes the spirit of self-organization in planning, then moved to coordination roles afterwards.

I feel more sad that people from different teams could not Just Talk without involving coordinators/managers.

 

Seeing the system dynamic: feature team vs. feature group

Feature group is a temporary group of individuals to deliver specific feature. It is very common in traditional matrix organization, and also called feature project. Meanwhile, feature team is a stable team who takes shared responsibility to deliver feature after feature. The below table from feature team primer summarizes the main differences between them.

feature team

feature group/project

stable team that stays together for years and works on many features

temporary group of people created for one feature or project

shared team responsibility for all the work

individual responsibility for 'their' part based on specialization

self-managing team

controlled by a project manager

results in a simple single-line organization (no matrix!)

results in a matrix organization with resource pools

team members are dedicated - 100% allocated - to the team

members are part-time on many projects because of specialization

Why do organizations make different choices? The below CLD illustrates the system dynamic around it.

Organize people - feature team vs feature group.png

Individual efficiency

The main motivation behind looking for the "right" individual to do the work is to create the skill match for individual efficiency. This is reflected by B1-loop, which reads like this:

  • the lower individual efficiency
  • the more consideration of individual skill in dividing work
  • the smaller skill gap
  • the higher individual efficiency

However, it creates unintended consequences at individual level shown as R1-loop and R2-loop. Together with B1-loop, it forms typical "fixes that backfire" system archetype.

R1-loop shows the problem with multi-tasking, which reads like this:

  • the lower efficiency
  • the more consideration of individual skill in dividing work
  • the more multi-tasking
  • the lower efficiency

Because seeking for perfect work and skill match creates the situation where people are multi-tasking for different feature groups, while multi-tasking is a source of low efficiency, the fix backfires.

R2-loop shows the problem with reduced learning, which reads like this:

  • the lower efficiency
  • the more consideration of individual skill in dividing work
  • the smaller skill gap
  • the less learning
  • the lower efficiency (with delay)

As people always work on familiar tasks, the learning is reduced, while learning helps increase the efficiency in the long term, the fix backfires.

Team performance

Traditional thinking assumes that team performance is solely or at least mainly decided by individual efficiency, which forms B2-loop by extending B1-loop. It reads like this:

  • the worse team performance
  • the more consideration of individual skill in dividing work
  • the smaller skill gap
  • the higher individual efficiency
  • the better team performance

Again we see "fixes that backfire" system archetype, this time at team level. It is formed by B2-loop and R3/R4-loop.

R3-loop shows the problem with low interdependency, which reads like this:

  • the worse team performance
  • the more consideration of individual skill in dividing work
  • the smaller skill gap
  • the less need for help
  • the weaker collaboration
  • the worse team performance

The task interdependency enables team collaboration. Once team members perceive little need to help each other, the motivation to collaborate is low. While the team performance is affected much by the level of collaboration, think about the time of integration. The fix backfires.

R4-loop shows the problem with temporary group, which reads like this:

  • the worse team performance
  • the more consideration of individual skill in dividing work
  • the less stable team
  • the weaker collaboration
  • the worse team performance

Because the work is dynamic, matching work with individual skill inevitably makes team unstable. While it takes time and effort to get a team into performing stage, any member change will bring the team back to storming stage (referring to Bruce Tuckman's model). The fix backfires.

Moreover, we see another "fixes that backfire" system archetype at team level, which is formed by B3-loop and R5-loop.

In traditional thinking, shared responsibility means no responsibility. Thus, it is believed that defining clear individual responsibility helps team performance, which is shown as B3-loop. It reads like this:

  • the worse team performance
  • the more consideration of individual skill in dividing work
  • the less shared responsibility
  • the better team performance

R5-loop shows the problem with lacking common goal, which reads like this:

  • the worse team performance
  • the more consideration of individual skill in dividing work
  • the less shared responsibility
  • the less aligned goal for different members
  • the worse team performance

Members in the feature group reporting to different managers make it even more difficult in having real common goal, while it is essential for team performance. The fix backfires.

Leverage

There is full of resource thinking in the above system dynamics, such as ignoring learning capability, aiming for efficiency and utilization, moving people around, etc. The old mental model plays the essential role in keeping the status quo. Seeing it is a powerful leverage in itself.

Considering to break vicious R-loop and/or introduce B-loop to balance, the below list offers some ideas about where to leverage:

  • keep stable team (through organization design)
  • ensure dedication (through organization design)
  • define shared responsibility (through organization design)
  • create task interdependency (through organization design)
  • support learning (through coaching)
  • align common goal (through coaching)
  • increase level of collaboration (through coaching)

 

Seeing the system dynamic: 1 vs. n product backlogs

In a product organization with multiple teams, it raises a choice - whether to have one or many product backlogs. They usually start with one product backlog, either because they start with one pilot team, or because their product starts small from one team. Later, some organizations choose to have many product backlogs in response to more teams, while other organizations choose to keep one product backlog. When having many product backlogs, usually separate PO will be responsible for each backlog.

The below CLD illustrates the system dynamic around this topic.

Organize work - 1 vs n backlog - 1.png

Drive for one product backlog

As this is one product, it should be quite natural to think of one product backlog. The R1-loop reads like this.

  • the fewer product backlogs
  • the more transparency
  • the better product wholeness
  • the fewer product backlogs

Potentially this could be a virtuous cycle, which eventually leads to one product backlog.

Why having many product backlogs?

Then, why do some organizations choose to have many product backlogs? There are three main balancing loops in play, which are B1-loop, B3-loop and B5-loop. Together with R1-loop, it creates "limits to growth" system archetype.

Organize work - 1 vs n backlog - 2.png

B1-loop reads like this:

  • the fewer product backlogs
  • the bigger skill gap
  • the lower development efficiency
  • the more anxious team gets
  • the more product backlogs

B1-loop illustrates the limitation from team specialization. In order to make use of team's specialization for efficiency, product backlog essentially becomes team backlog to match their skills. This dynamic is similar as the one involved in having generic vs. specialized teams. However, there is fundamental solution, and we shall elaborate on it later.

B3-loop reads like this:

  • the fewer product backlogs
  • the more stories in each backlog
  • the more effort by PO on clarification (assumption: PO does requirement clarification)
  • the more anxious PO gets
  • the more product backlogs

B3-loop illustrates the limitation from requirement clarification. There is common misunderstanding about PO clarifying requirements for teams. If PO does all of that, it becomes a limiting factor for having one product backlog. However, there is fundamental solution, and we shall elaborate on it later.

B5-loop reads like this:

  • the fewer product backlogs
  • the more coupled among teams
  • the less efficient in discovery and decision making
  • the more anxious PO gets
  • the more product backlogs

B5-loop illustrates the limitation from discovery and decision making. The assumption here is that every team has its own PO, and it is more efficient when PO could make decisions on his own. However, there is fundamental solution, and we shall elaborate on it later.

These are main restraining forces for having one product backlog. They limit R1-loop and damage the product wholeness. The leverage lies at weakening those forces by looking for fundamental solutions.

Look for fundamental solutions

Corresponding to B1-loop, B3-loop and B5-loop, there are alternative fundamental solutions shown as B2-loop, B4-loop and B6-loop, respectively. However, those solutions are with delay, thus, long-term. The short-term solution (i.e. having many product backlogs) shifts the focus on long-term solutions. That is essentially what "Shifting the burden" system archetype is about.

1. Team specialization

Organize work - 1 vs n backlog - 3.png

The fundamental solution is shown as B2-loop, which reads like this:

  • the lower development efficiency
  • the more anxious team gets
  • the more learning
  • the broader team skill gets (with delay)
  • the smaller skill gap
  • the higher development efficiency

Instead of having many product backlogs to reduce skill gap for development efficiency, we focus on learning and expanding team skill breadth, eventually leading to higher development efficiency.

R2-loop is the addictive loop in "Shifting the burden", which reads like this:

  • the more product backlogs
  • the less perceived need for learning by team
  • the less learning
  • the narrower team skill gets (with delay)
  • the bigger skill gap
  • the lower development efficiency
  • the more anxious team gets
  • the more product backlogs

When having many product backlogs sort of fixes the development efficiency, we tend to focus less on learning and expanding team skill breadth, and become more addictive to having many product backlogs.

2. Requirement clarification

Organize work - 1 vs n backlog - 4.png

The fundamental solution is shown as B4-loop, which reads like this:

  • the more effort by PO on clarification
  • the more anxious PO gets
  • the more involved team gets in requirement clarification
  • the less effort by PO on clarification (with delay)

Instead of having many product backlogs to reduce PO effort, we focus on getting team involved in requirement clarification, eventually leading to reduced workload from PO side. The delay is caused by team having to learn how to work with users and the domain in order to do the proper requirement clarification.

R3-loop is the addictive loop in "Shifting the burden", which reads like this:

  • the more product backlogs
  • the fewer stories in each backlog
  • the less perceived need for help by PO
  • the less involved team gets in requirement clarification
  • the more effort by PO on clarification (with delay)
  • the more anxious PO gets
  • the more product backlogs

When having many product backlogs sort of fixes PO effort problem, we tend to focus less on getting team involved in requirement clarification, and become more addictive to having many product backlogs.

3. Discovery and decision making

Organize work - 1 vs n backlog - 5.png

The fundamental solution is shown as B6-loop, which reads like this:

  • the less efficient in discovery and decision making
  • the more anxious PO gets
  • the more alignment across teams
  • the more efficient in discovery and decision making (with delay)

Instead of having many product backlogs to reduce team coupling for discovery efficiency, we focus on getting teams aligned and increasing the capability of group decision making, eventually leading to more efficient discovery with group of teams and POs. The delay is due to the time and effort necessary to create cross-team alignment and build group collaboration capability.

R4-loop is the addictive loop in "Shifting the burden", which reads like this:

  • the more product backlogs
  • the less coupled among teams
  • the less perceived need for alignment across teams
  • the less alignment across teams
  • the less efficient in discovery and decision making (with delay)
  • the more anxious PO gets
  • the more product backlogs

When having many product backlogs sort of fixes discovery efficiency problem, we tend to focus less on creating alignment and building group collaboration capability, and become more addictive to having many product backlogs.

Summary

As we have one product, it is desirable to have one product backlog. We look at what prevents us from doing that. Those are barriers we need to overcome. There are three common reasons why having many product backlogs - team specialization, requirement clarification, discovery and decision making. We look at fundamental solutions for those, and how to avoid the traps associated with the quick fix, i.e. having many product backlogs.

 

Seeing the system dynamic: component team vs. feature team

This is one article in a series that tries to see system dynamics behind various choices in organizing work, people and time.

Among many choices in organizing people, feature team vs. component team is an important one.

The below CLD (Causal Loop Diagram) illustrates the system dynamic around it.

Organize people - component team and feature team.png

The variable "product scope"

The difference between feature team and component team can be boiled down to the difference in product scope. Read the article "is team in Scrum feature team?" to understand that feature team is a continuum related to the product definition. Thus, I introduce the variable "Product scope" to illustrate the continuum.

  • "Product scope" bigger => more on feature team
  • "Product scope" smaller => more on component team

Driving forces for feature team

1. Speed for value delivery

The related causal links read like this:

  • the bigger product scope (adopting feature team)
  • the less external dependency
  • the faster speed
  • the more value delivery

Once all dependencies are within the team, it is always in sync so that the value can be delivered in the same sprint. This is the most important benefit in adopting feature team.

2. Speed for learning

Extending the above causal links creates the R1-loop, which reads like this:

  • the bigger product scope (adopting feature team)
  • the less external dependency
  • the faster speed (the faster feedback)
  • the more learning
  • the higher efficiency (with delay)
  • the bigger product scope (expanding feature team)

This is a virtuous cycle leading to feature team in broader product. However, as there is delay between learning and efficiency, the effect may be invisible in the short term.

3. Skill gap for learning

The related R2-loop reads like this:

  • the bigger product scope (adopting feature team)
  • the bigger skill gap
  • the more learning
  • the higher efficiency (with delay)
  • the bigger product scope (expanding feature team)

This is also a virtuous cycle leading to feature team in broader product. However, the skill gap also causes less efficiency in the short term, which creates restraining force against feature team. See more details in B1-loop.

4. Self-organization capability

The related R3-loop reads like this:

  • the bigger product scope (adopting feature team)
  • the less external dependency
  • the less coordination complexity
  • the fewer roles for coordination
  • the more capable team becomes in self-organization
  • the bigger product scope (expanding feature team)

This is also a virtuous cycle leading to feature team in broader product. The coordination roles here refer to project managers or feature coordinators responsible for coordinating work across teams.

Restraining forces against feature team

1. Efficiency

The related B1-loop reads like this:

  • the bigger product scope (adopting feature team)
  • the bigger skill gap
  • the lower efficiency
  • the smaller product scope (shrinking feature team)

Even though the learning triggered by skill gap can lead to higher efficiency in the long term (R2-loop), the challenge in the short term is real. In order to shift dominance to R2-loop, we need to think of ways to reduce efficiency loss and raise learning effectiveness. We shall introduce right amount of skill gap to support learning while not overly losing efficiency. It is necessary to gradually expand the scope of feature team. Meanwhile, we shall focus on how to speed up the learning.

Traditionally, one way to reduce skill gap for efficiency is to consider skill in prioritization. Sometimes, we select low-value items just because they match our skill. However, the value delivery is decided by both the value in those items and how efficient you deliver them.

  • the more consideration on skill match in prioritization
  • the less skill gap
  • the higher efficiency
  • the more value delivery

Skill consideration in prioritization can help value delivery.

  • the more consideration on skill match in prioritization
  • the less value in items
  • the less value delivery

Skill consideration in prioritization can also damage value delivery.

In a way, it is an economic choice, but doing so misses the possibility to remove the constraint.

2. Quality

The related B2-loop reads like this:

  • the bigger product scope (adopting feature team)
  • the bigger skill gap
  • the lower quality
  • the smaller product scope (shrinking feature team)

Another challenge is about quality. When skill gap is too big, the quality will suffer. One argument for component team is that it leads to better quality, as people are more specialized. Whether this holds true deserves further examination, because the narrow focus on component also limits learning, which is essential for good quality.

Lowering efficiency and quality are main concerns in adopting feature team. Therefore, the leverages lie at how to support learning and ensure quality. The following practices would help.

  • Continuous Integration
  • Collective Code Ownership
  • Component Guardian
  • Community of Practices
  • Slack

Consider those while adopting feature team, and learn more details from LeSS website and books.

 

Is team in Scrum feature team?

Feature team gains popularity, but the difference between feature team and cross-functional team is still confusing to many people. Surprisingly, I failed to find good reference to clarify it, thus I decide to write one.

1. Does Scrum require feature team?

If you read Scrum Guide, the below defines the (development) team.

"The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of 'Done' product at the end of each Sprint."

And it is clear that team is cross-functional.

"Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment."

However, it is not clearly stated whether it is feature team (vs. component team). This creates lots of confusion about whether cross-functional team implies feature team, and whether they are the same thing.

2. Does SAFe require feature team?

In my previous articles and presentations, I mentioned that SAFe did NOT require feature team, though it might still recommend it, it is not part of essential SAFe. One friend in the community argued with me that SAFe also requires feature team. His view was, as Scrum is used at team level in SAFe, and Scrum requires feature team, therefore, SAFe requires feature team. His argument has relevance to the same confusion - does Scrum require feature team?

If you read SAFe, the below defines the (Agile) team.

"An Agile Team consists of a small group of dedicated individuals, who together have the skills necessary to define (elaborate and design their component/feature), build (implement their component/feature), test (run the test cases and validate the component/feature) increments of value in a short timebox."

It is clear that team is cross-functional. It is somewhat clear that component team and feature team are both possible.

3. Does LeSS require feature team?

In LeSS, the below rule makes it clear that LeSS requires feature team.

"The majority of the teams are customer-focused feature teams."

The root of the confusion

Back to Scrum, it uses "Increment of 'Done' product" when defining the team. The root of the confusion is from being unclear about what the product is. In SAFe, it uses "increments of value". It does not help much to clear the confusion as it is not clear what value is either.

The question of "what the product is" sounds trivial but deserves deeper thinking. LeSS states, "When starting a LeSS Adoption, one of the first things to clarify is what your product actually is."

The definition of feature is dependent on the definition of product. The product bounds the feature, and the feature is end-to-end within the product.

  • If you define your component as product, the requirement on the component becomes feature.
  • If you define your platform as product, the requirement on the platform becomes feature.
  • If you define your "product" as product, the requirement on the "product" becomes feature.
  • If you define your solution as product, the requirement on the solution becomes feature.

The feature-ness is a continuum!

This is nicely illustrated by feature team adoption map in LeSS. In my view, the more precise name should be cross-functional feature team adoption map, as there are two dimensions - cross-functionality and feature-ness.

Does it mean that the whole distinction of component team and feature team is meaningless? Not really. It means that the distinction is contained by what the product is.

In LeSS, there is a rule regarding what the product is.

"The definition of product should be as broad and end-user/customer centric as is practical. Over time, the definition of product might expand. Broader definitions are preferred."

Clarify what the product is, and form feature team to deliver Done product increment.

 

Seeing the underlying resource thinking

Creating stable teams and having teams work from one priority are two critical ideas in large-scale product development. This means when we discover some work, we put it into the overall backlog with appropriate priority; then, all teams share same priority, and any team may do the work.


However, two common counter ideas often pop up.


1. Change work priority to match team skill


Only the team with matched skill will be considered for the work, while other teams will not, even they are available. What will other teams do? Because they should not be idle, they do work that has lower priority but matches their skill.


2. Create project team to match individual skill


When the work requires skills across groups, people from those groups are pulled into a short-term team only for this work, so that individuals can do the part matching their skills. This is the traditional project team approach.


I felt a bit frustrated when I heard those ideas again during my recent consulting. It seems so deeply held, thus I decide to make a deep analysis resulting in the below CLD (Causal-Loop Diagram).


Resource thinking.jpg


The two counter ideas, which are in fact solutions on how to organize people for work, are illustrated by two B-loops (B1 and B2).


The B1-loop reads like this:


      the more delivery pressure -> 

      the more consideration for skill in prioritization ->

      the more match between work and skill ->

      the more efficiency ->

      the more value delivery ->

      the less delivery pressure


The B2-loop reads like this:


      the more delivery pressure -> 

      the more consideration for skill in forming team -> 

      the more match between work and skill -> 

      the more efficiency -> 

      the more value delivery -> 

      the less delivery pressure


They both try to create the match between work and skill, thus optimize for efficiency.


However, they also create intended/unintended consequences illustrated by other loops in the diagram.


1. Less value delivery


This is illustrated by the R1-loop, which reads like this:


      the more delivery pressure -> 

      the more consideration for skill in prioritization -> 

      the less value delivery (as it constrains prioritizing high value items) -> 

      the more delivery pressure


As the value delivery is affected by both value in items and the number of delivered items (efficiency), R1 and B1 together create an economic tradeoff. Depending on which loop is dominant, it may deliver less value, even though the efficiency goes up.


2. Lower team performance


This is illustrated by the R2-loop, which reads like this:


      the more delivery pressure -> 

      the more consideration for skill in forming team -> 

      the less stable the team is (as the work is dynamic) -> 

      the less efficiency at the team level (as it takes stability to perform at the team level) -> 

      the less value delivery -> 

      the more delivery pressure


R2 shows the fix (create project team to match individual skill) that backfires, as those teams exist only in short term while the stability is essential for team performance.


3. Less learning


This is illustrated by the R3-loop, which reads like this:


      the more delivery pressure -> 

      the more consideration for skill either in prioritization, or in forming team (actually two loops) -> 

      the more match between work and skill ->

      the less learning ->

      the less efficiency (in the long term) ->

      the less value delivery ->

      the more delivery pressure


R3 shows the fixes (change work priority and create project team) that backfire, as they both create more match between work and skill, which reduces learning!


What we are seeing in the diagram is really the underlying resource thinking.


  • Skill utilization is more important than value delivery
  • Team is no more than sum of individuals
  • People are fixed in one skill and they cannot learn

As learning is essential in any product development, the mismatch between work and skill is not something nice to have, but must have. By creating stable teams and having teams work from one priority will you create the mismatch to promote learning!


 

Build a Real Management Team

Real development team is already rare, let alone real management team. When talking about real team, I mean that the group has common goal and takes shared responsibility. Usually, management team is not a real team, but a working group. This is indicated by every member having clear individual responsibility. Even though it is claimed that they have common goal, it is mostly the leader who is accountable for it, and other members are mostly responsible for their own parts. This is the traditional organization hierarchy.


As the hierarchy is defined by reporting line, let's look at various settings when we create cross-functional feature team in adopting Scrum.


1. from multiple managers to one manager


As the traditional organization is often based on functions and components. When we move from single functional and component team structure to cross-functional and feature team structure, if original reporting structure remains, members in the same team will report to different managers. Those managers are still responsible for their own functions and components. Even though they are members in management team, they do not take shared responsibility. This is not desirable for team, as the more managers, the more difficult it becomes in alignment. 


Reporting line - functional.png


Therefore, the common advice is to change the reporting line and make the whole team report to same manager. Then, those managers become cross-functional managers. However, this does not make them take shared responsibility in management team, as usually they are still responsible for their own teams.


Reporting line - cross-functional.png


2. from one manager to multiple managers


Recently, in my LeSS course, a few participants from same product organization shared that the members in their teams report to multiple managers, but NOT managers for different functions and components. Instead, it was a bit like everybody randomly picking up a manager. It sounded weird at first, then, it revealed an interesting purpose of doing that. They want to build a real management team!


Reporting line - random.png

The rationale is, when any team is not owned by one manager, it would avoid the situation of any manager only responsible for their own teams. Instead, multiple mangers will collectively  ensure the success of all teams. In this setting, any misalignment among managers would become serious impediment towards well-working team. What impressed me was that they made informed choice, with the attitude of experimentation.


This reminded me of my NSN (Nokia Siemens Networks) experience. When I led a department with 100+ people, we had 4 R&D managers, together with me we formed a management team. We put deliberate efforts in building a real team - taking shared responsibility for the whole department goals.


We tried:


  • Managers acted as ScrumMaster for teams who did not directly report to them. See Manager as ScrumMaster paper.
  • Created department initiatives to foster collaboration among R&D managers, especially on removing organizational impediments, continuous improvement, and community of practices.
  • Not cascade down department objectives to next level for R&D groups, but kept it at department level.
  • Instead of me giving the feedback to every manager as part of performance appraisal, we had management team feedback session, everybody giving and receiving feedback in the open.


We did not try having members in one team report to different managers by random. What an interesting experiment, ever though its effect remains to be checked.


I applaud for any attempt in building the real management team, as it is hard, but a lofty goal to seek.

 

Decouple Line Organization from Requirement Area

After almost 10 years, I got chance again to work on a LeSS Huge adoption. Facing different challenges and reflecting on my experience 10 years ago, I am proposing an experiment here to decouple line organization from requirement area.


NSN experience


In 2007, I experienced an organizational transformation in NSN (Nokia Siemens Networks) to adopt LeSS, at which time the name "LeSS" had not yet existed. We had transformed the organization into a LeSS Huge setting with a few requirement areas, in each area there was APO (Area Product Owner) and Area manager. Area manager was the line manager for the area. We used the same name for requirement area and line organization, for example, the area I worked for was Traffic & Transport, both as requirement area and line organization. So, requirement area and line organization are coupled.


Even though the workload in one requirement area is more stable than one feature, if we follow priority based on customer value, it is inevitable that the workload varies as time goes. So, today you need 5 teams working on this requirement area, tomorrow you need 6 teams. I am exaggerating, this would not be "today/this sprint" vs. "tomorrow/next sprint", but more like "this quarter/this year" vs. "next quarter/next year". Anyway, this happens. When it happens, LeSS recommends to move team, rather than individuals, to other requirement area. When requirement area and line organization are coupled, it means that the team would also change the line organization. As you can image, line change is never easy. Everybody may agree that this makes sense and support, the necessary justification and convincing others carries big overhead. Even today when I reflected back, I could still feel the very pain. Yes, the silo among requirement areas was clearly there and the coupling with line organization made it worse. Interestingly, the developed silo was also one of the reasons why we chose to couple line organization with requirement area, because that way, line organization would have more product ownership, not for the whole product, but for the requirement area.


Although it was painful experience to move teams to different requirement area, it did not happen often, as the workload seemed stable in requirement area. In retrospect, i suspect that the prioritization decision may consciously or unconsciously take the capacity of requirement areas into account.


New challenge


Recently, I encounter a different challenge. In the context of my LeSS coaching client, their workload between two requirement areas varies release by release. Say, there are 5 teams in each requirement area. In release 1, based on priority, 60% of work is from requirement area A, and 40% of work is from requirement area B. That translates into 6 teams for requirement area A and 4 teams for requirement area B. However in release 2, only 40% of work is from requirement area A, while 60% of work is from requirement area B. If we have requirement area and line organization coupled, we basically have two options. First, we do not follow the priority strictly and take the work considering the capacity in each requirement area. Second, we move teams to different  requirement areas release by release, as line organization is coupled, we change their line organization as well. As their release cycle is 3-4 months, it would be hectic to make so frequent line change.


New experiment


In fact, we have the third opinion, which is to decouple line organization from requirement area. Once it is decoupled, we may move teams across requirement areas but not change their line organization. Let's illustrate this with the below diagram (RA = Requirement Area).


Decouple line organation from requierment area.jpg


2 line organizations (A and B), each having 5 teams

2 requirement areas (RA1 and RA2), with varying number of teams


Release 1, 4 teams for RA1 and 6 teams for RA2

Release 2, 6 teams for RA1 and 4 teams for RA2


The name for requirement areas is often associated with product domains (customer domains, rather than architecture domains). Hotel, Flight, etc. would be suitable names for requirement areas in Ctrip type of product, assuming that each is big enough to justify as its own area. However, we name line organization without referring to product domains. It could simply be product line group A, B and etc.


In LeSS Huge, one rule says that each team specializes in one RA. In this case, we can't let A5 and B5 specialize in RA1 and RA2, respectively. Instead, we would like them to be able to work for both RA1 and RA2. Would that cause problem? Let's first understand the rationale behind the rule. It is usually difficult for any team not to specialize in any area, as the whole product in LeSS Huge is too complex for any team. This holds true by and large. However, there are a couple of subtle differences here.


  1. We are talking about minority of teams, for most teams (A1-4 and B1-4), they still specialize in one requirement area. It is likely to enable small number of teams who can specialize in more than one requirement area.
  2. Team A5 and B5 may not specialize in RA1 and RA2 completely, but to some extent, e.g. some sub-areas in both RA1 and RA2. The key is to have the flexibility in addressing the workload variation in requirement areas across different releases.

Another potential downside for the decoupling is that line organization would not develop strong product ownership. While this is true for requirement area, too strong ownership for one  requirement area may lead to silos within one product. Thus, the decoupling also has the potential in reducing silos if we can make any line organization care more about the whole product.


Conclusion


Regardless of what choice you make - either coupling or decoupling, I suggest you to understand deeply those forces in the dynamic, thus, make informed choice.


 

Create Discomfort for Continuous Improvement

How often do you feel the discomfort? If it is everyday, you burn out; if it is seldom, you probably do not grow much.


Sitting on the plane to visit a client in US, I felt discomfort, because of different culture, different language, and more. I expected this to come when I accepted the job. I intended to create this discomfort so that I would grow.


How could we create discomfort to grow the team?


1. Scrum


You may start from where you are, which is one of Kanban principles. It helps reduce the change resistance. On the other hand, does it create enough discomfort? Recently, one client asked me to give suggestion on whether to adopt Scrum or Kanban. One thing I paid special attention to was if it would create right amount of discomfort. For Scrum, 1/3 of people felt positive and were eager to try, the other 1/3 felt challenging and hesitated, still the other 1/3 were unclear. While for Kanban, most of them felt comfortable. Then, I suggested to go with Scrum, as I saw that the discomfort level trigged by the change was not too high to burn them out, but enough to make them grow and improve.


2. Done


Get stories done by the end of every Sprint creates the drive for improvement. You need both clear Done and Sprint as timebox. If you do not have clear definition of Done, it is easy to get "Done" as you change it to fit whatever gets completed at the end of Sprint. I have also seen that team planned one day between Sprints to accommodate not being able to get done. Scrum works as mirror, providing the transparency and exposing problems for your improvement. Done within timebox is supposed to create discomfort for team's growth.


3. Expand Done


If you can constantly get done by the end of Sprint, you become comfortable again. Don't keep in that state too long, create discomfort again. If there is still gap between your current Done and PSPI, expand your Done. Expect that you get problems in getting Done after it is expanded, which is good, because you create discomfort again. Team grows when they solve problems that prevent them from getting this expanded Done.


4. Shorten Sprint


I find that still many teams like 4-week Sprint, because they can do mini-waterfall while still getting done at the end of Sprint. Again, if you observe that team feels very comfortable, it may not be effective in exposing their problems and creating drive for improvement. In that case, try to shorten the Sprint and assess the discomfort level, would it enable team to stop doing mini-waterfall and seek more effective collaboration ways of developing software?


5. Go faster, create more value, etc.


Next challenge could be going faster, creating more value, etc. Or, create your own High Performance Tree as your team vision to help identify the gap. With gap, you feel discomfort again to continuously improve.


It is a journey, enjoy it!


 

Two Approaches for Solving Dependency

In the recent email exchanges, one topic came up as whether introducing more coordination meetings and roles actually solves dependency problem or just "shifts the burden".


Shifting the burden is one common system archetype, which consists of two balancing loops and one reinforcing loop. For the topic of dependency, I draw the below CLD (Causal Loop Diagram).


Solve Dependency in English.jpg


Two balancing (B) loops


Two balancing loops illustrate two approaches for solving dependency problem. In scaling environment with multiple teams, the dependency across teams often slows down the development, and poses big challenge for Agile at scale. There are a few scaling frameworks, and they address various scaling challenges differently. For this specific challenge, the two approaches (two balancing loops in CLD) actually represent SAFe way and LeSS way of solving dependency problem.


SAFe tries to manage dependencies. One essential activity in SAFe is PI planning, where dependencies are identified and coordination is fostered. SAFe's focus is on PI (Program Increment), consisting of a few Sprints. Where you have component teams, it is still possible to synchronize all relevant parts into the same PI, but it would be impossible to always synchronize those into the same Sprint. So, it helps to certain extent.


LeSS tries to remove dependencies. One key element in LeSS is feature team, which means to design team structure so that the cross-team planning dependencies are avoided. LeSS's focus is on Sprint, same as Scrum, which makes it critical to adopt feature teams. Feature team adoption addresses the root cause of dependency problem, but as it requires organization redesign, it is more disruptive and needs stronger motivation.


One reinforcing (R) loop


This is the addictive loop. Would the adoption of SAFe reduce the chance for deeper organizational change promoted in LeSS? Once SAFe solves the dependency problem to some extent, the feeling of control goes up, thus the motivation for deeper change goes down. That creates the reinforcing loop to favor the approach of managing rather than removing dependencies. Whether does this addictive loop exist? It depends on whether it is seen good enough to deliver in PI, and whether PI planning is seen effective in solving dependencies.


In my recent experience, the organization I worked with adopted SAFe before moving towards feature teams. They did not see that PI planning was sufficient in solving dependencies, "especially when there is change, which is inevitable in their environment". That makes me wonder that the pace of change is another variable affecting the dynamic.


The focus on PI, rather than Sprint, reduces the ability to respond to change. The assumption to make PI planning somewhat effective is that PI content is relatively stable during PI. Change is very disruptive to PI plan.


Therefore, I could imagine that "shifting the burden" dynamic exists when focus on PI is good enough and there is little change during PI, because then dependencies are seen well managed, so that the motivation for organizational change towards feature teams would be low.