(Originally published by Lv Yi on May 7, 2020)

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 ?

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

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.

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

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

(Originally published by Lv Yi on June 8, 2020)

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:

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

(Originally published by Lv Yi on June 3, 2018)

[Team Leader = TL; Product Owner = PO; ScrumMaster = SM]

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:

1. 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.
2. 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:

1. 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)
2. 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
3. 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.

This is a cross-post from AgiliX blog post.

This blog is part of a series of peek previews from my upcoming book Coaching Agile Organisations.

In the first part of this blog series, I explained how to identify the organizational elements to include in your product definition. In this blog, I explain how you can refine your product definition to organize into effective cross-functional teams.

Some elements are more equal than others

Below you can see a simplified view of the organizational elements at one of my customers.

We discovered that some organizational elements are required more than others to develop product features. The more often a particular element is required, the stronger the dependency. We visualised the strength of the dependencies with a heat map – see the figure below for an anonymised simplified example.

The y-axis shows product features. The x-axis shows the organizational elements. A green area indicates an element that is needed to deliver the feature

The elements that heat up the most indicate the strength of the dependency – these are the hotspots. Note that the WEB element is needed in 28% of the time to develop product features, the APP 20% of the time, while Legal is required only 7%.

NOTE: Avoid focusing too much on the percentages. This is not exact science, but rather a guide to help you move forward. Other than percentages I have also successfully used categories to estimate the strength of the dependencies like: Seldom, Now and Then, Frequent.

When all the teams can pick up any work that comes in and deliver it completely to “done”, you have maximum adaptability. That would mean that each team has the skills to cover the whole heat map. Unfortunately, this was not the case for us. There were just too many technologies and domain knowledge for the teams to comprehend. Also, there is value in team specialisation. The solution was for teams to specialise in the customer domain first, and then to learn about other product domains as needed.

Learning can take many months or even years, and in the meantime, we needed to determine how to start. Which organisational elements should the teams cover first and which shall we add later? This decision depends upon the strength and type of the dependencies.

Find the balance between adaptability and speed

When a team can work on all components but only one feature, a team covers a complete row, as drawn in the figure below. Such a team has no external dependencies; hence they probably deliver fast. On the other hand, when a team covers all features but only one component, it covers a complete column in the heatmap. Such a team can work on all feature-parts; hence they can adapt to all work that comes in, but cannot deliver end-to-end.

Therefore, the size of the heat map area that a team covers strongly determines its

• feature delivery speed
• flexibility to pick up work from the product backlog

Our challenge was to find the optimal balance between speed and adaptability in our 11 team context, and that depended upon several variables:

• The teams’ cognitive capacity. When teams specialise in a customer domain they can still work on customer features without needing to understand the other customer domains of the product.
• The type of dependencies between the elements. This helps the teams determine which organizational elements to cover first and which later.

Specialise in the Customer Domain

Our product was a large insurance system. We used interviews and questionnaires to determine where users spend most of their time when using the product. It turned out that there were a couple of main groups of users. (For this blog, I just use 2 groups: “Claims” and “Evaluation” and call them “red” and “yellow”.) Some users mostly used the red-colored features – red area – while the other group primarily used the yellow-colored features – yellow area. The orange features were used by both groups of users – they overlap or intersect both red and yellow areas.

The red and yellow areas let the teams specialize in a customer domain – see Requirement Areas in LeSS and Value Area Scrum pattern. This reduces the cognitive demand on the teams.

The next step was to find the most significant heat map area that the teams could cover.

The type of dependencies between the elements

We used the following rules to decide which elements to include from the beginning and which to add later.

• Rule 1 – Contain reciprocal dependencies within one Value Area: The work of one team is input for another team and vice-versa, and there is uncertainty about how to accomplish the task, which makes frequent alignment necessary.
• Rule 2 – Ensure sequential dependencies between Value Areas with iterative planning when one team’s work is dependent upon the work done by another team. Applicable to work with low uncertainty and predictable work.
• Rule 3 – Manage pooled dependencies across Teams and Value Areas with simple coordination rules. For example, sharing of a single test environment, or dependency on a person with a scarce skill.

Below you can see an example result for the red Value Area.

The Web, App, Siebel, Portal components are used often together and their interdependencies are reciprocal. The teams in the red area decided that they would need to cover at least these elements.

Furthermore, you can see that the area has a pooled interdependency with Legal, and that it is a relatively strong dependency of 14%. The weakest interdependency is with the Sales Force. We choose not to include Sales Force initially and only add it when the teams mastered the other elements. Legal was also not included because it was a pooled dependency.

The yellow Value Area below has a different set of dependencies.

The teams decided that they needed to cover at least the APP, Sales Force, Siebel and WEB components.

For this area, Legal is not needed at all. And there is a weak sequential dependency on Portal. We decided to not include Portal in the first step. In the exceptional case that a feature needed a change in Portal the teams would coordinate with the red-area to get it done. We also used these as opportunities to learn more about Portal.

How to handle features in the intersecting orange area? A solution is to decide based on the feature itself.

For example, F10 could be picked up by either the red or yellow area. F18 requires only APP and can be picked up by the yellow area. The only complicated feature is F11. It requires knowledge of both Sales Force and Portal which neither the red or yellow area possess. So, how to handle this one? Well…, remember the golden rule of Scrum Mastership: “Always ask the team.”

Final Result

The product definition includes all elements, but we choose to not include Legal skills in any of the teams from the start. Why? Because it is a pooled and weak dependency. Also, the teams felt they were not yet able to cover more skills right from the start. Instead, Legal became the next activity to include in their Definition Of Done.

In the infrequent case when a feature requiring Legal skills would appear on top of the Product Backlog, we would plan for that by working together with Legal in refinement events and during the Sprint.

During Sprint Planning, the team that selected that feature would then coordinate to work together with someone from Legal to get the feature done. Preferably, the Legal person(s) would also use the opportunity to teach the team so that they understood a little bit more about Legal at the end of the Sprint. When a team keeps selecting to work on features with the Legal part, eventually they would learn enough to add Legal to their Definition Of Done. Bas Vodde calls this accidental specialization.

NOTE: Not all teams need to know everything about all elements in the Product Definition right from the start. Teams can have their own speciality as long as all teams as a group can pick up any element from the top of the Product Backlog.

This is a cross-post from AgiliX blog post.

This blog is part of a series of peek previews from my upcoming book Coaching Agile Organisations.

This is the first part of a blog series about product definition in LeSS.

In large product development, teams tend to work on just a part of the real product. The part – a narrow product definition – is often a component or a specific activity in the development process; it is not a product.

A narrow product definition creates all kinds of problems for a product group. It locally optimizes the performance of the teams at the cost of the performance of the group. The causal loop diagram (CLD) below explains this dynamic. (See this blog for a quick overview of CLD notation.)

Narrow product definitions make it more likely to have specialized teams that only work in their silo, which in turn decreases adaptability and speed of learning at the overall product level. Broader product definitions lead to teams that cover multiple components and activities that together address the needs of end-users.

What is a Product Definition?

A commonly used definition of a product is “something that is made to be sold.” The product provides a way of making a profit.

• A product has users who are people.
• A product provides features to those users that address their needs and problems.
• A product has a business model, revenue stream, independent profit & loss, or return on investment.
• A product is developed and sustained by a system of people, components, and processes.

The product definition determines what organizational elements (people, components, processes, and systems) are needed to develop and run the product. If your product is Mortgages, then your Product Owner is probably a business person who understands the market. The Product Backlog might have items like “Loan offers to small businesses,” and the users are likely to be paying customers. Mortgages is a broad product definition when it contains all the parts needed to produce an end-to-end solution to the end customer.

How To Define the Product?

The product definition includes multiple components, activities, and provides solutions to the needs and problems of end-users. You can define your product using the following two steps:

Step 1 – Identify the required organization elements to develop and sustain the product.

You start with the elements – your component teams – you currently call products, the activities, the people, and the processes you have presently in your group. You then study how the work works for your group so that you understand the types of dependencies that exist to develop, maintain, and sustain your product.

The typical steps to achieve this are:

• Identify some typical external end-users of your group.
• Identify some regular needs these end-users want to be addressed or tasks they need to complete.
• Identify some features for each of the users that they consume to address their needs or perform their jobs.
• Identify the boundaries through which the users consume the features to satisfy their needs/problems etc. (for example a Browser, App, API, Connector or Helpdesk)
• Next, you want to identify the organizational elements that are needed to produce the feature and satisfy the customer. You do that by studying how each feature flows through your organization into the hands of the customer. You start at the boundaries and work through the components, systems, people, and processes until completion.

Step 2 – Clarify the revenue streams

A proper product definition identifies a group broad enough so that it includes revenue streams. Without it, the teams in the group will likely be disconnected from market concerns where the real value lies, and instead, the teams focus only on the part of the whole product.

In this step we ask the question: Do the identified organizational elements produce a product that generates revenue for the organization? Or are there missing parts to do so? The way we prefer is to find answers to the following questions:

• How do the elements together generate cash? For example, is the product definition able to have usage fees? Asset sales? Subscription fees?, Licensing? If not, what would need to be added to the product definition?
• Does the product definition have an independent profit & loss? If not, what organizational elements are missing?
• What business KPIs can you assign to the product definition? For example, can you assign it an increase in gross income? An increase in new customers? Customer satisfaction?

If you cannot give a meaningful answer to all of the questions above, then your product definition is too narrow, and you would need to expand it.

Product definition completed?

At this point, you identified a set of organizational elements that together produce value for end-users and have an independent revenue stream. The result typically includes tens of components, skills, activities, and it can involve hundreds of people in total.

With such a large group, you may ask yourself, “How can I create effective cross-functional teams that include all these capabilities?” In the case of more than around ten teams, we recommend to organize the teams among Value Areas and contain dependencies per area.

This is the topic of my next blog, part 2.