Manager as Scrum Master

Note: This article was originally published as an experience report in Agile 2011.

Abstract

Manager as Scrum Master? You can not do that! It goes against the conventional wisdom, which assumes command and control managers cannot lead and coach as Scrum Masters. However, as an important aspect in Agile change, self-managing means a management transformation from command and control to leading and coaching. This experience report will explain how one large-scale organization adopted Agile over three years, with the focus on the evolution of Scrum Master and manager role and the way they work together. It describes how the change regarding self-management was introduced and adapted, then how we have tried to sustain the change by creating consistency between the values and principles behind Agile into the organization and the management capability to practice them.

Context

I worked in a product development organization in Nokia Siemens Networks, formerly Nokia Networks, from 2002 to 2010. The organization consists of two sites, one in Hangzhou, China, and the other in Espoo, Finland.

In late 2005, we started Scrum pilots in various projects and teams to get focus and flexibility in our projects. We were running parallel projects and the resulting multi-tasking caused people to lose focus. Because teams were organized around components, not customer deliverables, we had a diluted sense of customer focus. The combination of single functional team and component team structure made adapting to change in a flexible way difficult. Because of all these factors, both upper management and the teams were motivated to try different approaches to development, and the agile nature and simplicity of Scrum made it a natural choice to try. I led one of the first Scrum projects in the organization.

In 2007, after initial success in our pilots, our entire product organization (over 500 people) decided to move to an Agile/Scrum model. I was selected to lead one department with ~100 people in the new Scrum-based organization and join the organizational leadership team. The story is about how we have been inspecting and adapting on Scrum Masters, Line managers and how they work and grow together ever since then.

Introduce Self-managing

Many organizations failed to change product management, which is typically a separate organization from R&D. However, in our case, Product management is part of our product organization, with the same boss. We introduced a Product Owner role and created a PO-centered mode of operation. Since traditional project management is distributed among Scrum roles - PO, team and Scrum Master, we eliminated most project managers to avoid the dysfunctions due to overlapping roles. People managers didn't feel threatened with this change, since people management is still essential (if not more so) in an agile organization. Thus, it was relatively easy to get their support. The challenge was getting people managers to understand the deep change needed to transform their role from command and control to leader and coach.

The original department consisted of single-functional component teams, and we reformed them into cross-functional feature teams. There were a few line managers in the department but Scrum Master was a new role. Product Owner was selected for our department. My first task as department manager was to set up teams to enable Scrum development (i.e. cross-functional feature team committing and delivering potentially shippable product increments on sprint basis), and get Scrum Masters to lead and facilitate the team and Scrum implementation. Self-managing is one essential theme in Scrum. I intended to incorporate this principle into the change - could we reform the teams and select Scrum Masters via self-management?

We started by sketching the constraints we faced and decided that we needed an appropriate sized team that was cross-functional and able to deliver customer features. We educated our people in self-organization, and provided opportunities for them to know each other. Our Product Owner also shared the current Product Backlog, which indicated the needed competence from teams. During the planning, one concern was raised, what if it failed to self-organize into teams, how long would we wait for teams to emerge? We decided to timebox the team-forming process and explained this to the potential teams. If teams did not emerge within the timebox, then management would decide the team composition for them.

We invited all the potential team members into a team forming session. Around 80 people were in one big hall room. Flipchart stands were distributed within the room, each of which indicated one team presence. We listed main criteria on the flipchart. After some turbulence, some people started to gather around stands, and others joined to discuss about the criteria. People moved around. Some people who shared good early working experience started to form teams as initial members, and they even added their own criteria to recruit other members, some related to the technical, while others related to the social. The most interesting experience happened in the end. Some "leftover" people finally merged into the last team. I was worried about their future, however, it surprisingly turned out to be one of the best teams later. After one hectic hour, 10 teams formed.

I was thinking of going one step further to ask each team to select their Scrum Master, but did not implement this idea for the following reasons. Line managers were not familiar with Scrum. In order for the change to succeed, they certainly needed to understand Scrum deeply and know how to effectively work in that mode. Practicing as Scrum Master could be good approach to develop that understanding and get them immediately involved in the new mode. Secondly, our people did not yet have the sufficient understanding about what good Scrum Master should be like, and there were few real Scrum Masters in the organization. I was concerned about the quality of self-selected Scrum Masters, thus, decided to recruit Scrum Masters by myself and create a pool of candidate Scrum Masters including all line managers. After the teams formed, the Scrum Masters presented themselves to the teams. The teams and the Scrum Masters mutually agreed for which team the Scrum Master would serve.

One risk to have traditional line managers as Scrum Masters was the tendency of working via authority, rather than influence, by line managers and the perceived authority by team, which may impede the team from self-managing. We instituted a rule that line managers could not be the Scrum Master for the team directly under their line.

Since all line managers including myself were Scrum Masters at the same time, line managers and Scrum Masters, together with Product Owner, worked very closely at both team level and organizational level. The size of this group, less than 10 people, made the efficient work possible. We had grown our capability of leading and facilitating teams through practicing as Scrum Masters and learning from external coaches. Moreover, we had developed deep understanding about organizational impediments to be solved and organizational supports to be established.

Struggling and adaptation

We soon found that line managers struggled with balancing the roles of organizationally-centric role of line manager and the team-centric role of Scrum Master.

During the planning of the transition to Scrum, a hot topic was the role of a line manager in Scrum. The Product Owner decides what, the team decides how, and the Scrum Master supports and enables. In the beginning, some people in the organization were unclear about how the process was supposed to work, and skeptical about the change. Crisis and urgent escalations from customers demanded immediate attention with little room for mistakes; organizational impediments surfaced and demanded management solutions. Making the transition to self-management requires even more management efforts, and more leadership. The dual function of the line manger affected the progress at team level towards well-working self-managing team with continuous improvement, as well as at organization level towards enabling and aligning organizational structure and support.

We moved towards having dedicated Scrum Masters, and let line managers lead organizational change and coach Scrum Masters. Their early experience as Scrum Masters enabled line managers to take on a new role in the Scrum organization that was more outward looking. Line managers became more involved with removing organizational impediments and creating the vision and strategy in organizational evolution. Line managers also transitioned from command and control to coaching Scrum Masters. Some new Scrum Masters were recruited within the organization; others emerged from within teams; others were identified and developed by line managers.

In our organization, line managers had the responsibility of supporting personal development. Once people understood better about Scrum Master role, some of them showed interests of developing into it. In the meantime, line managers were looking for candidates to take over their Scrum Master role. It was a good match. Nevertheless, with the social culture of valuing getting into management position more than continuing to develop into technical experts, we actually encouraged people to stay focused on technical skill development. We made it clear that being Scrum Master is good for learning and growing leadership, but it is neither a position nor related to promotion. In fact, it would affect becoming a technical expert. Line managers paired with the remaining people, who would genuinely like to serve the team and help them become great, as well got the support from other team members. By recommending books and sharing thoughts after reading, coaching and mentoring in the context of the team to which they belonged, letting them facilitate Scrum meetings and giving feedback for improvement, line managers helped them get ready to start. The taking over happened when all parties including team felt comfortable in doing so.

When we had the mixed role of line manager and Scrum Master, we started with a peer group of both line managers and scrum masters. With the evolution towards having more dedicated Scrum Masters, a single group grew above the appropriate size for effective team work. Therefore, we decided to separate them into two groups. One consisted of line managers, whose focus was to specify the ends and create the environment for team to achieve; the other consisted of Scrum Masters (and line managers as optional members) whose focus was the competence development of Scrum Masters.

We made line managers optional in Scrum Master development groups. In addition to keeping the group size small, we thought that the line managers' presence might prevent Scrum Masters from taking the ownership for their own development. We made it clear that it was their platform and line managers would participate based on a pull mode.

We implemented Scrum buddies, pairing a line manager and a Scrum Master, to support coaching and mentoring within the organization. For new Scrum Masters, we also paired them with experienced Scrum Masters, considering that they would learn more from hands-on Scrum Masters, and experienced Scrum Masters would increase coaching and mentoring capability through practicing.

Sustaining

A downside of having two separate groups was the lack of opportunity for Scrum Master to get involved at the organizational level. A good Scrum Master in our organization not only looks at the team, Product owner, and their interactions, but also at the organization. For a Scrum Master's growth, we wanted them to understand the organization. In addition to the line manager's coaching that could be extended beyond the team context, we created workgroups based on organizational tasks, which would not only solve the problem but also grow Scrum Masters. Another downside came from line managers being separated from the teams compared to Scrum Masters, thus, weakening their understanding of the problems teams were facing.

Although we had positioned line manager as organizational centric role and Scrum Master as team centric role, we noticed that the line was sometimes blurred for some Scrum Masters/Line Managers. It made sense to develop the consistency among them for sustainability.

Our organization as well as our department grew. We increased the number of new line managers as well. Besides following the conventional management ratio (one line manager for 2-3 scrum teams), the selection of new line managers provided the opportunity to create sustainability in the change. Those Scrum Masters who had already demonstrated leadership in both team and organization contexts became a good source of candidates.

When they were selected as line managers, they continued to serve one of teams under their direct line as Scrum Master. This supplemented the line management team with good insights from teams. This seems as though we were back where we started, i.e. line managers were Scrum Masters. There were important differences, though. In the beginning of the Scrum transformation, the focus was to implement the change throughout the organization, including creating the vision, communication to get buy-in, removing impediments, etc. At this time, the focus was to sustain the change and ensure that it became part of the organization. The best way to do this is through the people, in particular those who have influence. With great Scrum Masters being promoted to line managers, it created more consistency between values and principles behind Scrum-based organization and management capability to practice them. As teams became more experienced in self-managing, the original challenge of balancing the line manager and Scrum Master roles became less of an issue.

With the growing number, the team of Scrum Masters with the learning focus has evolved into Community of Practice, i.e. Community of Scrum Master. It became less efficient to complete task with big number of people, thus we shifted focus further on growing ourselves into good Scrum Masters via exchanging ideas, sharing experiences, opening perspectives and providing insights. With the new purpose after adaptation, we extended Community of Scrum Master from our department to the whole organization. We set up the mailing group and regular gathering to support the community. We made a few arrangements to cultivate it. A few Scrum Masters and line managers acted as the role model for how to properly behave in the community; we handed out good books and encouraged the sharing after reading and group study; we introduced the internal community to the Scrum China community, thus connecting us to the outside; and so on. Over time, people developed the learning habit and got into self-growing stage. That's where sustainability comes from. Personal continuous improvement from Scrum Masters and line mangers led to the continuous improvement in teams and organization. Moreover, when they started to contribute in wide scope, it created positive reinforcing loop.

Summary

The initial drivers for more flexibility and better focus were addressed by creating customer-oriented product backlog and teams accordingly, so that we as organization deliver potentially shippable product increments in every sprint. We experimented how to lead self-managing teams in this context, and discovered the followings.

Successful change needs both vision and down-to-earth. Even though the ultimate state is less management efforts through self-managing, we should not underestimate the management efforts while introducing change; even though we desire for emergent Scrum Master in the long run, we'd better not start with self-selecting Scrum Master; and so on.

Sustainability comes from the consistency between organizational management with servant leadership and the self-managing teams. Although the conventional wisdom assumes a conflict between the focus of the manager on command and control and the Scrum Master on leading and coaching, and may suggest to separate these roles, this is questionable when thinking about creating sustainability. Without changing the organizational management, self-managing teams are more accidental. When managers change, the original conflict disappears.

Finally, sustainability comes from a change in people. Without most of the people making continuous improvement on their own, continuous improvement at team and organizational levels is unlikely.

Once a team responsible for "A" (be it a function, component or customer domain) grows too big, we split it into two teams, responsible for the subsets of "A" (the left side). Why is it so natural to do this, rather than the alternative - we split it into two teams, responsible for "A" together (the right side)?

 

individual responsibility.jpg

  

There are a few responses.

  1. we don't know why we do this, with the variants of "we have been doing this", "others are doing this", "is there any alternative", and etc.
  2. we want specialization by letting each team focus on one subset.
  3. we want clear responsibility by letting each team work on one subset.

I don't know what to do with the 1st response, and I have explored the 2nd response in the series of "Number of backlogs and multi-learning". This article is for the 3rd response.

 

Mental model

The iceberg model is a systems thinking tool. It helps progress our thinking from the obvious event to the patterns of behavior, to its supporting structures, and its underlying mental models. The below diagram is from Michael Goodman's original article that introduced the iceberg model. In other places, mental models may also be illustrated as a separate deeper layer. 

the-goodman-iceberg-model.png 

For the topic of specialization, we explored mainly the structure, but mental models, such as "people can or can't learn", were also implied there.

Now look at the topic of responsibility, is the mental model here that "clear responsibility is necessary"? It is hard to dispute about this. Who wants its opposite - unclear responsibility? However, when two teams are responsible for "A" together, is the responsibility unclear? Not really, it is not unclear, but shared. What is the opposite of shared responsibility? it is individual responsibility. The response is actually that "we want individual responsibility" in disguise. The mental model is really that "individual responsibility is necessary".

Why do we want individual responsibility? Because we assume that shared responsibility means no responsibility. When something goes wrong, shared responsibility makes is difficult to find someone accountable, so as to blame or even fire him. By contrast, individual responsibility makes it more "clear".

However, the sole focus on its responsible part leads to strong local identity, and eventually silo mentality. Many people say that they hate silo, but the love for "clear" responsibility in fact helped create it in the first place. Maybe we don't really hate silo, do we?

 

From Individual responsibility to Shared responsibility

I purposefully make individual unclear - be it individual person or individual team. The underlying thinking is the same. We need to improve our mental model from "individual responsibility is necessary" to "shared responsibility could work, and even better."

This happens in Scrum adoption. One-team Scrum breaks down individual responsibility on the individual members, and defines shared responsibility on the team instead. The team takes shared responsibility towards its common goal. While individual responsibility makes it easier to hold someone accountable, it doesn't make the group a real team working towards a common goal. Individual responsibility creates silos in the group, and leads to local optimization.

This happens in LeSS adoption too. LeSS - aka multi-team Scrum - breaks down individual responsibility on the individual teams, and defines shared responsibility on the product instead. Multiple teams take shared responsibility towards their common goal. It has the same logic as one-team Scrum. This should not be surprising, as LeSS is Scrum.

The shift in this mental model happens at two levels - one-team (Scrum) and multi-team (LeSS), but they are essentially the same shift.

 

Espoused theory vs. Theory-in-use

Espoused theory is reflected by what we say; while theory-in-use is reflected by what we do. We realize the gap through the discipline of mental models.

When we let the whole team take shared responsibility in adopting Scrum, that is our espoused theory. When we still define clear responsibility for individual members and hold them accountable for their own parts accordingly, we have a different theory-in-use.

When we have already let individual team take shared responsibility, but fail to take it into the next level, i.e. multiple teams take shared responsibility on one product through shared product backlog and shared product increment, there is still a gap between espoused theory and theory-in-use.

The gap is not necessarily bad. When we realize the gap, we ask ourselves - do we really value the espoused theory? If yes, then the gap represents the tension between reality and our vision, so as to help create the path of least resistance. If no, then the gap is not real. As there is no commitment to the espoused theory, we will only manipulate the gap but fail to achieve our vision.

Reasoning before measuring

I often got this question - what do you measure while adopting Agile?

The conversation usually went like this:

[me] What is about adopting Agile?
[him] ... doing Scrum.
[me] What effect do you expect after adopting Agile?
[him] higher efficiency.
[me] How would you define higher efficiency?
[him] ... finishing more tasks.
[me] Why would adopting Agile lead to higher efficiency?
[him] Agile means higher efficiency, doesn't it?!

The thinking is fuzzy, to say the least. I suggest to focus on reasoning before measuring.

Let's take Specification by Example (SbE) as one example of agile practices. What do you measure while adopting SbE?

Practice and Purpose

Firstly, we learn about SbE by asking 1) what is SbE; and 2) why SbE.

A good source of learning is of course the book "Specification by Example".

1) What is SbE?

"Specification by Example is a set of process patterns that facilitate change in software products to ensure the right product is delivered effectively."

Blog - reasoning before measuring.png

Suppose that among those process patterns, the below two are our main focus of initial adoption. We dive deep on them.

  • Specifying collaboratively

"Instead of relying on a single person to get the specifications right in isolation, successful delivery teams collaborate with the business users to specify the solution."

  • Illustrating using examples

"The team works with the business users to identify key examples that describe the expected functionality. During this process, developers and testers often suggest additional examples that illustrate edge cases or address areas of the system that are particularly problematic."

2) Why SbE?

There are various benefits from the whole set of SbE process patterns. Let's focus on the benefits from "Specifying collaboratively" and "Illustrating using examples". In other words, let's understand the purposes of these two specific practices.

"Specification by Example helps to improve the quality of software products, significantly reduces rework, and enables teams to better align analysis, development, and testing activities."

There are three areas of benefits.

  • Higher product quality

"Specification by Example improves collaboration between delivery team members, facilitates better engagement with business users, and provides clear objective targets for delivery - leading to big improvement in product quality."

  • Less rework

"Specification by Example helps teams establish a collaborative specification process that lowers problems in the middle of an iteration. Most teams have significantly reduced or completely eliminated rework that occurred as a result of misunderstood requirements or neglected customer expectations."

  • Better work alignment

"Specification by Example enables tams to clearly define a target that's universally understood and objectively measured. As a result, many teams find that their analysis, development, and testing activities became better aligned."

The above reasoning could be summarized as below.

Blog - reasoning before measuring - 1.jpg

Only then do we go to the measuring part.

"Practice has purpose, and we measure both the practice and the purpose." I learned this in one private workshop by David Hussman for Odd-e in 2013 - one of the most memorable experiences with "the dude".

We may come up with the following measures.

  1. For the practice
    • %stories done with SbE (measuring the extent of doing SbE)
    • %stories with cross-functional conversations (measuring the extent of specifying collaboratively)
    • %stories specified with examples (measuring the extent of illustrating using examples)
  2. For the purpose
    • #defects due to misunderstood/neglected requirements after done (measuring product quality)
    • #defects due to misunderstood/neglected requirements during the sprint (measuring rework)
    • %stories reaching completion at the end of the sprint (measuring work alignment)

Causal Diagram

In the "The Book of Why", it introduces causal diagram to move from the correlation to the causation. Causal diagram is similar to causal loop diagram in systems thinking, as they both are based on the causation.

After understanding the practice and the purpose, we reason further for finer-grained causation by expanding with the intermediates. Why doing SbE leading to higher product quality, less rework and better work alignment?

The below causal diagram illustrates one reasoning.

Blog - reasoning before measuring - 2.jpg


Then, we measure the intermediates, so as to learn the whole chain of causation via validation or invalidation. Note that some variables are harder to measure than others. For example, "amount of rework" is harder to measure than "internal defects". We don't have to measure all the variables. With a few intermediate ones, we build our confidence in this causation.

We may end up with measuring:

  • %stories of doing SbE (i.e. specifying collaboratively and illustrating using examples)
  • #internal defects during the sprint
  • #external defects after done
  • %story completion at the end of the sprint

 

Conclusion

We reason about the cause and effect, before getting to the measure. On the other hand, measuring also improves our reasoning in two senses - 1) thinking about how to measure increases the rigor in the reasoning; 2) the measuring result validates or invalidates the reasoning.

Notice that measuring here is for learning and improving. See my previous blog "Two Guidelines for Metrics" for further reference.

How does LeSS optimize organizational ability to learn?

In my previous series of article "#backlogs and multi-learning", I wrote that "the agility is to deliver highest customer value in uncertain environment. With uncertainty, the ability to deliver is not sufficient, we need the ability to inspect and adapt, in order to deliver highest customer value". Inspect, adapt and deliver is the essential cycle. 

#backlogs and multi-learning - inspect-adapt-deliver.png

To achieve higher agility, we need to optimize for inspectability, adaptability and deliverability. LeSS optimizes adaptability via one product backlog; LeSS optimizes deliverability in terms of end-to-end cycle time via feature team; then, how does LeSS optimize inspectability, i.e. organizational ability to learn?

I have been pondering on this question for a while. In the "fifth discipline" book, there are three disciplines closely related to learning - team learning, mental model and systems thinking. I try to look for insights from them.

Scrum/LeSS has built-in events for product learning and process learning in the sprint cycle. Therefore, let's look at product learning and process learning separately.

Product learning

The most related event to product learning is sprint review. In Scrum, during sprint review, team, PO and stakeholders including users and customers together inspect the current product increment and explore the ideas for improving the product further. In LeSS, with the whole-product focus, there is one sprint review for all teams. Review bazaar is the recommended practice for the joint sprint review.

The sprint review institutionalizes the discipline of team learning - for product learning. Furthermore, in order to deepen the learning, we also need the other two disciplines - mental model and systems thinking.

Lean startup popularizes the concept of validated learning. First make hypothesis, then design experiment to test core assumptions, then learn from the validation or invalidation. This reflects the discipline of mental model. We make our mental models explicit while making hypothesis, so as to examine and improve them both before and after running the experiments.

Impact mapping shows the logic connection between product goal and features. It explicitly asks to expand the view - who else and how else would impact the goal? This reflects the discipline of systems thinking - in the space dimension. Unfortunately, impact mapping does not highlight the time dimension, i.e. short-term vs. long-term impact. 

Business seeks for growth and product needs growth engine. This is the reinforcing loop. The growth is inevitably limited by certain factors. This is the "limits to growth" system archetype. I could see the merits in applying systems thinking in the product domain, but I have rarely seen its comprehensive application - through the explicit use of systems thinking tools such as behavior-over-time, causal-loop diagram, stock&flow diagram, computer simulation - in the field. It is worth experimenting to leverage its potential.

Process learning

The most related event to process learning is sprint retrospective. In Scrum, during sprint retrospective, team and PO reflect on way of working and strive for improvement. In LeSS, besides team retrospective (i.e. team does the sprint retrospective on their own), team representatives, PO, SMs and managers will have an additional overall retrospective, which has the focus on improving systems.

The sprint retrospective - both team retrospective and overall retrospective - institutionalizes the discipline of team learning - for process learning. Same as in product learning, in order to deepen the learning, we also need the other two disciplines - mental model and systems thinking.

There is a LeSS guide called "improving the system". It explicitly recommends doing systems modeling to understand the system and have a conversation to reach shared understanding. As overall retrospective has the systemic focus, applying systems thinking there is a natural fit.

In fact, every improvement action is an experiment. We first model to make our logic behind the experiment explicit for critical thinking. While modeling, the whole team practices "balancing advocacy and inquiry", and exposes different mental models. We examine those underlying assumptions via "the ladder of inference", and improve them via reflection. Then, we return to our model and learn more after running the experiment. This is the combination of systems thinking, mental model and team learning.

Conclusion

I find that there are many similarities in product and process learning, when they are elevated into higher abstract level.

Every feature is an experiment; every improvement action is an experiment. Therefore, we make hypothesis (i.e. make the logic explicit) for critical thinking; we balance advocacy and inquiry with the whole team; we examine mental models and reflect with actual result to improve them.

In short, we aim for double-loop learning, rather than single-loop learning, for both product and process, via practicing systems thinking, mental model and team learning.

LeSS before Scrum?

The discussion in this article assumes that we apply Scrum in large-scale (i.e. multi-team) product development, which is probably 90% of cases.

Scrum adoption

Scrum implies the change in organization design. The star model by Jay Galbraith defines five aspects of organization design.

Scrum education - star model.jpg

Let's put Scrum in the context of organization design.

  • In "strategy", Scrum is designed to achieve speed and flexibility.
  • In "structure", cross-functional team able to deliver customer value from end to end is the basic organization unit.
  • In "processes", value is delivered in sprints, which defines the planning, review and retrospective cycle.
  • In "rewards", team is jointly accountable for the result.
  • In "people", team members learn to become multi-specialists.

While the change may be trivial in one-team organization, it is significant in large-scale organization.

When there is lack of proper organization design, Scrum adoption falters. Richard Hackman in his classical book "Leading Teams" showed how team design and coaching jointly affected team performance. 

Scrum education - team design vs coaching.jpg

When team is poorly designed, the coaching only has limited effect. On the other hand, when team is well designed, its performance would not be too bad, even with ineffective coaching. This provides room to gradually improve coaching effectiveness.

LeSS provides the guide on the necessary organization design to enable Scrum in large-scale organization. LeSS is the Scrum enabler. Therefore, first adopt LeSS to design the organization, then coaching for those well-designed teams. This is the organization-first approach.

Even LeSS without Scrum provides benefit, actually more than Scrum without LeSS, in large-scale organization. See more insights from LeSS without Scrum experience report.

Therefore, here is an experiment for Scrum/LeSS adoption: LeSS before Scrum (rather than first Scrum, then LeSS).

Scrum education

CSM is probably the most popular Scrum course, and many people learn about Scrum from it. The CSM focuses on one-team context, and treats scaling as more advanced topic. This leads to various educational paths.

Before Scrum Alliance introduced A-CSM, I had my own version of Advanced SM course. It consisted of two days, day one on organization design and day two on coaching. The course design was targeted for large-scale context, and built on Richard Hackman's work - team design and coaching jointly affect team performance. In large-scale context, organization design becomes the first-order factor, thus it is essential for SM to learn about it. Later, Scrum Alliance introduced A-CSM and scaling is part of its content.

The more scaling-focused educational option would be attending CLB or CLP after CSM. CLB is 1-day overview on LeSS, while CLP is 3-day deep-dive on LeSS. For people working in large-scale organization to learn about Scrum, it is also recommended to attend the 2-day CSM plus 1-day CLB. Regardless, the underlying thinking behind those options is all the same, first learn about Scrum then scaling.

Scrum education - csm before clp.jpg

However, there is a potentially fundamental flaw. For people working in large-scale organization, only learning about Scrum in one-team context is simply not sufficient. They get confused and fail miserably after going back to apply Scrum in their organization, because the existing organization design is not supportive for Scrum. Therefore, we need better approach on Scrum education in large-scale context.

A while ago, Michael James started to offer 3-day CSM/CLB mixed together. The mixed CSM/CLB does not separate CSM and CLB. Scrum is not something you learn first, while LeSS not as more advanced topic. In order to do one-team Scrum well in large-scale context, the organization design in LeSS is a necessary enabler, thus, must be taught and learned as an essential part. In fact, after teaching CSM for 10+ years, I have stopped doing it, and put my focus on doing CLP. However, I would seriously consider trying the mixed CSM/CLB course.

How about CLP before CSM? LeSS is Scrum, thus it seems illogical to learn in this sequence. However, if we could teach LeSS without Scrum, i.e. extract the part of organization design from LeSS, it isn't that illogical, is it?

Scrum education - clp before csm.jpg

Therefore, here is an experiment for Scrum/LeSS education: LeSS before Scrum (rather than first Scrum, then LeSS).

 

The path of least resistance towards one backlog

How could we create a path of least resistance towards one backlog?

A collection of multiple backlogs is NOT one backlog

Assuming that multiple teams are working on the same product, the below is a typical conversation between me and my fellow, who may be a friend in the community, a client in the organization or a student in the class.

[me] do you have one product backlog?

[fellow] yes, we do.

[me] how do you create this one backlog?

[fellow] we collect every team's backlog to make one backlog.

This is NOT one product backlog, but a collection of multiple product backlogs. They are not the same thing, as one product backlog means to prioritize as a whole, while a collection means to prioritize separately.

Accommodate constraint in actual backlog

[fellow] but, if we prioritize as a whole, we will find that some teams may need to work on domains that they are not familiar with. Though we desire for one backlog, we currently still have constraint.

[me] so then?

[fellow] we have to take our constraint into account when creating the actual backlog.

That way, the collection becomes the actual one backlog. In this solution, we accommodate the constraint in creating actual backlog, and further regard it as desired. It is illustrated by B1-loop in the below diagram. 

the path of least resistance towards one backlog - 1.jpg

Meanwhile, as the tension caused by the gap between desired backlog and actual backlog goes away, the fundamental solution of removing the constraint, illustrated by B2-loop, does not move forward. Thus, the constraint will stay forever. This creates the dynamic of "eroding goals".

Maintain desired backlog to keep tension

[fellow] what to do instead?

[me] maintain the desired backlog, so as to keep the tension

Let's maintain two backlogs - desired backlog and actual backlog, so that the tension is kept. This avoids "eroding goals" and creates the path of least resistance towards one backlog.

the path of least resistance towards one backlog - 2.jpg

One backlog for one team

The same dynamic may exist in one-team context too, though rarer than in multi-team context.

Sometimes, we may accommodate the constraint from team members in creating actual backlog, and mistake it as desired backlog.

In that case, maintaining the unconstrained desired backlog keeps the tension, thus creates the path of least resistance towards the real one backlog for one team.

The path of least resistance

Here are some further thoughts on the path of least resistance.

1. Personal vision

In fact, the path of least resistance is the name of a book about personal mastery, which is one of the five disciplines for organizational learning.

What do you want to create? That is your personal vision. The gap between the personal vision and the current reality provides creative tension, thus creates the path of least resistance.

2. Organizational vision

Not surprisingly, another discipline for organizational learning is shared vision. What does organization want to create? The resulting creative tension creates the path of least resistance too.

This is also similar to what I wrote in the article of "from change resistance to limits to growth" - create the common goal to be higher than status quo, in order to avoid the change resistance.

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

#backlogs and multi-learning - article 4.png

Feature team is responsible for delivering customer value from end to end, thus, there is only one backlog associated with value delivery, i.e. the whole team shares the work and one priority. However, for the organization, there are multiple feature teams, each having its own backlog. They are responsible for different customer domains, thus, specialized feature teams. Those work in different backlogs are independent of one another.

More backlogs for efficiency

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

#backlogs and multi-learning - article 4.1.jpg

B1-loop: specialization for efficiency

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

However, here is a different type of specialization. Instead of specializing on function for functional team and on component for component team, feature team specializes on customer domain. This creates the different impact.

The "unintended" impact on adaptability

As feature team can deliver customer value independently, thus, having more backlogs won't have direct impact on e2e cycle time. The unintended impact is on adaptability.

#backlogs and multi-learning - article 4.2.jpg

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

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

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

In order 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.

#backlogs and multi-learning - article 4.3.jpg

R1-loop: fewer backlogs drives broad learning

More backlogs, more specialization, narrower knowledge breadth. Then, the narrow knowledge breadth becomes the cause for more backlogs, and it creates a reinforcing R1-loop. It is easier to work in the direction of more backlogs, how could we turn this around?

Take the same reinforcing loop and make it like this - fewer backlogs, less specialization, broader knowledge breadth, 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 for multiple feature teams.

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

What are the techniques to do 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 the adoption, it is recommended to do all-team 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 the maximum cross-domain learning among those feature teams sharing one product backlog.

In summary, the associated backlogs in feature teams are still for efficiency, but it creates unintended impact 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.

#backlogs and multi-learning - article 4.4.jpg

The drive behind having various backlogs is higher efficiency through specialization. They specialize on different things - function, component and customer domain. They create different problems. Functional backlog and component backlog create dependency among them for delivering customer value, thus, they have the most impact on e2e cycle time. While product backlog is independent of one another, it has the most impact on adaptability.

The key lever all lies at 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 - number of backlogs and multi-learning.

Number of backlogs and multi-learning: 3) feature group

In this article, we shall look at a variant of the functional team and component team structure - feature group. We shall revisit the dynamics with functional team and component team, and see how much similarity and difference feature group has with them, in terms of its impact on the agility and the lever. 

#backlogs and multi-learning - article 3.png

Feature group is also called feature project. It is formed to deliver customer value, consisting of people from various functional and component teams. Each member has its own work and priority, thus its own backlog. Same as the functional team and component team structure, for the value delivery, it requires the work in multiple backlogs, and they are dependent on one another. The difference between them is on whether those backlogs are responsible by functional team and component team, or by functional members and component members in the group.

Feature group

Let's start from the same diagram for the functional team and component team structure, and understand how it applies in the context of feature group.

Thumbnail image for #backlogs and multi-learning - article 2.4.jpg

Individual responsibility

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

B1-loop: specialization for efficiency

The functional or component specialization is good for efficiency. It is now 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 strong local identity for their functions or components. This hurts collaboration, which leads to 1) increase integration effort, thus lower efficiency; 2) increase integration time, thus longer e2e cycle time.

The feature group could lessen the silo thinking, as the group may develop a common identity in addition to local identity, something like this - "you belong to this 'team' (feature group), nevertheless, you still do the work in your speciality only."

Cycle time

In the structure of functional team and component team, the related parts may be done at 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, then, waiting is confined to a sprint. The longest e2e cycle time would be a sprint. This also lessens the below problem.

R3-loop: Rework hurts efficiency

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

Specialization

R1-loop: Over-specialization hurts collaboration

Over-specialization does not get fixed when members have their own backlogs (B1-loop). The resulting narrow knowledge breadth continues to hurt collaboration, and creates unintended impact on efficiency.


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

Thumbnail image for #backlogs and multi-learning - article 3.2.jpg

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, then multi-tasking ensues.

R5-loop: Multi-tasking hurts efficiency

More backlogs leads to more multi-tasking, then lower efficiency. The multi-tasking creates another unintended impact on efficiency.

2) Temporary group

Group members will change accordingly, thus the group becomes temporary.

R6-loop: Group instability hurts collaboration

More backlogs leads to less stable group. The feature group consists of people who are able to work on various backlogs. The more backlogs, the more change the group composition endures. It takes time for the group to jell and become effective. Temporary group hurts collaboration, and is hard to sustain the improvement. The group instability creates another unintended impact on efficiency.

In summary, the main dynamics and problems with functional team and component team remain with feature group. However, feature group may have a 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 feature group and feature team. The real feature team has only one backlog, and members take shared responsibility.

R4-loop: fewer backlogs drives broad learning

Feature team may also start with multiple implicit backlogs due to the skill constraints, but by having one explicit backlog, it drives multi-learning and reduces the number of implicit backlogs over time. On the contrary, feature group accepts the status quo and keeps multiple backlogs forever.

Having one backlog removes the need for partial allocation and temporary group. With the dynamic requirements, the needed effort in various functions and components will still change, and there will be mismatch between the work and the skill. 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 practices (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, feature group becomes feature team.

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

#backlogs and multi-learning - article 2.png

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

More backlogs for efficiency

Let's step back and first ask the question of why having more backlogs. The answer lies at the efficiency thinking.

#backlogs and multi-learning - article 2.1.jpg

B1-loop: specialization for efficiency

There is an explicit or implicit efficiency goal. This causes efficiency gap, leading to more backlogs, more specialization, higher efficiency, which reduces the gap.

Relatedly, higher efficiency leads to shorter touch time (i.e. the time used to process the work in function or component), thus, shorter cycle time. However, we need to understand how much percentage touch time accounts for in the whole e2e cycle time, and see the bigger picture.

The "unintended" impact on cycle time

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

#backlogs and multi-learning - article 2.2.jpg

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

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

Even though having more backlogs may lead to shorter touch time, many 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. Then, overall, more backlogs leads to longer e2e cycle time.

The "unintended" impact on efficiency

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

#backlogs and multi-learning - article 2.3.jpg

Level of collaboration is the commonly overlooked factor. The unit does not stand alone, but needs to integrate with other units. The integration requires to collaborate with others, thus, the level of collaboration affects both time and efficiency. Let's see a few dynamics that create negative effects on collaboration.

R1-loop: Over-specialization hurts collaboration

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

R2-loop: Local identity hurts collaboration

More backlogs leads to stronger local identity, which means that our group only works on this function or component, as well as other group is not allowed to touch it. These are functional and component silos, and they hurt collaboration. This both decreases efficiency, thus creates R2-loop and worsens the integration time, thus even longer e2e cycle time.

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

R3-loop: Rework hurts efficiency

The rework caused by the asynchrony (i.e. low level of synchronization), which is caused by having different backlogs, decreases efficiency. This creates R3-loop.

Overall, B1-loop aims to increase efficiency, while it creates unintended consequence on collaboration and rework. B1-loop and R1..R3-loop form the system archetype of "fixes that backfire". In the meantime, these effects on collaboration and rework worsen the e2e cycle time.

Multi-learning for fewer backlogs

Let's see how to drive toward fewer backlogs.

#backlogs and multi-learning - article 2.4.jpg

R4-loop: fewer backlogs drives broad learning

More backlogs, more specialization, narrower knowledge breadth. Then, the narrow knowledge breadth becomes the cause for more backlogs, and it creates 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 make it like this - fewer backlogs, less specialization, broader knowledge breadth, 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 multi-learn? The backlogs are based on functions and components here, thus, we do cross-functional and cross-component learning.

What are the techniques to do cross-functional and cross-component learning? The 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 practices (both functions and components)
  • component mentor
  • current-architecture workshop
  • multi-team design workshop

In summary, the associated backlogs in functional and component teams are for efficiency, but they create unintended impact on e2e cycle time, and even worse, the efficiency as well. Multi-learning enables fewer backlogs, while fewer backlogs in turn drives multi-learning.

This is the first article in a series about "number of backlogs and multi-learning".

Goal for Agility

Let's first set the stage for our analysis by clarifying the system optimizing goal. The goal is to optimize for agility.

The agility is to deliver highest customer value in uncertain environment. With uncertainty, the ability to deliver is not sufficient, we need the ability to inspect and adapt, in order to deliver highest customer value.

We may inspect and find that market changes, then, we embrace the change and make the necessary adaptation, then deliver the value. We may deliver our initial idea, then, we inspect the feedback, then adapt by acting on the feedback.

Here is the essential cycle to illustrate.

#backlogs and multi-learning - inspect-adapt-deliver.png

  • Inspectability

The ability to inspect is the ability to learn. Learn the market and customers, learn the feedback, and analyze to gain the insights.

  • Adaptability

The ability to adapt is the ability to change the direction. Embrace the change and decide the next appropriate step - either refine it or make a pivot.

  • Deliverability

The ability to deliver is associated with e2e/end-to-end cycle time. Deliver customer value now; or deliver to learn now so as to deliver more value later.

To optimize for agility, we optimize for either of them or all of them.

Backlogs with various teams

There are various team structures in product development organizations. Let's see different backlogs associated with them.

  1. Functional team and component team

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

#backlogs and multi-learning - functional team and component team.png

In the above picture, each box is either a functional team or a component team, and each team has its own backlog (i.e. 6 backlogs in total). In the second article, we shall analyze its impact on the agility and find the lever to optimize for the agility.

  1. Feature group

Feature group is also called feature project. This is directly connected to the structure of functional team and component team, thus, more as a variant. Project group is formed to deliver customer value, consisting of people from various functional and component teams. Each member has its own work and priority, thus its own backlog. Same as the first structure, for the value delivery, it requires the work in multiple backlogs, and they are dependent on one another.

#backlogs and multi-learning - feature group.png

The above picture is actually the same as the one for functional team and component team, except each box now is either a functional member or a component member, and each member has its own backlog (i.e. 6 backlogs in total). It is likely that multiple members share one backlog for certain function or component, but the structure remains the same. In the third article, we shall revisit the dynamics with functional team and component team, and see how much similarity and difference feature group has with them, in terms of its impact on the agility and the lever.

  1. Specialized feature team

Feature team is responsible for delivering customer value from end to end, thus, there is only one backlog associated with value delivery, i.e. the whole team shares the work and one priority. However, for the organization, there are multiple feature teams, each having its own backlog. They are responsible for different customer domains, thus, specialized feature teams. Those work in different backlogs are independent of one another.

#backlogs and multi-learning - specialized feature team.png

In the above picture, each box is a feature team, and each team has its own backlog (i.e. 3 backlogs in total). In the fourth article, we shall analyze its impact on the agility and find the lever to optimize for the agility.

Here are all four articles in this series.

  1. see the backlogs
  2. functional and component team
  3. feature group
  4. specialized feature team

 

Recent Comments

  • lee: ya good thinking read more
  • Lv Yi: The key difference between them is the purpose. MVP may read more
  • Chen Gang: Clear introduction. BTW, do you mean the key difference between read more
  • Jacky Shen: A complicated organization may result to "contract game" & "content read more
  • Lifen: Very glad to see your new post. Just a few read more
  • He Bing: IMHO, the knowledge composition is typically related to role, but read more
  • Lifen: I did experienced the period of wearing this two hats. read more
  • https://www.google.com/accounts/o8/id?id=AItOawmNYfpsk6pL7pHr1A6_rEDt5CYSG_nX6Fg: PO on feature reminds me of companies new to Scrum read more
  • He Mian: What is the new responsibility of the line managers. - read more
  • Vineet Shukla: Hi Yi, We share same views on long lived team read more

Recent Assets

  • individual responsibility.jpg
  • the-goodman-iceberg-model.png
  • Blog - reasoning before measuring - 2.jpg
  • Blog - reasoning before measuring - 1.jpg
  • Blog - reasoning before measuring.png
  • Scrum education - clp before csm.jpg
  • Scrum education - csm before clp.jpg
  • Scrum education - team design vs coaching.jpg
  • Scrum education - star model.jpg
  • the path of least resistance towards one backlog - 2.jpg