LeSS is natural

I realize that LeSS is a natural way to scale. And let me illustrate.


LeSS is still Scrum


LeSS provides two different large-scale frameworks: LeSS for 2-8 teams and LeSS huge for 8+ teams. We focus on LeSS here. LeSS is trying to reach the same purpose as one-team Scrum while staying within the constraints of the standard Scrum rules. So, let's examine what's essential for one-team Scrum.


One summary could be "deliver value on sprint basis". This is achieved by one Product Backlog (PB) by one Product Owner (PO), representing value; and one Team self-organizing to deliver at the end of each Sprint, getting Done and leading to one Potentially Shippable Product Increment (PSPI).


That basically has:

  • One PO and one PB
  • One Done and one PSPI
  • One Sprint
  • One Team

What's the challenge when scaling? Team size is too big. We need to split them into multiple teams. Think about 20 people, we may split them into 3 teams. But meanwhile keep the rest as intact as possible.


That leads to:

  • One PO and one PB
  • One Done and one PSPI
  • One Sprint
  • Multiple Teams

The design goal for team structure is to enable any Team (after splitting) take items from one PB, get to common Done and become part of common PSPI (integrated with other items done by other Teams). Feature team (the majority of the teams) is thus a natural choice.


This is LeSS way, and it is natural to scale this way. More reference here.


Scale Scrum when we grow


In a recent scaling workshop, an interesting comment was raised. "We pretty much did LeSS even without knowing it." I dug deeper on how it evolved. It turned out that they started with one-team Scrum, but grew to the size that is too big for one-team any more. They tried to introduce minimal change by splitting the big team into several small parallel teams. By "parallel", i mean that they could work on any item in the common backlog and didn't create specialization area to constraint themselves. This worked well for them.


This reminded me of my previous experience. Back to 2005-2006, in my first Scrum project, we started from one team Scrum. After 6 months, it grew into 3 teams. We kept one PO and one Product Backlog. We shared the Sprint rhythm, defined common Done, had joint sprint planning and sprint review to keep the whole product focus. This is in line with LeSS. Again in 2008-2009, we had one team in my department, growing into 3 teams. It used similar approach leading to similar LeSS structure.


If you start with one team Scrum, it is rather natural to scale to LeSS. Moreover, regardless of how big the product eventually becomes, it is almost always wise to start from one team. Therefore, scale to LeSS, not start from LeSS.

Read more

เวลาอู้

เวลาอู้

ผมกำลังอ่านหนังสือ Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency ของ Tom DeMarco ซึ่งได้ให้มุมมองใหม่เกี่ยวกับ Slack time หรือเวลาอู้งานกับผม แต่ก่อนจะเล่าว่าผมเห็นอะไร ผมของแบ่งปันมุมมองเวลาผมดูองค์กรก่อนนะ สายการผลิต คนในองค์กรมารวมตั

By Chokchai
สุดยอดทีม (Extraordinary Team)

สุดยอดทีม (Extraordinary Team)

ท้ายหนังสือ Teamwork is an Individual Skill ของ Christopher Avery ได้กล่าวถึงสมการของสุดยอดทีมไว้ดังนี้ครับ Extraordinary Collaboration = Exchange + Expansion + Integrity ผมใช้เวลาอ่านตรงนี้ และอีก 3 บทที่ขยายความเรื่อง Exchange, Expansion และ Integrity อยู่เกือบ 2 สัปดาห์กว่าจะพอเข้าใจมันอย่

By Chokchai
ไล่ตามความฝัน กับ ดูแลตัวเอง

ไล่ตามความฝัน กับ ดูแลตัวเอง

ไล่ตามความฝัน กับ ดูแลตัวเอง ก่อนหน้านี้ผมเคยเล่าถึงขั้วตรงข้าม (Polarity) ระหว่างความคล่องตัวกับความสร้างสรรค์ไปแล้ว ครั้งนี้ผมมองว่า “การไล่ตามความฝัน” และ “การดูแลตัวเอง” (เปรียบเสมือน นักรบ กับ นักรัก) ก็เป็นแสงและเงาของกันและกั

By Chokchai
สกรัมเป็น Empirical process

สกรัมเป็น Empirical process

กระบวนการแก้ปัญหาในโลกแบ่งเป็น 2 แบบ แบบแรกคือ Defined process ซึ่งเป็นกระบวนการที่มีขั้นมีตอนชัดเจน เช่น Waterfall เป็นต้น ส่วนแบบที่สองคือ Empirical process หรือ "กระบวนการเชิงประจักษ์" ซึ่งเป็นการทำไปแล้วก็ปรับไปเรื่อย ๆ สกรัมเป็นแบบหลัง

By Chokchai