A fractal is a structure in which, when you look closer, you will discover self-similarity at different scales. (wikipedia).

Zoom In and Out Scrum

Fix The Empirical Process Control

In Picture A, you can find a typical representation of a Sprint in Scrum, which is, perhaps, a misunderstanding of both iterative development and empirical process. After a sprint, the organization should have an updated direction, embodied by an updated product backlog, as shown in Picture B.

Rotate and Zoom In 1

Let’s rotate Picture B inward and zoom in to reveal some details in a successful Scrum team. Within a Sprint, you can find multiple iterations, and each adds a done increment to the product, gets full-cycle feedback, and delivers customer value. The team will limit the Work-In-Progress by finishing one item before moving on to the next one, as shown in picture C. Scrum is iterative doesn’t mean a Sprint is one iteration.

Zoom In 2

If you zoom in again, you can find a successful Scrum team’s way of working repeats the above pattern. For the one item they are focusing on, they break it down into many small iterations, and each of them is a steady stepping stone towards their goal and seeks to have full-cycle feedback. As shown in picture D, a team will use practices like ATDD, TDD, trunk-based development, continuous delivery, etc.

Zoom In 3

Let’s look even closer. A successful team with many members does not work in a single thread (some do, using mob programming). They may split an item into smaller tasks and work in parallel. But as we saw before, all these tasks belong to the same item, and everyone is continuously coordinating and integrating. It will look like picture E. It might look intimidating for many, but not for a team practice collective code ownership, continuous integration, communication through code, and self-managing coordination, in addition to their individual practices like TDD. Unfortunately, decision-makers usually do not have visibility at this level, and Scrum Teams typically are not equipped with the technical practices that enable them to experience this.

Zoom Out

Now, let’s zoom out. How do you scale Scrum? A LeSS Sprint should look like picture F. The entire development organization focuses on the same direction. Teams may focus on different user-centric items, but these items belong to a limited number of larger topics. They integrate and coordinate by themselves all the time. At the end of the Sprint, the organization has an updated direction, reflected in their single, updated Product Backlog.

The Wrong Fractals

All models are wrong, but some are useful. Like many people in the LeSS community, I’ve had this mental model for many years, which helped me organize my thoughts on software development at different scales. I kept it to myself because I thought the problems and constraints differed at each level, and my mental model could be an oversimplification. On the one hand, now I feel there’s enough similarity to call it a fractal structure. On the other hand, I see the danger of it. I found there are a couple of things worth noticing.

• The Sprint itself is not part of the fractal. A Sprint has unique qualities. For example, it has an arbitrary timebox, which is the cadence of the organization.
• A misunderstanding of Scrum is that the work should be pre-planned to remove dependencies, typically by the management. The integration and coordination are also led by management, usually when the individual tasks are done. As shown in the picture, this model is too wrong to be useful.

The harmfulness of Scrum Master double roles and what you can do about it

The other day I had an intense conversation with managers about the topic of double roles of a Scrum Master. One of the managers was also a Scrum Master. He and his superior defended the viewpoint that it is a great idea to have one person being the line manager for the teams and at the same time being the Scrum Master for the same team. Based on my observations about the typical dysfunctions created by this kind of set-up, I express my thinking that the Scrum Master must be a dedicated role if the organization is seriously wanting to introduce Scrum. As a result, I was labeled kind of religious and “inflexible to adapt to their thinking”.

My first learning was that it is pointless to convince others of your view and the statement “own versus rent” has proven itself once more. People need to generate those insights by themselves and not be told by a “guru”.

I dug up some of my old work on this subject and I present you with an overview of different combinations I have seen during my work life including my view on the pros and cons.

Conclusion

I can not recommend any of these combinations as the cons in all those combinations outweigh the pros. Most companies do the combination for saving money, and this is in IMHO the wrong place to start saving money. Having a dedicated Scrum Master allows this person to fulfill the role of an SM without conflicts of interest, and support, coach, help the teams, the PO, and especially work with the organization (in collaboration with the managers) to create the environment in which teams can succeed.

What to do about it?

The biggest hurdle seems that organizations need to do their own learning. Therefore I suggest you make experiments in your organization. Try out a dedicated Scrum Master in comparison to the combination you face in your organization. Reflect after 2-6 Sprints on the results, and then adapt based on your findings. Yes, this will take time and energy. The easier way might be to follow the principle of Shu-Ha-Ri and adopt the collective learnings from the past 15 years (and e.g. the empirically-created LeSS rule): The Scrum Master is a dedicated role.

Harmful Agile Adoptions by Playing with Words

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

Wish we could stop playing with words.

(Originally published by Lv Yi on Oct 3, 2019)

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.