Go cold turkey for self-managing with long-lived virtual team

I have been implementing, and suggesting others to implement, solid team in Scrum context. I consider this as essential because virtual team structure so often leads to unaligned purpose and goals, since the respective managers still try to enforce their (e.g. functional) goals on the members who now work in Scrum team. Only when team shares same purpose and goals, self-managing is likely to emerge.


Recently, while coaching an organization for Agile adoption, i saw the virtual team again. The team members belong to different reporting lines, but they are supposed to all dedicate on the Scrum team, and the team is supposed to stay in the long run too. Interestingly, they choose to do that on purpose.


Why do they choose so?


  1. From manager perspective, they have no team to command & control, since they don't have one team to control. They are removed from the single point of accountability for the team. This may help transform.
  2. From team perspective, they have no reliance on manager. This may help team learn self-managing and transform too.


This reminds me of one common scenario about self-managing team.


Self-managing is one key aspect in Scrum implementation. When we form Scrum team, we tell our team to be self-managing. However, things don't work as expected, for instance, team may overlook risks in their plan, team may not well manage dependencies with other teams, team may not give sufficient visibility to stakeholders, and etc. As manager, you point those out and ask them to correct. Team fixes those, but you see more problems. Then, you follow up more closely. To your frustration, it seems not improving the situation, and the trend is even getting worse. You start to lose the confidence about the direction of self-managing.


The system archetype "Shifting the burden" captures the dynamic pretty well.


Shifting the burden.jpg


  • The problem symptom is that team does not manage themselves well.
  • It consists of two balancing loops. The upper one is a quick fix - managers use command and control to put out fire; and the lower one is the fundamental solution - increase team's capability to manage themselves.
  • There's one reinforcing loop. When managers execute command and control, it develops the unintended consequence - team steps back, which does harm to the effort on developing capability to self-manage. Then, more failure ensues, which causes managers to execute even more command and control.


The general strategy to leverage this situation includes:


  1. Focus on the fundamental solution
  2. Stop using the quick fix, or use it only to buy time


Applying those into our specific situation, it means:


  1. Agree on the vision of self-managing, managers transform from command & control to coaching and leading, and teams increase their capability and learn how to self-manage
  2. Limit the urgent cases that call for command & control, i.e. use quick fix carefully only to buy time


This promotes the gradual change, as is described in our story.


Another leverage option for a "shifting the burden" situation is to "go cold turkey", i.e. stop using quick fix completely. This is essentially what the organization i worked with would like to achieve by keeping virtual team.


However, there are dangers with this approach too. The withdrawal symptoms may be unbearable. In this case, corresponding to the reasons why they choose to have long-lived virtual team structure,


  1. When there is no direct point of accountability towards one team (there's still one point of accountability at upper level), middle managers neither function in old way, nor transform to new way.
  2. Accordingly, team lacks the support, thus, doesn't survive.


I do not mean that this will fail. Context matters and time will tell. It's a different approach, and I am keen to see how it evolves.

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