The Odd-e Blog

 
The Authors
 

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
  • ...

Conclusion

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:

Producer

  • of product data
  • of price data

Consumer

  • 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:

Producer

  • creator
  • updater
  • controller

Consumer

  • viewer
  • validator

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

Producer

  • 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)

Consumer

  • 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.

Conclusion

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.

Summary

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.

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.