The Odd-e Blog

The Authors

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.


Seeing the system dynamic: 1 vs. n product owners

I thought that this choice was essentially the same as the choice of 1 vs. n Product Backlog. When I examine more, I find it worthwhile to write it as a separate topic. As the two most popular scaling frameworks - SAFe and LeSS, they made different choices on this. ART in SAFe and LeSS (up to 8 teams) in LeSS are comparable in size. In ART, there are product manager and team POs; while in LeSS, there is only one PO working with all teams. In this article, we shall explore the dynamic around having 1 vs. n POs.

In the description of ART in SAFe, it states the reason of having team POs.

"At scale, a single person cannot handle both product and market strategy while also being dedicated to an Agile Team. Therefore, the 'PM/PO' team steers the train together."

Let's explore the dynamics of why doing so and what consequences it causes.

Prioritization over Clarification

The below CLD illustrates the dynamic about introducing multiple POs to share the workload of requirement clarification.

Organize people - 1 vs n PO - 1.png

Introducing multiple POs as a solution to reduce the workload of requirement clarification by one PO is reflected by B1-loop, which can read like this:

  • Higher workload of clarifying requirements by one PO
  • More POs
  • Lower workload of clarifying requirements by one PO

Behind the solution, there is a common misunderstanding about PO solely responsible for requirement clarification. In one-team Scrum, it is more a matter of choice, as described in Scrum guide.

"The Product Owner may do the above work, or have the Development Team do it."

The above work includes requirement clarification.

While in multiple-team Scrum, it is more a necessity if we would like to enable one PO to work with multiple teams, as described in LeSS.

"A LeSS Product Owner focuses on thinking hard about prioritization but collaborates with the teams on clarification. Further, he encourages and helps the teams enter into a direct conversation with true users and customers for clarification. He acts as a connector, not an intermediary."

This alternative solution is reflected by B2-loop, which can read like this:

  • Higher workload of clarifying requirements by one PO
  • More participation on requirement clarification by team
  • Stronger ability of working with customers by team / Richer business domain knowledge by team 
  • Lower workload of clarifying requirements by one PO

The R-loop explains why it is so common to stick with multiple POs. It can read like this:

  • Higher workload of clarifying requirements by one PO
  • More POs
  • More dependence on POs
  • Less participation on requirement clarification by team
  • Weaker ability of working with customers / Poorer business domain knowledge by team
  • Higher workload of clarifying requirements by one PO
  • More POs

If you have read the previous blogs in this series, you must have recognized the system archetype of "shifting the burden" here.

Status Quo of Contract Game

The below CLD illustrates the dynamic about introducing multiple POs from R&D to accommodate the change resistance on business side.

Organize people - 1 vs n PO - 2.png

Traditional way of working between business and R&D is through contract game. Business and R&D negotiate a contract for the release, then, business leaves R&D to deliver the contract. There was no sprint-based collaboration between them before adopting Agile. It means more change needed on business side when you want to have more POs. The resistance ensues and more POs in R&D are created as a result. This solves the resistance problem meanwhile fulfills the need to have POs. The status quo is maintained.

The B1-loop is the quick solution, which can read like this:

  • the more change needed on business side (more POs needed)
  • the more resistance it creates
  • the more POs in R&D introduced
  • the less change needed on business side

The B2-loop is the fundamental solution, which can read like this:

  • the more change needed on business side (more POs needed)
  • the more resistance it creates
  • the more coaching for business
  • the more collaboration introduced between team and business (either as POs or as stakeholders, but the key is to collaborate sprint by sprint)
  • the more value it creates and the more flexibility it creates
  • the less change needed on business side

The R-loop explains why it is so easy to revert back to status quo. It can read like this:

  • the more change needed on business side (more POs needed)
  • the more resistance it creates
  • the more POs in R&D introduced
  • the less collaboration between team and business (as PO-team collaboration becomes internal for R&D)
  • the less value it creates and the less flexibility it creates
  • the more change needed on business side

Again, you see the system archetype of "shifting the burden".


I have seen two common setups when having multiple POs for one product.

In many Internet companies, those team POs are product managers at the low level. They are working mainly on tactical level, not much on strategic level. When they feed teams with detailed specification and UI sketches, the level of team engagement in product discovery is low. This not only misses the opportunity for team to contribute, but also creates barrier to reach shared understanding for delivery.

In more traditional industries, it is common to introduce team POs inside R&D. When they are focused on requirement clarification, they essentially regress to traditional BAs. There are many arguments against BA role, and my favorite is the keynote from Martin Fowler and Dan North in QCon London 2007. In short, "bridges are better than ferrymen".

Be aware of the consequences when you choose to have multiple POs.


Seeing the system dynamic: Sprint vs. PI

Regarding time dimension, SAFe introduces another concept called PI (Program Increment) besides Sprint. This is a super Sprint, by default consisting of 4 normal Sprints plus 1 special Sprint called IP (Innovation and Planning). In Scrum and LeSS (LeSS is still Scrum), there is no such concept, and Sprint is its sole focus. In this article, we are going to explore the dynamic behind Sprint vs. PI.

In order to model the system dynamic around them, we need to first understand the essential difference between Sprint and PI.

In Scrum, planning horizon and releasing frequency are often coupled on Sprint. In fact, this distinguishes the timebox approach from the flow approach in Kanban. However, they are also not fully coupled, as in practice some teams are releasing on Sprint cadence, other teams are releasing more frequently - even continuously, still other teams are releasing less frequently - releasing after a few Sprints.

PI is still a timebox, thus coupling planning horizon with releasing frequency. PI talks about "plan on cadence, release on demand", which is essentially the same as Sprint. Some teams are releasing on PI cadence, other teams are releasing more frequently, still other teams are releasing less frequently.

When modeling, we separate planning horizon and releasing frequency as two variables. And we make the following assumptions.

  • Planning horizon with PI is longer than with Sprint, but shorter than with traditional release.
  • Releasing frequency with PI is lower than with Sprint, but higher than with traditional release.

The below CLD (Causal-Loop Diagram) illustrates the dynamic around this topic.

Organize time - sprint vs pi.png

Shorter planning horizon and higher releasing frequency

1. Why?

As we move from traditional release to PI then to Sprint, we shorten planning horizon and increase releasing frequency. The R1-loop and R2-loop explain the key driving force, which is the flexibility, i.e. the ability to respond to change.

I often heard about comments of not having the need for more flexibility, as their market is rather stable and their customers do not change that often. There is a bit of truth in it, though it ignores the dynamic. The market change is also affected by our capability of responding to change. When the flexibility on our side is low, we try to control the changes instead of embracing them, which leads to the perception that we do not have much change. When one player in the industry starts to increase the flexibility, market and customers are exposed to more possibilities, other players have to follow.

2. Limiting factors

B1-loop, B3-loop and B5-loop illustrate the limiting factors to shorter planning horizon and higher releasing frequency. Combined with R1-loop and R2-loop, it forms two instances of "limits to growth" system archetype.

B1-loop and B3-loop limit R1-loop (towards shorter planning horizon)

B1-loop reads like this:

  • the shorter planning horizon
  • the more change resistance on business side
  • the longer planning horizon

As business side is familiar and comfortable with the contact game, the longer planning horizon, the easier to work with from their point of view.

B3-loop reads like this:

  • the shorter planning horizon
  • the less synchronized
  • the longer planning horizon

As existing structure and capability constrain on how much synchronization we can get, the longer planning horizon, the less demand on synchronization.

B5-loop limits R2-loop (towards higher releasing frequency)

B5-loop reads like this:

  • the higher releasing frequency
  • the higher releasing cost
  • the lower releasing frequency

As releasing cost may be high due to weak test automation, inefficient deployment, etc. the lower releasing frequency reduces the total releasing cost.

3. Leverages

B2-loop, B4-loop and B6-loop provide the fundamental solutions in contrast to B1-loop, B3-loop and B5-loop respectively.

Coaching business side (B2-loop)

It is a big shift from working in contract game to collaborating on Sprint. Coaching business side requires skills and hard work, as well as patience. Regardless of PI or Sprint, close collaboration between business side and R&D, rather than relying on contract negotiation, is essential for achieving agility. Therefore, coaching business side in making the shift is the fundamental solution.

Improving synchronization (B4-loop)

In a scaling environment, many factors make multiple teams out of sync, such as team structure, way of splitting work, ability to coordinate across teams, etc. The fundamental solution involves changing team structure from component teams to feature teams, splitting stories into small, enabling self-organization for cross-team coordination, etc.

Reducing releasing cost (B6-loop)

While treating releasing cost as fixed cost, the only remaining way becomes reducing the releasing frequency. However, releasing cost can be decreased by improving deployment infrastructure, automating regression tests, preventing defects or finding them earlier, etc. These are fundamental solutions.

It is all about status quo

I have not described R3-loop, R4-loop and R5-loop. These are addictive loops in the "shifting the burden" system archetype. There are three instances. B1-loop, B3-loop and B5-loop represent status quo in the old system. R3-loop, R4-loop and R5-loop act as forces to maintain the status quo.

Status quo of contract game

B1-loop represents the status quo regarding the working way between business and R&D. For many organizations, the status quo is that business people do not work with teams on Sprint cadence, while only negotiate a contract with them during release planning. PI planning resembles the traditional release planning and commitment game, thus, makes it more likely to be accepted by business side. Comparing to Sprint based collaboration, this is not good enough. On the other hand, PI as planning horizon is shorter than traditional release, thus a step forward.

Status quo of coordination

B3-loop represents the status quo regarding team structure and coordination mechanisms. For many organizations, the status quo is component team structure and having coordination roles such as project managers to squeeze out value delivery. While Sprint makes status quo unacceptable, PI leaves more room to accommodate status quo. On the other hand, PI provides tools such as big-room planning to increase the coordination capability via self-organization. This enables the synchronization on every PI, which is a step forward than every traditional release.

Status quo of hardening

B5-loop represents the status quo regarding hardening, which is essentially the undone work. For many organizations, the status quo is having a hardening phase to remove any undone work before releasing. The special Sprint (previously even called HIP, where H stands for Hardening) accommodates it, which resembles the testing and bug fixing phase in traditional waterfall project. On the other hand, releasing on PI cadence is more frequent than traditional release, thus a step forward.

In summary, introducing PI may be a clever move as it resembles traditional release, thus reducing the change resistance, while still taking a step forward. On the other hand, it may not challenge status quo enough, thus grind to a halt after its adoption.


Product learning in Sprint review

Sprint review is the Scrum element for which I evolved my understanding the most during the past 10+ years.

There still exists two prevalent but mistaken views.

  • Sprint review is about showcase. The demo could be an effective vehicle for product learning, but showing "good" case, and hiding "bad" case completely miss the point of sprint review.
  • Sprint review is about acceptance. The deep mindset involved is still contract and blame, rather than collaboration and learning.

In my view, the proper focus of Sprint review is product learning.

Levels of product learning

We learn about product from what and why. For what, there are various levels. We learn about story details on acceptance criteria; we learn about release progress on release turndown; we learn about meaningful product slices on story map. For why, we learn about product goal on impact map. Let me explain.

  • what/story, on acceptance criteria

We learn if the team has delivered the right stories. The main learning here is whether we had the shared understanding for those stories. If PO and team collaborate well during the sprint, chances are, PO has already checked this with team. Then, it becomes mainly checking with stakeholders to see if they have the same shared understanding. The results lead to the acceptance or decline, and possibly some improvement ideas on story level, which may become new or updated stories.

  • what/release, on release burndown

We learn if the release is on the right track. This is more about project view than product review. Traditional release burndown helps us understand if the release deviates from the plan, and then we adapt by varying scope, schedule or cost. In an environment where right stories are more known, it makes sense that the learning about delivery progress becomes the focus. Otherwise, we shall go deep into further product learning.

  • what/product, on story map

The learning on story level may be limited, particularly when we split stories for delivery purpose but break the natural size of uses. During initial backlog creation and backlog refinement, you may have done some story mapping and mapped separate stories into user scenarios. Sprint review is the time to revisit your story map. The granularity of discussion is around user scenarios. This reflects better about the progress, as those are more meaningful things for users, rather than separate stories. This supports better in discussing about what's still missing and what's next. This connects better with users as they are more engaging with meaning product slices, which ofter leads to more insights and product ideas.

  • why/product, on impact map

The next level of learning is how much progress we made in achieving why. During initial backlog creation and backlog refinement, you may have done some impact mapping and mapped stories to the goal and measures. Sprint review is the time to revisit your impact map and assumptions. We collect data for the released stories in the past sprints. We evaluate the real impact and come up with next stories to learn or build.

Ways of product learning

Product learning happens with the right people. Besides PO and team, stakeholders such as users and marketing are invited.

I learned the below 4 quadrants of product learning based on what users say vs. do and qualitative vs. quantitative from a former Alibaba product manager Su Jie. 

Blog - product learning in sprint review.png

He puts one example method in each quadrant.

  • Interview, qualitative learning, based on what users say
  • Survey, quantitative learning, based on what users say
  • Usability testing, qualitative learning, based on what users do
  • Data analysis, quantitative learning, based on what users do

Inspired by this, we could organize product learning in sprint review with various ways.

  • demo stories and user scenarios
  • interview with prepared questions
  • survey with prepared questions
  • observe uses of stories and scenarios by users
  • data analysis to understand impact
  • ...


The number of emergent requirements from Sprint review is a reflection of the amount of product learning in Sprint review. My colleague Terry came up with Agility Index that beautifully illustrates this point.

Turn your Sprint review into a product learning session and let your valuable requirements emerge.


User role modeling

User role describes the relationship to the system. 

I read this from somewhere, but could not find its origin any more. In Mike Cohn's classic book "User Story Applied", there is a chapter dedicated on this topic called "user role modeling". It referred to Larry Constantine's work and his book "Software for Use", chances are it is from there. Do let me know if you happen to know.

Anyway, from my recent experience in helping team charter a new project, we encountered an example that illustrated this nicely.

It is a data application for internal use. Some common uses are as below.

  • Sales looks at product information and price information while creating quotation for customers.
  • Sales updates price information.
  • Marketing looks at product information and price information while building marketing campaign.
  • Marketing uploads product photo.
  • Product engineer adds new product information.
  • Product engineer restricts the access to certain product information.
  • Pricing group uploads price information.
  • Pricing group validates price information.
  • ...

It is tempting to define the following user roles.

  • Sales
  • Marketing
  • Product engineer
  • Pricing group
  • ...

Those roles come directly from work, thus, easy to access. However, those do not describe the relationship to the particular system - the data application. Why does it matter? Same roles have different intents onto the system, while different roles have similar intents onto the system. This makes it difficult to understand the system from those user roles. It makes it a lot easier to understand the system when you define user roles in terms of their relationships to the system.

For this data application, in terms of relationship, we define initial user roles as Producer and Consumer.

Considering two major data types in this application - product data and price data, we may refine the initial roles further like this:


  • of product data
  • of price data


  • of product data
  • of price data

Product data contains text data and photo.

Considering different ways of producing and consuming data, we may refine the initial roles further like this:


  • creator
  • updater
  • controller


  • viewer
  • validator

When we consolidate the user roles with those mixed, we end up with the following list.


  • Product text data producer (by product engineering)
  • Product photo producer (by marketing)
  • Pricing creator (by pricing group)
  • Pricing updater (by sales)
  • Pricing controller (by pricing group)


  • Viewer (of both product and price data, by marketing and sales)
  • Product validator (by product engineer)
  • Pricing validator (by pricing group)

Mike Cohn in his book defines user role as "a collection of defining attributes that characterize a population of users and their intended interactions with the system." To me, this is the verbose version of "relationship to the system".


Paradox in coaching self-organizing team

Recently, I read an interesting experiment from the book "Why we do what we do: understanding self-motivation" by a psychologist called Edward L. Deci.

In this experiment, the subjects were teachers. They came into the lab to teach students how to solve problems. They were randomly assigned to one of two groups, everything was the same for the two groups except for the fact that researchers made one additional statement to the teacher in one group, "remember, it is your responsibility as a teacher to make sure your students perform up to high standards". The researchers then tape-recorded the teaching session and did the analysis. The result was astonishing. The teachers to whom researchers had mentioned the additional statement spent 2x as much time talking during the teaching session as the other teachers. They also made 3x as many directives and 3x as many controlling statements such as "should" or "must".

In order to achieve good results in the students, many people in real life such as school administrators or parents pressure teachers to produce. The paradox is the more they do that, the more controlling the teachers become, which undermines intrinsic motivation and performance in the students. The harder the teachers are pushed to get results, the less likely it is that the important results will be forthcoming.

One essential element in coaching self-organizing team is to support team's autonomy. This experiment provides much food for thought on it.

1. Dedicated coach role

When introducing ScrumMaster role, one question arises - how does it differ from traditional team leader role? For ScrumMaster, a well-working team is her product. In the regard, traditional team leader shares the same responsibility. One could say that traditional team leader does more command and control, while ScrumMaster does more facilitation and coaching. What about team leader with facilitative and coaching style? Does it differ any more from ScrumMaster in that case?

Well, team leader is still responsible for the team performance, instead of team itself. This reflects the organizational hierarchy. Does it matter? Even though I have seen autonomy-supportive team leaders, as well as controlling ScrumMasters, taking the delivery responsibility away from coach role still makes a difference.

This reminds me of Michael James's keynote "Human Beings and Scrum" in Shanghai Scrum Gathering 2013. He stated, "Scrum is the only approach that dedicates a role to create environments for learning, innovative teams - without giving contradictory responsibilities." Delivery is one contradictory responsibility, as the associated pressure creates obstacle for promoting autonomy.

This can be confirmed by my own experience as development area manager in NSN time. Even though I had a deep belief on self-organization and autonomy, I unconsciously (only realized in retrospect) became more controlling when facing great pressure to release the product.

Therefore, there is a reason to believe that having dedicated coach role such as ScrumMaster helps coaching self-organizing team.

2. Coach's performance

As coach does not have the direct responsibility for delivery, how do we know if they are doing a good job? We could see it from the improvement of team performance. Furthermore, when considering self-organizing team, one essential aspect to see is whether team becomes more autonomous.

Coaches face the same paradox as those teachers in the experiment. When they feel more pressured in doing a good job, it is less likely that they will do. I draw the following CLD to illustrate.

paradox in coaching.pngThe B-loop is the reason why they become controlling. The R-loop illustrates the long-term effect. When they become more controlling, intrinsic motivation is undermined, then team performance is degraded in the long run. Notice that the R-loop also works from the other direction - when they feel less pressured in doing a good job, it is more likely that they will do.

I remember that a few years ago, I had a conversation with a friend about this. She commented that it would be very hard for junior ScrumMasters not to feel pressured in doing a good job. This is natural as they need to demonstrate their ability for building confidence and trust. This is the same for ScrumMaster, internal coach, as well as external coach. ScrumMaster and internal coach get pressure from management, while external coach gets pressure from clients. How can they feel less pressured, thus more likely to keep autonomy supportive? Here are a couple of ideas.

Management or client believes in coach's intrinsic motivation of doing a good job, thus, gives space and time to coach. Performance evaluation works more like performance feedback session focusing on improvement rather than evaluation.
Coach makes their own effort not to hook onto the result. The proper state of mind is that they care, but not attached to the result. They care for the sake of caring. When they feel less attached, they feel less pressured, regardless of the expectation from outside. To me, this state of mind is similar to the one in those parents who are effective in helping child develop true self.

3. Parent's state of mind

Parents play an important role in helping child develop true self. They can be autonomy supportive or controlling, which nurtures or undermines intrinsic motivation accordingly. Parents face the same paradox. When they feel pressured to be "good" parents, they become controlling, which undermines child's intrinsic motivation. Eventually child would fail to develop true self.

As no "management" or "client" gives parents pressure to produce result, where do parents get pressure? They are certainly influenced by the society, such as other parents around them, teachers at school, etc. It is hard to change the social environment, same as it is often hard to change management or client's expectation towards coach. As parent or as coach, we both need to learn how to keep own autonomy in that environment.

I have a daughter. I surely care about her. However, she has her own true self to develop, and my self worth is not defined by her either. I view our relationship as enriching each other's life. With that view, I feel less pressured in producing certain result, thus, tend to be more autonomy supportive, which I hope will help her develop true self. I hold the similar state of mind when coaching self-organizing teams for clients.


Promoting autonomy is essential in coaching self-organizing team, while one obstacle is the pressure of producing result. The book "Why we do what we do" gives much more insights, and I would like to recommend it to any parents or teachers who have the interest in helping children develop their true self, as well as any ScrumMasters or coaches who have the interest in helping self-organizing teams develop their autonomy.


Seeing the system dynamic: sprint vs. flow

Regarding the time dimension, there are two main options - sprint (aka iteration, timebox) or flow. This choice is often coupled with the choice of implementing Scrum vs. Kanban, respectively. However, in this article, we do not try to compare Scrum vs. Kanban, but only sprint vs. flow. We focus on seeing the system dynamic around its impact on value delivery and continuous improvement.

1. Value delivery

We aim to maximize the value delivery, and the key is to reduce WIP regardless of whether to use sprint or flow. The below CLD illustrates the dynamic around this.

Organize time - sprint vs flow - 1.png

There are actually many R1-loops. As their essence is the same, I put them under same label.

R1-loop creates the virtuous cycle of reducing WIP to maximize value delivery, which can read like this:

  • the less WIP
  • the more flexibility and/or the higher speed
  • the more value delivery
  • the more "use of same ways to reduce WIP"
  • the less WIP

Then, there are various ways to reduce WIP.

a. Limiting #stories

  • shorten sprint length (indirectly limiting #stories), when doing sprint
  • decrease WIP limit (directly limiting #stories), when doing flow

b. Reduce story size

Sprint creates force to split the story, as it is required to complete the story at the end of timebox. When story size is smaller, it reduces WIP further. This contributes to the virtuous cycle.

However, too much force will make the story splitting unnatural, thus, decrease the value in those split stories. This forms B1-loop.

    • the more value delivery
    • the shorter sprint length
    • the more force to split story
    • the less value in split stories
    • the less value delivery

The story could not be split infinitely, as there is natural limit on how small a valuable story could be. If you look at R1-loop and B1-loop together, it is actually a typical "limits to growth" system archetype. Eventually, growth process hits the limit. In reality, there are many other limits. I choose to illustrate this one as it relates to the common accusation for timebox approach.

2. Continuous improvement

We aim for continuous improvement, and the key is to create the right amount of challenge to drive improvement, regardless of whether to use sprint or flow. The below CLD illustrates the dynamic around this.

Organize time - sprint vs flow - 2.png
The B2-loop illustrates the relationship between challenge and improvement, which can read like this:

  • the more challenge
  • the more drive for improvement
  • the more improvement
  • the less challenge

The R3-loop illustrates the unintended consequence when the challenge is too big.

  • the more challenge
  • the more pressure
  • the more quick fix (e.g. sacrifice quality)
  • the less improvement
  • the more challenge

You may think of B2-loop and R3-loop together as "fixes that backfire" system archetype. In essence, it explains that having right amount of challenge matters.

As B2-loop is a balancing loop, it leads to the stagnancy of improvement. Continuous improvement is never ending, for which we need a reinforcing loop. There are actually many R2-loops. They are all about elevating goals to create right amount of challenge again, so that improvement will continue. Thus, I put them under same R2-loop, which can read like this:

  • the more improvement
  • the higher "improvement goal"
  • the more challenge
  • the more drive for improvement
  • the more improvement

Then, there are various ways to elevate goals.

a. Limiting #stories

  • shorten sprint length (indirectly limiting #stories), when doing sprint
  • decrease WIP limit (directly limiting #stories), when doing flow

We have seen its role in maximizing value delivery, here comes another important role limiting WIP plays, which is for continuous improvement.

b. Expanding system scope

  • In Scrum, this means extending Done.
  • In LeSS, this means extending Done, expanding product definition, or both.
  • In Kanban, this means expanding the scope of Kanban system.

When system scope is expanded, the challenge increases, which creates drive for continuous improvement.

c. Elevating improvement goal

The above is essentially all various ways to elevate improvement goals. Besides, making it flow and shortening cycle time is probably the most important goal in Kanban. See more in my article about improvement goal.


With the choice of sprint vs. flow, they essentially use different ways to reduce WIP, while low WIP helps for both value delivery and continuous improvement.


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.


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)