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

จักระกับระบบประสาท

จักระกับระบบประสาท

ครูณาส่งหนังสือที่ครูแปล ชื่อ Becoming super natural มาให้ ผมได้ข้อมูลที่ตื่นตาตื่นใจหลายอย่าง หลายอย่างผมก็ยังต้องใช้เวลาค่อย ๆ ทำความเข้าใจไป แต่วันนี้อยากเอาเรื่อง จักระ ทั้ง 8 จุดมาแบ่งปัน จากในหนังสือ ผมได้ลองนั

By Chokchai
Scrum master focus

Scrum master focus

ครั้งแรกที่ผมได้เรียนว่า สกรัมมาสเตอร์ควรแบ่งโฟกัสการโค้ชของตัวเองเป็น 4 เรื่องคือ 1. องค์กร 2. engineering practice 3. product owner 4. ทีม ผมอดคิดไม่ได้ว่าคนบ้าอะไรจะไปเก่งทั้ง 4 อย่างซึ่งมันใช้ความรู้และทักษะที่แตกต่างกันเหลือเกิ

By Chokchai
Community of Practice (CoP) คืออะไร?

Community of Practice (CoP) คืออะไร?

กาลครั้งหนึ่ง… ชมรม Community of Practice (CoP) เป็นคอนเซปต์ที่ถูกกล่าวถึงใน Large Scale Scrum เทียบง่าย ๆ ก็เหมือนชมรมตอนเราเรียน ม. ปลาย นั่นแหละ ใครสนใจเรื่องอะไร ก็ไปเข้าชมรมนั้น แล้วก็ไปทำกิจกรรมร่วมกันในเรื่องที่เราสนใจ เพื่อฝึกฝนและแลกเปลี่ยนความรู้ บางทีอาจจะมี

By Chokchai