This is an ad-hoc post written out of pure frustration with many so-called AGILE adoptions.
Everywhere I go, new fancy names get adopted for old concepts without any behavioral change. The most common is a mixture of Scrum terms and “spotify model” terms. It would be good if the adoption of a new idea came with a new word that describes that idea… but unfortunately, many agile adoptions adopted only the word agile.
On my desk, I have a translation manual for an organization I’m working with right now. It reads,
Tribe -> Department
Product Owner -> Outwards Project Manager
Scrum Master -> Inwards Project Manager
etc.
Why do organizations do this? My best good-intentions guess is that it is forced through the throat of most people in the organization by a well-intended yet naive manager who at least temporarily was enthusiastic about some new concept. Unfortunately, the adoption of the new concept was too short and too broad, leaving only words. Often the initiator of the change is so far away from the actual work that (s)he is unaware of the non-adoption as people use the right words.
This playing with words doesn’t only cause confusion and demotivation but is also harmful. Perhaps the fancy word that annoys me most is “squad” as that word didn’t even bring a new concept but was truly just a rename of the word “team.” WHY!?!? Is it because we have a preference for military originated words? Do we like that this word is also used in e.g. firing squad? The adoption of the word squad has been a puzzle for me. But this also causes harm as adopting a meaningless word for an existing concept makes it harder to learn more about that concept. Ironically, my Amazon search on “improving squads” led me to a book called “the cheerleaders.” Perhaps the books “group dynamics for squads, “coaching squads”, and “squadwork” are being written now? (I’m also waiting for Microsoft Squads).
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 following is a typical conversation between me and a friend in the community or a client in an organization or a student in my class.
[me] Do you have one product backlog?
[friend] Yes, we do.
[me] How do you create this one backlog?
[friend] 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.
Accommodating constraint in actual backlog
[friend] But, if we prioritize as a whole, we will find that some teams may need to work in domains that they are not familiar with. Though we wish to have one backlog, we currently still have that constraint.
[me] So then?
[friend] 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 when creating the actual backlog, and further consider it as the desired backlog. It is illustrated by the B1-loop in the following diagram.
[Note: The meaning of “value in desired backlog” and “value in actual backlog” is the prospective value that may be obtained by delivering those items in the backlog.]
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 “eroding goals” dynamic. For more information, please refer to “Drifting goals: the ‘boiled frog’ syndrome”.
Maintaining desired backlog to keep tension
[friend] What to do instead?
[me] Maintain the desired backlog in order 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.
One backlog for one team
The same dynamic may exist in one-team context too, though it is rarer than in multi-team context.
Sometimes we may accommodate the constraint from team members when creating the actual backlog and mistake it for the desired backlog.
In that case, maintaining the unconstrained desired backlog keeps the tension, thus creating 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 creating the path of least resistance.
2. Organizational vision
Not surprisingly, another discipline for organizational learning is shared vision. What does an organization want to create? The resulting creative tension creates the path of least resistance too.
This is similar to what I wrote in the article “from change resistance to limits to growth” – create the common goal to be higher than status quo, in order to avoid the change resistance.
I often get this question – what do you measure while adopting Agile?
The conversation usually goes like this:
[me] What is it 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 an example of a concrete agile practice. What do you measure while adopting SbE?
Practice and Purpose
Firstly, we learn about SbE by asking 1) what is SbE, and 2) why do SbE ?
“Specification by Example is a set of process patterns that facilitate change in software products to ensure the right product is delivered effectively.”
Suppose that among those process patterns, we choose to focus on the below two at the beginning of our initial adoption. We dive deeper into 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 do 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 teams 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:
Only after getting this clarity we can go to the measuring part.
“Practice has purpose, and we measure both the practice and the purpose.” I learned this from David Hussman in a private workshop for Odd-e in 2013 – one of the most memorable experiences with “the dude”.
We may come up with the following measures.
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)
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
“The Book of Why” introduces causal diagrams as a tool to move from correlation to causation. Causal diagrams are similar to causal loop diagrams in systems thinking – they are both based on causation.
After some understanding of the practice and the purpose, we can reason further with finer-grained causation chain by identifying intermediate steps. Why does SbE lead to higher product quality, less rework and better work alignment?
The below causal diagram illustrates our reasoning.
Then, we can measure the intermediate steps, 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 need to reason about causes and effects, before getting into measures. On the other hand, measuring can also improve our reasoning in two senses: 1) thinking about how to measure increases the rigor in the reasoning, and 2) measurement results validate or invalidate the reasoning.
Notice that measuring here is for learning and improving. See my previous blog “Two Guidelines for Metrics” for further reference.
When 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” that are as independent as possible (the left side). Why is it so natural to do this, rather than the alternative - split into two teams, responsible for “A” together (the right side)?
There are a few responses:
We don’t know why we do this, with the variants of “we have always been doing this”, “others are doing this”, “there are no other alternatives”, etc.
We want specialization by letting each team focus on one subset.
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 addresses the 3rd response.
Mental model
The iceberg model is a systems thinking tool. It helps progress our thinking from an obvious event to patterns of behavior, to their supporting structures, and the 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.
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 let’s look at the topic of responsibility. Is “clear responsibility is necessary” the mental model here? It is hard to dispute 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 “we want individual responsibility” in disguise. So, the real mental model is “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 it difficult to find someone accountable, so we don’t know whom to blame or even fire in case of failure. In contrast, individual responsibility makes it more “clear”.
However, the sole focus on the responsible part leads to strong local identity, and eventually to silo mentality. Many people say that they hate silos, but in fact our love for “clear” responsibility helped create them in the first place. Maybe we don’t really hate silos, or 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 be better.”
This happens in Scrum adoptions. One-team Scrum breaks down individual responsibility for the individual members, and defines shared responsibility for 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 adoptions too. LeSS – aka multi-team Scrum – breaks down individual responsibility for individual teams, and defines shared responsibility for 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 since LeSS is Scrum.
The shift in this mental model happens on two levels – one-team (Scrum) and multi-team (LeSS), but they are essentially the same.
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 when 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 an individual team take shared responsibility, but failed to take it to 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 the 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.
Real Scrum requires significant organizational redesign. I have seen two common settings to pilot Scrum: 1) project group and 2) component team. As those are existing structures, it is convenient to just use them. However, without organizational redesign, you would end up with fake Scrum.
In this article, we focus on the organizational setting with component teams, and discuss two alternatives before we are ready for organizational redesign to adopt real Scrum.
Here is the starting point.
Let me clarify some terms I use here:
Features are requirements for the product. They are customer centric and associated with business value.
Component requirements are requirements for the component. They are actually tasks from the perspective of the product.
Component tasks are internal tasks in the component.
Traditionally, TL is responsible for the component team and is held accountable for delivery of the component work.
Fake Scrum with team PO
This is what usually happens while adopting Scrum for a component team.
Of course we introduce the roles of SM and PO, right? As there used to be one TL, I have seen two common arrangements:
TL becomes the PO, who is a team PO as well as a fake PO, as he is clearly not responsible for maximizing value of the product. Another person is found to fill the SM role.
TL becomes the SM. Another person is found to fill the team PO role.
Usually, regardless of whether the TL becomes the PO or SM, the delivery accountability is still kept with the TL.
Those are good progress. However, in both cases, focus on the component misses the most important point behind real Scrum – maximizing the value through inspection and adaptation based on features and whole product perspective. Therefore, this is fake Scrum with a team PO.
Real “Scrum” with TL
An alternative I would recommend is to keep the TL role, but transform the role to 1) do the fake Scrum on the component, 2) shift focus to the product and features, and 3) advocate for organizational redesign.
Let me elaborate:
Do fake Scrum on the component
consolidate all component work and prioritize (i.e. what the fake PO does)
coach the team to self-organize for delivering the component (i.e. what the SM does)
Shift focus to the product and features
connect component work to the product and features
connect component team to the real PO
coach team to self-organize with other component teams in delivering features
coach the real PO to inspect & adapt on the product
Advocate for organizational redesign
prepare with cross-learning and technical excellence
spread the knowledge and experience on organizational redesign towards feature teams
This approach better follows big ideas behind Scrum, even though Scrum roles are missing. Therefore, this is the real “Scrum” with TL.
Only after the organizational redesign and creation of feature teams, the team would work directly with the real PO, and it would take end-to-end responsibility for feature delivery. Eventually, the TL would be replaced by a SM – a coaching role not responsible for the delivery. That would be the real Scrum.
End note
In fact, TL working this way is well defined in the book Leading Self-Directed Work Teams. It describes the TL role as a boundary manager. Please, do not introduce team PO for a component team, TL will do.
RSS feed