Beyond adopting LeSS

Will you adopt LeSS? Not wanted, or not possible; end of story. This is a loss of opportunity for both. For LeSS, it loses much of its potential to make an impact in the domain of large-scale product development; while for organizations, it loses the opportunity to get inspired by LeSS and learn many great and practical ideas from LeSS to help their improvement. Adopting LeSS is not the only way to benefit from LeSS.

How can organizations benefit from LeSS?

I see at least two ways, and refer to them as framework focus and experiment focus.

1. framework focus

Framework focus is to adopt LeSS frameworks (LeSS and LeSS Huge), including the rules that define them, and the guides that support the adoption.

For a smaller large-scale organization, we create a LeSS structure all at once, having multiple feature teams sharing one product backlog. To focus on the whole product, we create common sprints at product level, and inspect & adapt as a whole to maximize customer value.

For a bigger large-scale organization, we take evolutionary and incremental approach, and may start from a RA, having multiple feature teams sharing one area backlog. Gradually with one RA at a time, we transform the whole organization to be LeSS structured.

LeSS frameworks are designed to optimize for organizational adaptiveness. If we adopt it in full, the likelihood to increase adaptiveness will be high. With a well designed structure, it provides a strong foundation for teams to continuously improve. That is certainly one way to benefit from LeSS.

2. experiment focus

Experiment focus is to use LeSS experiments for improvement. In fact, LeSS started as experiments, while frameworks were introduced later as a response to the people who would like to know where to start. The history of how LeSS evolved was well explained in "the story of LeSS" by Bas.

Organizations try to improve regardless of LeSS. They are likely already on their way to improve, but they still look for inspirations about where to evolve, then further refining their vision; or look for improvement ideas in various areas of product development, learning from others and the industry. LeSS experiments just provide those kinds of inspirations and improvement ideas.

This initial set of LeSS experiments is well documented in the first two LeSS books, and more experiments are constantly emerging. When we learn about experiments, we don't just copy the solution - the experiment itself, but focus more on the reasoning behind - why this experiment, what factors and dynamics are involved, etc. The people in organizations decide what to do with that learning, and they own their improvement.

Experiments can be small or big. Those experiments concerning organizational design are usually big ones, which can be risky, but also have the potential to create profound impact. Nevertheless, organizations choose the right pace on their own. Their next experiments can be creating one feature team aligning all members' performance measures without the change in reporting line, merging two teams' backlogs, having the team leader step away from assigning tasks, and many more. They are not the same as LeSS rules, and even not directly from but inspired by LeSS experiments, however, they are equally if not more powerful with their own thinking, reflection and learning.

These organizations may never officially adopt LeSS frameworks, but they clearly can benefit from LeSS.

Get balanced

On reflection, I feel that we get somewhat imbalanced with these two focuses over the years. We seem focusing more on the opportunities of adopting LeSS, and less on the opportunities of using LeSS experiments for improvement. However, the latter perhaps accounts for more among all cases where LeSS can be beneficial. All the LeSS case studies seem focusing on the adoption, and there is not one case study based on using LeSS experiments to improve a large-scale product development organization, without adopting LeSS. In contrast to talking much about starting a LeSS adoption, we seem talking less about designing the next experiment for improvement. LeSS adoption is becoming a goal in itself.

Therefore, I'd like to rebalance the framework focus and the experiment focus. Specifically, I will take initiative to group relevant LeSS experiments into improvement areas (product, team, engineering practices, and organization), then organize a series of educational sessions to increase the awareness that our improvement can benefit from LeSS. Anyway, what really matters is to improve product development. So, let's go beyond adopting LeSS!

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