Take the problem to team

Self-organizing team is an essential element in Scrum. ScrumMaster has the responsibility to help team become self-organizing. Agile coaches often give the suggestion that you should take the problem to team. While this is a good suggestion, it is too much simplified thus not used effectively in practice. I'd like to elaborate the key aspects and ScrumMaster's role in this approach.

  • Define the problemIt is too often for us to quickly jump into solutions, while it is much more effective to sell the problem than to sell the solution. Slow down to first define the problem. At which boundary should the problem be defined? That is the same boundary you want to enable team's self-organizing. Why does the problem matter to the team? Make the problem clearly seen by the team.
  • Who is "the team"?

When taking the Scrum context, it is the team who is self-organizing. That's the target we bring the problem to. However, it's beyond that if we think of self-organizing as a different thinking paradigm than command and control. What if the problem relates to two teams? Then "the team" is two teams combined. Therefore, it's really the group of people who should self organize to solve the problem.
The problem and the team are coupled. Let me give you one example from my recent coaching experience. The organization was fighting for getting the release out. The overall situation was challenging. The number of bugs found in system testing, which is still not part of their Scrum team's definition of Done, was high, and system testing was still in progress. Different Scrum teams were working separately to fix bugs, and system testing team was executing test cases according to the plan. I observed that those teams, Scrum teams and system testing team, did not sufficiently work together. Only few people had the idea about where the release was heading. The problem in this situation was the challenge to get release out, while all teams were the people who should work together to face this challenge.

  • Take the problem to team

After you define the problem and find the team to work on it, the next step is to enable them to work together. It could be as easy as sending out an invitation. Or you have to first get their buy-in for the problem and the need to collaborate with others in solving the problem. It is worth the time to gradually build the shared understanding and agreement about the problem among the people, before taking it to them for solutions.

  • Facilitate collaboration

Once the whole team is ready to work on solutions, your job is to facilitate the collaboration. Try simple collaboration process as described in the book "Stand Back and Deliver", and study books such as "Collaboration Explained" and "Facilitator's Guide to Participatory Decision-Making" for skill development in this area.

  • Coaching for depth and breadth

During the whole process, ScrumMaster plays a coaching role. In the beginning, you may see the problem, define it and bring it to the team. Gradually, you coach more people in seeing and defining the problems by themselves. When they start to collaborate, the greatness of the solutions still depends on their capability in problem solving. You coach them in analyzing root causes and designing experiments to verify. There are two main focuses in the coaching - understand the problem within the broader system, and analyze the deeper causes. PDCA, systems thinking, root cause analysis techniques, even scientific method are the great sources of learning.
Self-organizing is not only a team element, but also at the organizational level. Therefore, the approach is actually not only for ScrumMasters, but also for managers in Agile organization. Yes, managers as coaches!

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