Change starts before it starts

People ask me how long it takes to adopt LeSS? I say, half a day. I refer to the most visible change in the LeSS adoption - team self-designing workshop, where the restructuring to feature teams happens.

In fact, change starts before it starts.

A couple of years ago, my client asked me to consult on their large-scale Agile adoption based on LeSS. I accepted and later found that there was not yet any product unit ready to start the adoption immediately. Thus, we started with organizing a few 2-day LeSS workshops in their various sites. We invited key people from product units who were interested in improving their system, and offered LeSS as one alternative. Not surprisingly, nobody decided to move forward right after the workshop. If they did, I must have set the unrealistic expectation about what this meant. After those workshops, we continued the discussion with some of them, who were not  scared away still. Fortunately, a couple of product units eventually went onboard. The experience afterwards was documented in my experience report - LeSS without Scrum.

Ever since that, I evolved my strategy about what to do before reaching the point of flipping the organization.

LeSS workshop

Having LeSS workshop to build the understanding is still essential. I do not try to sell, but help make informed choices. For many people and organizations, they only see one option. For example, start with one team responsible for one component; when the team grows and splits into two teams, almost always, each team would be responsible for a sub-component. The success key in workshop is to help people see it as one option, but there are also other options.

We apply systems thinking to understand current situation. By seeing the dynamics resulted from our previous choices, we develop insights about how we contribute to our own problems. This is critical in building the motivation for change.

Different options are optimizing for different system goals. We need to define the organizational perfection goals, as they guide our choices in organization design. LeSS is a set of organization design choices, and optimizes for the goal of delivering valuable product in every sprint. If you have a different goal such as maximizing resource utilization, you would make different choices.

Once we build informed consent, we are ready to go.

One product backlog

We develop better understanding about what our product is, and create one product backlog for it. We do not change the way of managing work yet, but only add this view in parallel. This creates transparency, and often exposes problems in the current system. One typical problem is the difficulty in delivering a feature due to the asynchronous dependency across multiple component teams. By seeing those problems clearly, the motivation for change increases.

Meanwhile, this is also the foundation for the future work and team re-design. It helps accelerate the pace of change once your decide to go. We shall use it as guideline for team self-designing workshop. We shall use it as input to sprint planning. Even if you still decide not to take the further step, one product backlog is still useful to let you see the value delivery capability of your organization.

Continuous integration

Continuous Integration (CI) is essential for feature teams to succeed. It takes much effort to build this capability, thus, start earlier. We adopt CI to tackle one of the known biggest obstacles in adopting LeSS. On the other hand, the motivation of adopting CI may be low as you do not yet have feature teams in place. This becomes chicken and egg problem. As minimum, we shall do the daily build, and create one example for both unit test and acceptance test. This involves the skill buildup and tool selection. It helps accelerate the pace of change once your decide to go. Meanwhile, those engineering improvements are useful regardless of your organization design.

Before "change" (i.e. the most visible structural change), you focus on these areas. During "change", you focus on organization design for both work and team. After "change", you focus on sprint practices, effective learning, coaching for self-organization 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