This is a cross-post from Evolve Agility blog post.

A Systems modeling technique to visualize and act on deeply entrenched systemic issues.

Everyone carries a model, fuzzy as it may be, a map of sorts to navigate reality as perceived. As team members we have expectations from each other. This internal picture of our expectations, and reasons, and emotions, and all the mess that is being human is our mental model. The differences between what actually happens and what we expected it to be, reinforces our mental models or alters it. Learners are able to update their mental models more often, and thus adjust their actions and expectations with ever emerging reality.

I find that curiosity is the doorway to learning. Accumulation of knowledge on the other hand is founded on the mistaken belief that knowing about a thing is the same as knowing the thing.

By learning, I do not mean accumulation of knowledge or a collection of jargon to impress your colleagues. By learning, I mean understanding that enables you to take actionable steps in a very real practical sense.

Here I want to share an actionable technique that I have used to assist teams in learning together. But first, let’s acknowledge that everybody has a blind spot. No one at any time, not even once, can be all knowing.

Everybody has a blind spot

Learning never stops, and this is the humbling truth. Mental models are at best approximations of reality, and can never be perfect.

As a hobby motorcycle rider, I constantly update my ‘model’ by continuously orienting myself to [sic]changes[sic] in road conditions, weather, other drivers on the road. We make up for lack of accuracy in our mental models by noticing these changes and adjust accordingly.

On the other hand, developing a perfect model will require that the rider account for every breeze, every pebble in order to develop an accurate picture of the situation at hand. And then take the next course of action. This as we know is analysis-paralysis. This affliction is detectable when people mistake knowledge about a thing, to knowledge of the thing. People who know about motorcycle maintenance talk more and do less, whereas actual mechanics talk less and do more.

We do not want to be bogged down with minutia, but act in response to emerging reality. A rider observes to validate or update their understanding of ground conditions. Additionally the rider continually scans/reorients to collect a good enough picture of emerging reality.

Never let your eyes fix on an object for more than two second, keep looking around. – Motorcycle rider manual.

Intense periods of concentrations may improve your resolution, but it comes at the risk of increasing your overall blind spot. If you have driven under snowy conditions, you know about the perils of tunnel vision. Focusing to appreciate each unique snowflake is not a recommended way to force an invitation to meet with your maker.

Without further ado, here are the steps to facilitation.

Step 1: I wonder…

There is no learning without curiosity. So what are you curious about? I find that framing your curiosity as “I wonder…” opens people up to alternative possibilities, and perhaps awakes our inner playful inquisitive spark. Following are some examples:

• I wonder why my team does not take on challenging work, or increase their productivity.
• I wonder why management focuses on metrics so much?
• I wonder why my team is unable to release software more often?

Step 2: Just talk

Bring your curiosity to your team, and check for interest in exploring this topic further. Give up on knowing, and you will invite others to wonder together with you. ‘Just talk’ is best practiced as a relaxed conversation with your team members.

Remember everybody has blind spots. No one, not even you will have complete understanding. By ‘just talking’, you and the team members are exploring various factors that surround a topic.

We will use the first statement as an example for illustration.

I wonder why my team does not take on challenging work, or increase their productivity.

A brief 5-10 minute conversation within your team may yield the following related factors.

Fig. 1: Brainstorm related factors

Related factors are often the ones that are perceived to change (increase or decrease) along with the topic at hand.

For example, in your ‘just talk’ session - you may have a talk about the situation when following a certain process step imposed by higher management leads to misunderstandings in team processes. You may capture this as two related factors “higher management process mandates” and “team understanding of management processes”, or as I have expressed above “team has autonomy over processes”. Fewer factors is better, and best not to get bogged down with wordsmithing.

CAUTION: These are by no means the only possible factors. And in your discussions within your team there will very likely be a different set of factors.

Within a team, each member has their own blind spots, but collectively the diversity within a cross-functional team will allow team members to cover for each other’s gaps in understanding.

Step 3: Sensitivity check

Expect that different members in the team will have different degrees of sensitivities, and therefore you may find more than a handful of factors.

While it may be tempting to acknowledge everyone’s sensitivities on this matter, trying to consider too many factors at once will lead to analysis-paralysis. And our goal in this exercise is to be actionable

CAUTION: From the superset of related factors, select no more than eight factors. Fewer than four and you may not have considered the diversity of factors, and more than eight (or perhaps ten) and your collective efforts will remain stuck in analysis-paralysis.

As a team you can collectively agree on top eight factors, or use a prioritizing technique, such as dot-voting, to select factors that closely correlate with the subject of your team’s curiosity.

In our example, we have selected the following eight factors.

Fig. 2: Selected factors

Step 4: Around the clock

Organize your items on a physical/digital whiteboard so that items together form a large enough circle, with the items arranged roughly on the hour positions of a clock.

Fig. 3: Circle arrangement

This step is best performed by randomly selecting one of the eight or so factors, and placing these randomly on the hour positions. Avoid unnecessary analysis.

Step 5: Select a facilitator

I strongly recommend that you have a facilitator for this step. During the next analysis step, your team will dive into the relationship between selected factors. A dedicated facilitator will

• prevent the whole group from getting too bogged down into the details.
• move the team along, and avoid tunneling.

The facilitators primary concern is to avoid analysis-paralysis, which merely leads to accumulation of knowledge, but no practical understanding that enables action.

The facilitator focuses on group interactions for remaining steps, and does not contribute in any other way.

Step 6: Simple cause and effect (Analysis)

The facilitator will invite team members to discuss relationships between sticky notes. The facilitator invites discussion within the team by posing a question:

“Is it because of [cause] therefore [effect] ?”

This is by far the most tedious step in this process, and takes a while to get comfortable with. As a facilitator you will need to use this phrase over and over again. By repeating the same sentence structure you are refraining from undue influence, and establishing a pattern for others to know when you are inviting discussion to consider the next relationship.

Round and around, relationships in a merry go round.

(a) Is there a cause-effect relationship? and which way?

Starting with the first sticky note item at the 12 O’clock position, the facilitator will ask the rest of the team to check for simple cause & effect relationships:

“Is it because people feel empowered therefore we have inspiring goals/vision ?”

AND then, after a brief pause check for causality in reverse:

“Is it because of inspiring goals/vision therefore people feel empowered ?”

By checking for directionality of cause and effect in both ways, your team may quickly discover the nature of the relationship between the two sticky notes (factors)

- OR -

conclude that these factors are not directly influencing each other.

In the example above your team may agree that inspiring goals/vision make them feel empowered.

(b) Is there a dominant direction?

Now keeping the same sticky note at 12 O’clock position as the anchor item, and moving clockwise, the facilitator will ask the team to check for relationship between the anchor item and the next in line factor:

“Is it because people feel empowered therefore increase in team productivity ?”

AND then, after a brief pause check for causality in reverse:

“Is it because of increase in team productivity therefore people feel empowered ?”

While the team is analyzing the relations, the facilitator must avoid getting dragged into their considerations. The facilitators role is to prevent analysis-paralysis from taking hold. While facilitating, ask the team members to pick one directionality as dominant.

DO NOT ALLOW FOR A RELATIONSHIP BETWEEN FACTORS TO BE BIDIRECTIONAL.

I say this with extra emphasis, not because bi-directional relationships do not exist, but because opening the exercise to also consider bi-directionality will confuse matters in the long run, and will get in the way of being actionable.

So when your group thinks that there is bi-directional relationship between two factors, pick one direction that is more likely or truer for your specific case.

In the example above, your team may find that when people feel empowered the productivity of the team improves as the more dominant relationship. Although it may also be true that when the team is productively humming, its sense of empowerment improves.

Fig. 4: Cause and effect directionality

(c) Round robin

Keeping your 12 O’clock factor as the anchor, check for cause-effect relationship with remaining factors. Once your team has considered the relationship between the anchor factor “people feel empowered” with remaining factors, you will go through the same process all over again.

This time, you will move clockwise and select the factor at 2 O’clock position to be the anchor item. Since we have discussed the relation between the new anchor and the previous anchor, we will have one less relationship to discuss.

After cycling through anchor #2, you will select the next in line anchor moving methodically in clockwise fashion. Each time you cycle through, there is one less relationship to discuss. Until finally there is only one relationship to discuss between the seventh anchor and the eight factor.

Hence, my caution in step 3 above to limit the number of factors to a maximum of eight.

This analysis is essential. By exploring cause-effect relationships, the team is collectively forming their shared mental model of factors and relationships between them.

You may end up with a map of cause and effect relationships like this.

Fig. 5: A web of cause and effect relations

(d) You can not present this

This messy ball of relationship yarn, must be confusing to you. Just as it should be. You were not involved in the discussions that led to it. This diagram would mean as much to you as it does to a playful kitten. Something to toy around with, and perhaps to get entangled in a cute mess with.

Fig. 6: Do not present your ball of yarn, unless you are this cute

The value of Simple cause and effect analysis lies in enabling structured conversations within the team. This is an approximation, at best, of shared understanding of the context within which this team operates. The hidden systems structure that governs observable behaviors and events. This visual representation means a lot to the team members who participate in its creation. It provides a reference for all team members to visualize together. A snapshot of how team members intuit their organization system to really work. How cool is that!

Curiosity (I wonder…), and participation (engagement) are prerequisites to understanding. You cannot present this model. It will make no sense to your manager or your friend. They will have to engage in a conversation with your team and influence the shape of this shared mental model. And as a consequence they will share their learning with others, to increase overall team awareness. Therefore, I strongly encourage managers to participate and wonder along with their teams.

The services of a facilitator are crucial. Their patience, and methodical channeling of discussions to keep momentum helps a team to not get bogged down in minutia. With practice, Step 6 - Simple cause and effect takes 15 - 20 minutes.

But the facilitator’s role is not done yet. The best is yet to come.

Step 7: Dominant factors (Synthesis) - a debrief

Learning together as a team involves owning your insights and taking actions based on them. You cannot borrow these insights from the “best practices manual”, and no tool is a substitute for judgment. As a team you will have to arrive at your own insights, and take action based on your own understanding.

In complex systems, any system that involves people, there is never really a single cause nor a real single effect. Things are interconnected, and in surprising ways. With the simple cause and effect diagramming above, our objective is not to play post-it billiards. Instead we want to develop a shared understanding by considering the system as a whole. There are revealing insights in the picture above, if you know how to look for it.

For each factor count the number of arrows going out, and the number of arrows coming in.

Fig. 7: Count INs and OUTs

A quick reminder on our curiosity that led us here:

I wonder why my team does not take on challenging work, or increase their productivity?

Dominant effects

Reviewing our counts reveals that the system as modeled, through team conversation, has the following dominant effects:

1. Increase in team productivity. (0 - OUT, 4 - IN)
2. Team takes on challenging work. (0 - OUT, 6 - IN)

Nothing terribly surprising here. Of course since the manager and/or the team is curious about lack of initiative from the team in taking challenging work and wants to increase productivity, we are now assured this is indeed a visible outcome of this systems structure.

Everybody sees the dominant effect, and worries about it. Visibility attracts attention. And as a consequence of attracting attention, it gets measured. Any real or perceived lack of meeting expectations, or desire to showcase improvement will draw attention to this most visible factor. The dominant effect.

Managers may rush to create a team member skills competency matrix so they can hold them individually accountable. Or hold a team meeting to set expectations on the number of story points/breadth expectations from the team. Such interventions are easy to announce, and may show marginal improvement in the short term. And therefore, perhaps, these continue to be tried over and over again.

Such interventions are naive, because they work against systemic leverage. Understanding points of leverage within your system and directing interventions appropriately can unlock long term shifts.

Dominant cause

A quick review of our counts reveals that the system as modeled, through team conversation, has the following dominant causes:

1. Culture of trust (4 - OUT, 0 - IN)
2. Inspiring goals/vision (4 - OUT, 0 - IN)
3. Team has autonomy over processes (4 - OUT, 1 - IN)

Notice that I am ignoring factors that have almost the same number of arrows IN and OUT.

A dominant cause is one that affects many factors directly or via other factors. Interventions aimed to make desirable shifts in dominant causes hold more promise.

Dominant causes often become entrenched and hidden. They can be hard to pin down. And this is why we have gone through all the steps so far - so the system at play can reveal its secrets.

Systems modeling is a collective activity for the whole team, and not for a manager alone. Through modeling, team discussions, and visually representing a shared model, your team will unlock additional insights that could hold revealing breakthroughs to make shifts at these crucial points of leverage.

For our purposes, we will go through the example discussed to consider some practical steps that can be taken by a team. These may not be applicable to your specific situation.

Building a culture of trust can be a humongous task when considered at the scale of a corporation. But at the same time building pockets of trust may be feasible within a single team. What can team members do to improve trust between themselves and with their managers ? Your team may start holding retrospectives again or take time out to socialize over virtual lunch. For an example of technique that I have used, see sharing values exercise to improve the degree of trust within your sphere of influence.

Managers may also consider easing down on prescriptive ways or, even better, set up a decisions agreement with their team, see decide how you are going to decide, so the team and management can have explicit agreements in areas where the team has autonomy over its processes.

Understanding the points of leverage for your system at play can open up a wide array of possibilities. A tiny change at these points of leverage can have disproportionate (non linear) impact on the overall system dynamics.

Get creative. Mix and match to design counter-measures that make a tiny dent across multiple factors, or consider a set of related counter measures to be tried all at once.

Because the dominant causes are so entrenched, they may not easily budge. And so, paradoxically, attempts to influence dominant causes lead to safe-to-fail experiments. Because big changes cannot be tried at once, you have to take incremental steps. And also because no one expects you to actually tip the system, you have the advantage of attempting multiple creative interventions.

Fig. 8: Dominant factors

Boundaries

Of course there is no way we can model all the factors that are involved. Remember everybody has their blind spots.

Clearly there must be some other factors that cause changes to “culture of trust” and “inspiring goals/vision”. Just because in our systems diagram there are no factors that affect them, it does not mean that there are no other factors that affect these dominant causes.

Our understanding of factors itself will also also be incomplete. Of course a culture of trust is not the only factor that affects a team’s autonomy over its processes. There may be instances where we collectively modeled incorrectly, or failed to notice a relationship that actually in fact exists. These are our collective blind spots.

These boundaries of comprehension and understanding are our limits. Teams benefit from keeping this visualization so that the shared systems model can be easily updated.

There is no way one can consider the totality of everything involved to make the best decision. Courage to act from incomplete understanding is foundational to team learning. And this simple cause and effect systems modeling technique can aid your team to collectively build shared understanding of your system at play. So you can decide and agree on what to do about it.

Curiosity awakens

I wonder…

Learning never stops. After attempting this activity in your first area of concern, you will undoubtedly uncover new areas of inquiry.

My hope is that managers and leaders open doors to team learning through their example of practicing curiosity, engaging in collective learning and boldly attempting counter-measures to some of the deeply entrenched issues of the modern work environment.

Do you want to go beyond the basics?

If you found this article useful, join our Accelerate Advantage™ mailing list. Evolve Agility is founded on the belief that people care deeply about their places of belonging and are not afraid to take action. Join our mailing list to stay connected with a growing community of practitioners who believe in actionable learnings.

Virtually every Team in their first Sprint is confronted with the problem of single-specialization causing work imbalance. What happens? The Product Owner orders the Product Backlog to maximize value. But when the team members are specialized in a single dimension - such as QA, Java development, front-end development - some team members regularly will find themselves with no work related to their area of specialization. Single-specialization inevitably causes work imbalance.

Organizations typically react by applying the following quick-fixes, (1) have people be on more than one team, (2) give additional work to the team, or (3) do work for the next Sprint (e.g. design) or work related to the previous Sprint (e.g. QA). The latter two quick-fixes are easily recognized as they lead to half-done items at the end of the Sprint, often referred to as ‘carry-over’ or ‘spill-over’ work.

Key point: The phrases ‘carry-over’ and ‘spill-over’ are not Scrum. They’re signs of dysfunctional Scrum.

Each of these quick-fixes inhibit well-oiled teams and reinforce responsibility at the level of individual members. For most organizations, Scrum entails a change in teams from individual responsibility (of my area of expertise) to a team-shared responsibility (for all work required to achieve the goal of the Sprint). Scrum makes this explicit by having a role: ‘Team’ – a single role of multiple people, rather than roles of team members.

Shared responsibility through balanced specialization

How do teams resolve the problem of specialization and work imbalance? Although it is up to the team, most teams have members learn and create secondary areas of specialization. This does not mean that all team members become generalists – either single-specialization or generalist is a false dichotomy.

Team behaviors that lead to balanced specialization are:

• Whenever the team has the right expertise for current work, every task is a learning opportunity. Any team member can either pick it up and do individually or request to pair or mob.
• Whenever the team feels there is currently enough learning going on, the tasks tend to be picked up by the team members with the most expertise in them.
• Whenever the team does not have the right expertise for the current work, the team discusses how to gain that knowledge through learning and collaboration.

Implications for organizational structure

Most organizational structures, such as functional departments, functional career paths, or component teams cause single-specialization in either functional skill or technology area. When these structures are kept in place while adopting Scrum, they cause conflicting loyalties. Team members have one loyalty towards their team for their shared work and another loyalty to their organizational unit. The organizational loyalty is involved in performance reviews, promotions, and bonuses and therefore tends to ‘win.’ Shared team responsibility only happens when these traditional single-specialization focused organizational structures are eliminated.

Scrum implies a shift from individual responsibility to shared team responsibility, which in turn implies a change from single-specialization to multi-learning. This can only be achieved by eliminating organizational structures that promote single-specialization. Scrum adoptions by ignorant managers that avoid these changes are likely to lead to pretend-Scrum – the same old with new words.

(Originally published by Lv Yi on June 23, 2019)

In this article, we shall look at the organization structure made of specialized feature teams, explore the dynamics around their backlogs, and then analyze the impact on agility and find levers to optimize for agility.

A feature team is responsible for delivering customer value from end to end. There is only one backlog associated with value delivery, i.e. the whole team shares the work and has one priority. In an organization, however, there are usually multiple feature teams, each having their own backlog. They are responsible for different customer domains, and that is why they are called specialized feature teams. Their backlogs contain mostly independent work.

More backlogs for efficiency

Let’s still ask the question of why having multiple backlogs for multiple feature teams. The answer again lies in efficiency thinking.

B1-loop: specialization for efficiency

This is the same loop as the one we have seen in the structure made of functional and component teams. There is an explicit or implicit efficiency goal. This causes an efficiency gap, leading to more backlogs, more specialization, higher efficiency, which reduces the gap.

With feature teams there is a different type of specialization. Instead of specializing in a function or a component, a feature team specializes in a customer domain. This creates a different impact.

The “unintended” impact on adaptability

Since feature teams can deliver customer value independently, having more backlogs won’t have direct impact on e2e cycle time. But there is an unintended impact on adaptability - ability to change direction.

In the upper part of the diagram, there are 3 causal links from the number of backlogs to adaptability.

1. More backlogs lead to lower transparency, less motivation to respond to change and lower adaptability.
2. More backlogs lead to stronger local identity, less motivation to respond to change and lower adaptability.
3. More backlogs lead to more specialization, narrower knowledge and lower adaptability.

All of them indicate that having more backlogs leads to lower adaptability.

For higher adaptability we need to:

1. Increase transparency so that we see the need to adapt
2. Reduce silos associated with local identity so that we are willing to adapt
3. Increase knowledge breadth so that we have the skill to adapt

Multi-learning for fewer backlogs

Let’s see how to drive toward fewer backlogs in the context of feature teams.

R1-loop: fewer backlogs drive broad learning

More backlogs lead to more specialization and narrower knowledge. The narrow knowledge, in turn, becomes the cause for more backlogs, thus creating a reinforcing R1-loop. It is easier to work in the direction of increasing the number of backlogs, how could we turn this around?

Take the same reinforcing loop and read it as follows: fewer backlogs, less specialization, broader knowledge, even fewer backlogs… The challenge is that less specialization does not lead to broader knowledge by itself. We need multi-learning to increase the knowledge breadth.

Fewer backlogs drive multi-learning; multi-learning enables fewer backlogs. They are mutually reinforcing. Therefore, the number of backlogs itself is an important lever - have one backlog for multiple feature teams.

The above analysis is exactly the same as the one for functional and component teams. What are the differences here? Here, the knowledge breadth is about customer domains, rather than functions or components. The backlog is product backlog, rather than functional or component backlog. The multi-learning is cross-domain learning, rather than cross-functional or cross-component learning.

What are the techniques for doing cross-domain learning? LeSS provides a guide about multi-team PBR. This is the key practice for any feature team to learn broadly about as many items as desirable from the same product backlog. In fact, when you start an adoption, it is recommended to do all-teams PBR by default, in order to maximize the learning. During multi-team PBR, instead of having different feature teams refine different items, we create mixed groups with people from different feature teams, and have them refine different items. They diverge and merge to get maximum cross-domain learning among feature teams sharing one product backlog.

In summary, the backlogs associated with feature teams are still there for efficiency. But the unintended impact is on adaptability, rather than e2e cycle time. Cross-domain learning enables fewer product backlogs, while fewer product backlogs in turn drives cross-domain learning.

Conclusion

Let’s conclude this series by putting various types of backlogs, specialization and multi-learning together.

The driver for having multiple various backlogs is the desire for higher efficiency through specialization. Teams specialize in different things: functions, components and customer domains. It creates different problems. Functional and component backlogs create dependencies for delivering customer value, thus, they have the most impact on e2e cycle time. While independent product backlogs for feature teams has the most impact on adaptability.

The key lever for all lies in multi-learning, though different types of multi-learning. Cross-functional learning enables fewer functional backlogs; cross-component learning enables fewer component backlogs; and cross-domain learning enables fewer product backlogs.

This ends the series about the number of backlogs and multi-learning.

(Originally published by Lv Yi on June 21, 2019)

In this article, we shall look at a variant of the functional team and component team structures - a feature group. We shall revisit known dynamics of the functional and component teams, and see what’s similar and different between them and a feature group in terms of impact on organizational agility.

A feature group is also called a feature project. It is usually formed to deliver some special customer value by picking people from various functional and component teams. Each member has their own work and priority, thus their own backlog. This is similar to the functional team and component team structure where all the work needed for value delivery is in multiple interdependent backlogs. The difference is who is responsible for specific backlogs, teams or individual members of a feature group.

Feature group

Let’s start with the diagram for a functional team and component team structure, and understand how it applies in the context of a feature group.

Individual responsibility

Members in a feature group take individual responsibility for either function or component, thus, they have multiple backlogs. Why?

B1-loop: specialization for efficiency

The functional or component specialization is good for efficiency. Except that now it is on members, rather than teams, but the same efficiency thinking applies.

This weakens the group’s common goal, and likely leads to the following dynamic.

R2-loop: Local identity hurts collaboration

Members still keep a strong local identity with their speciality. It hurts collaboration and leads to 1) increased integration effort, thus lower efficiency, and 2) increased integration time, thus longer e2e cycle time.

The feature group could reduce silo thinking by developing a common identity in addition to local identity. Something like: “You belong to this ‘team’ (feature group), nevertheless, you still do the work in your speciality only.”

Cycle time

In organizations with functional and component team structure, related parts may be done in different sprints, thus, the e2e cycle time could be several sprints long. However, the feature group should have the common goal of delivering customer value within the same sprint. In that case, the level of synchronization improves and waiting is confined to one sprint. The longest e2e cycle time would be one sprint. This also lessens the problem below .

R3-loop: Rework hurts efficiency

The rework caused by asynchrony still exists, but with improved level of synchronization, the resulting rework gets decreased.

Specialization

R1-loop: Over-specialization hurts collaboration

Over-specialization is still there when members have their own backlogs (B1-loop). The resulting narrow knowledge continues to hurt collaboration, and creates unintended impact on efficiency.

Besides, with dynamic requirements, the effort needed in various functions and components will change, which creates two more dynamics, shown as the additional R5 and R6 loops in the updated diagram.

As members have their own backlogs (B1-loop), the change on effort leads to:

1) Partial allocation

Some members will work in multiple feature groups with ensuing multi-tasking and associated context switching cost.

R5-loop: Multi-tasking hurts efficiency

More backlogs lead to more multi-tasking, which lowers efficiency. In other words, multi-tasking creates another unintended impact on efficiency.

2) Temporary group

Group members will change according to the amount of specialized work needed. Thus the group becomes a temporary group.

R6-loop: Group instability hurts collaboration

More backlogs lead to a less stable group. The feature group consists of people who are able to work on various backlogs. More backlogs, more changes the group is likely to endure. It takes time for any group to jell and become effective. Temporary groups tend to have low collaboration levels, and it is very hard to introduce and sustain any improvements. Thus, group instability creates another unintended impact on efficiency.

In summary, the feature group has the same main dynamics and problems as the functional and component teams with additional problems related to multi-tasking and group stability. However, a feature group may have a strong common goal of delivering customer value within the same sprint, and develop a common identity as a group. Therefore, it is usually better than no group at all, in terms of our goal for agility.

Feature team

To improve further on agility, having fewer backlogs in the feature group is a key lever. In fact, this is the main difference between a feature group and a feature team. A real feature team has only one backlog, and members take shared responsibility.

R4-loop: fewer backlogs drive broad learning

A feature team may also start with multiple implicit backlogs due to skills constraints. But one explicit backlog drives multi-learning and reduces the number of implicit backlogs over time. On the other hand, a feature group accepts the status quo and keeps multiple backlogs forever.

Having one backlog removes the need for partial allocation and temporary groups. With dynamic requirements, which is very common, the effort needed in various functions and components will still change, and there will still be a mismatch between work and skills. When that happens, we take advantage of it and trigger cross-functional and cross-component learning.

The same list of techniques for cross-functional and cross-component learning still applies.

• specification by example
• collective code ownership
• pair/mob programming
• communities of practice (both functions and components)
• component mentor
• current-architecture workshop
• multi-team design workshop

Multi-learning further enables fewer backlogs, until eventually achieving one backlog. By then, a feature group becomes a feature team.

(Originally published by Lv Yi on June 12, 2019)

In this article, we shall look at the structure of functional and component teams, explore the dynamics around their backlogs, analyze its impact on agility, and find the lever to optimize for agility.

A functional team is responsible for functional work such as analysis, design, implementation, and testing. Component team is responsible for the implementation of various technical components, such as component A, B and C. Each team has its own work and priority, thus, its own backlog. For overall value delivery, it means that the required work is in multiple backlogs which are dependent on one another.

More backlogs for efficiency

Let’s step back and first ask the question: why more backlogs? The answer lies in “efficiency thinking”.

B1-loop: specialization for efficiency

Organizations have either an explicit or implicit efficiency goal. The difference between this goal and reality causes an efficiency gap. Creating more backlogs, leads to specialization and, it theory, to higher efficiency, which reduces the gap.

Higher efficiency should also lead to shorter touch time (i.e. the time used to process the work in a function or a component), thus, shorter end-to-end cycle time. However, we need to understand what percentage touch time accounts for in the whole e2e cycle time, and to see a bigger picture.

The “unintended” impact on cycle time

Let’s see more factors having impact on cycle time.

In the upper part, more backlogs lead to more parts for integration, longer integration time, longer e2e cycle time.

In the lower part, more backlogs lead to lower level of synchronization (different parts are being worked on at different times), which leads to: 1) more rework, thus, more rework time, and 2) longer waiting time. In both cases, longer e2e cycle time.

Even though having more backlogs may lead to shorter touch time, other factors create negative effects on the whole cycle time. It is often the case that touch time is not the most significant part, while waiting and integration account for much more.

The “unintended” impact on efficiency

Let’s return to efficiency. As we analyzed earlier, it is the efficiency goal that drives toward more backlogs. Now we shall see the unintended impact on efficiency.

The level of collaboration is one commonly overlooked factor. A unit of work does not stand alone, but needs to be integrated with other units. Integration requires collaboration with others. Thus, the level of collaboration affects both time and efficiency. Let’s see which dynamics create negative effects on collaboration.

R1-loop: Over-specialization hurts collaboration

More specialization leads to deeper but narrower knowledge. The knowledge breadth is important for collaboration. In fact, the overlap in knowledge among collaborators helps a lot in mutual understanding. On one hand, narrow knowledge decreases efficiency, thus, creates the R1-loop. On the other hand, it creates more negative effects on integration time, leading to an even longer e2e cycle time.

R2-loop: Local identity hurts collaboration

More backlogs leads to stronger local identity, which means that one group only works on a specific function or component, while another group is not allowed to touch it. These are functional and component silos, and they hurt collaboration. This both decreases efficiency and worsens the integration time, thus even longer e2e cycle time.

Another dynamic comes from rework, which also creates a negative effect on efficiency.

R3-loop: Rework hurts efficiency

When work is done asynchronously, hidden problems are commonly discovered during integration and often require redoing parts that were considered complete. So, the rework caused by the asynchrony (i.e. low level of synchronization), which is caused by having different backlogs, decreases efficiency. This creates the R3-loop.

Overall, B1-loop aims to increase efficiency, but it creates unintended consequences on collaboration and rework and worsen the e2e cycle time. B1-loop and R1..R3-loop form the system archetype called “fixes that backfire”.

Multi-learning for fewer backlogs

Let’s see how to drive toward fewer backlogs.

R4-loop: fewer backlogs drive broad learning

More backlogs lead to more specialization and narrower knowledge. Then, the narrow knowledge becomes the cause for more backlogs creating a reinforcing R4-loop. It is easier to work in the direction of more backlogs. How could we turn this around?

Take the same reinforcing loop and read it like this: fewer backlogs, less specialization, broader knowledge, even fewer backlogs… The challenge is that less specialization does not lead to broader knowledge by itself. We need multi-learning to increase the knowledge breadth.

Fewer backlogs drives multi-learning; multi-learning enables fewer backlogs. They are mutually reinforcing. Therefore, the number of backlogs itself is an important lever - have one backlog by creating a real cross-functional and cross-component feature team.

What do we mean by multi-learning? The backlogs are based on functions and components here, thus, we do cross-functional and cross-component learning.

What are the techniques enabling cross-functional and cross-component learning? Below is a list of well-known techniques, and many of them are in LeSS guides:

• specification by example
• collective code ownership
• pair/mob programming
• communities of practice (both functions and components)
• component mentor
• current-architecture workshop
• multi-team design workshop

In summary, separate backlogs for functional and component teams are created for higher efficiency, but they create unintended negative impact on the overall e2e cycle time, and even worse, overall efficiency itself. Multi-learning enables fewer backlogs, while fewer backlogs in turn drives multi-learning and improves delivery capability.