Seeing the system dynamic: sprint vs. flow

Regarding the time dimension, there are two main options - sprint (aka iteration, timebox) or flow. This choice is often coupled with the choice of implementing Scrum vs. Kanban, respectively. However, in this article, we do not try to compare Scrum vs. Kanban, but only sprint vs. flow. We focus on seeing the system dynamic around its impact on value delivery and continuous improvement.

1. Value delivery

We aim to maximize the value delivery, and the key is to reduce WIP regardless of whether to use sprint or flow. The below CLD illustrates the dynamic around this.

There are actually many R1-loops. As their essence is the same, I put them under same label.

R1-loop creates the virtuous cycle of reducing WIP to maximize value delivery, which can read like this:

• the less WIP
• the more flexibility and/or the higher speed
• the more value delivery
• the more "use of same ways to reduce WIP"
• the less WIP

Then, there are various ways to reduce WIP.

a. Limiting #stories

• shorten sprint length (indirectly limiting #stories), when doing sprint
• decrease WIP limit (directly limiting #stories), when doing flow

b. Reduce story size

Sprint creates force to split the story, as it is required to complete the story at the end of timebox. When story size is smaller, it reduces WIP further. This contributes to the virtuous cycle.

However, too much force will make the story splitting unnatural, thus, decrease the value in those split stories. This forms B1-loop.

• the more value delivery
• the shorter sprint length
• the more force to split story
• the less value in split stories
• the less value delivery

The story could not be split infinitely, as there is natural limit on how small a valuable story could be. If you look at R1-loop and B1-loop together, it is actually a typical "limits to growth" system archetype. Eventually, growth process hits the limit. In reality, there are many other limits. I choose to illustrate this one as it relates to the common accusation for timebox approach.

2. Continuous improvement

We aim for continuous improvement, and the key is to create the right amount of challenge to drive improvement, regardless of whether to use sprint or flow. The below CLD illustrates the dynamic around this.

The B2-loop illustrates the relationship between challenge and improvement, which can read like this:

• the more challenge
• the more drive for improvement
• the more improvement
• the less challenge

The R3-loop illustrates the unintended consequence when the challenge is too big.

• the more challenge
• the more pressure
• the more quick fix (e.g. sacrifice quality)
• the less improvement
• the more challenge

You may think of B2-loop and R3-loop together as "fixes that backfire" system archetype. In essence, it explains that having right amount of challenge matters.

As B2-loop is a balancing loop, it leads to the stagnancy of improvement. Continuous improvement is never ending, for which we need a reinforcing loop. There are actually many R2-loops. They are all about elevating goals to create right amount of challenge again, so that improvement will continue. Thus, I put them under same R2-loop, which can read like this:

• the more improvement
• the higher "improvement goal"
• the more challenge
• the more drive for improvement
• the more improvement

Then, there are various ways to elevate goals.

a. Limiting #stories

• shorten sprint length (indirectly limiting #stories), when doing sprint
• decrease WIP limit (directly limiting #stories), when doing flow

We have seen its role in maximizing value delivery, here comes another important role limiting WIP plays, which is for continuous improvement.

b. Expanding system scope

• In Scrum, this means extending Done.
• In LeSS, this means extending Done, expanding product definition, or both.
• In Kanban, this means expanding the scope of Kanban system.

When system scope is expanded, the challenge increases, which creates drive for continuous improvement.

c. Elevating improvement goal

The above is essentially all various ways to elevate improvement goals. Besides, making it flow and shortening cycle time is probably the most important goal in Kanban. See more in my article about improvement goal.

Summary

With the choice of sprint vs. flow, they essentially use different ways to reduce WIP, while low WIP helps for both value delivery and continuous improvement.