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.

Organize time - sprint vs flow - 1.png

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.

Organize time - sprint vs flow - 2.png


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.

Read more

Scrum master ทำแค่เนี๊ยะ

Scrum master ทำแค่เนี๊ยะ

เวลามีคนถามว่า Scrum master ทำอะไร แล้วผมตอบว่าทำให้ Scrum เวิร์คสำหรับทั้งองค์กร ซึ่ง โฟกัสหลัก ๆ 4 อย่างก็จะอยู่ที่ Product owner, ทีม, engineering practices และ องค์กร บางครั้งที่ผมจะได้ยินเสียงตอบกลับมาเบา ๆ ว่า “แค่เนี๊ยะ?” ในฐานะ

By Chokchai
how to สร้าง Knowledge Management

how to สร้าง Knowledge Management

ตอนเรียน Large Scale Scrum กับ Jurgen de Smet สิ่งหนึ่งที่ผมได้เรียนรู้ คือ ปัจจัยสำคัญหนึ่งที่ทำให้องค์กรหนึ่ง ๆ จะเร็วขึ้นได้ คือ จะต้องเรียนรู้ไปพร้อม ๆ กันได้ ซึ่งถ้าอยากทำแบบนั้นได้ก็จะต้อง share ownership

By Chokchai
โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

ซามูไรที่ได้รับความไว้วางใจให้แก้ core logic จะมีสัญชาตญาณซามูไร คือแก้ตรงนี้ จับยามสามตาแล้วรู้เลยว่าจะไประเบิดตรงโน้น แล้ววิ่งไปสกัดบั๊กไว้ก่อนความเสียหายจะเกิด (ถ้าเป็นในหนัง ตอนนี้เป็นบทที่บั๊กร้องว่า “มืงรู้ได้ไง?!” :D) หลังจากที

By Chokchai
ประสบการณ์ TDD

ประสบการณ์ TDD

มันมีบางชั่วขณะ ที่ผมอินกับ Test-Driven Development (TDD) มาก จนอยากจะแนะนำทักษะนี้ให้คนเขียนโค้ดทั่วโลกที่สนใจเลย ผมคิดว่า ทักษะนี้มีผลเยอะมาก ๆ กับความรู้ความชำนาญในการเขียนโค้ดของผมทุกวันนี้ แต่ที่ผมไม่เคยอธิบายเป็นคำพูดออกมาได้คือ ทำไมนะ? เมื่อเช้าตอนกำลังอ่านเกี

By Chokchai