System modeling ใน Overall retrospective

Chokchai Phatharamalai
odds.team
Published in
2 min readJan 3, 2022
Photo by Ivan Bandura on Unsplash

ผมกับเจนมีโอกาสได้ไปพูดในงาน Agile Tour Bangkok 2021 ที่ผ่านมา ใน session ของเรา พวกเราได้แชร์สิ่งที่เราได้เรียนรู้จากการลองทำ LeSS Example 14 เดือนที่ผ่านมา

LeSS Example เป็นองค์กรที่เราตั้งใจให้เป็นตัวอย่างให้คนในวงการไอทีไทยได้มาดูว่า Large Scale Scrum ในชีวิตจริงมันเวิร์คยังไง

ใน talk ของเรา พวกเราได้แบ่งปัน quote ที่ผมจำได้จากการเรียนคอร์ส Certified LeSS Practitioner ของ Viktor Grgic ว่า

LeSS Organization ที่มีประสบการณ์เค้าทำแต่ System modeling ใน Overall retrospective เท่านั้นแหละ — Viktor

ผมแบ่งปันต่อว่า overall retrospective เป็นพื้นที่ที่เอาไว้ทำ organizational change ซึ่งผมได้เรียนรู้ว่าการทำ overall retrospective โดยให้ตัวแทนของทีมมาแบ่งปันปัญหาที่เจอใน sprint เป็นหลุมพรางที่ในหนังสือ Large Scale Scrum เตือนว่าหลาย ๆ คน (รวมทั้งผม) มักจะตกลงไป เพราะการให้ทีมแบ่งปันปัญหาที่เจอใน sprint retrospective มักจะจำกัดมุมมองของทีมให้มองแค่สิ่งแวดล้อมการทำงานของตัวเอง เป็นมุมมองของทีม ๆ เดียว ซึ่งยังนับเป็น local optimization อยู่ ทั้ง ๆ ที่จริง ๆ แล้ว overall retrospective เราควรจะมองภาพรวมทั้งองค์กร

พอพูดเสร็จ ก็มีคนมาถามหลายคนว่า System modeling มันเกี่ยวอะไรกับ overall retrospective มันช่วยให้ทีมมองภาพรวมทั้งองค์กรได้ยังไง?

System Thinking

ก่อนจะไปตอบคำถาม ผมอยากแบ่งปันก่อนว่าเวลาผมใช้คำว่า System modeling ผมหมายถึงการทำ Causal Loop Diagram ซึ่งเป็นเครื่องมือที่ไว้อธิบายว่าอะไรเป็นเหตุให้เกิดอะไร ทำให้เราเห็นความเป็นเหตุเป็นผลได้ง่ายขึ้น

Causal loop diagram ไม่ใช้เครื่องมือเดียวที่ผมใช้ใน System thinking อีกตัวที่ผมใชับ่อย ๆ และมักจะมีคนรู้จักแพร่หลายกว่าคือ 5-why หรือคือการถาม why ซ้ำ ๆ 5 รอบเพื่อหา root cause ที่แท้จริง

Causal loop diagram ช่วยยังไง

ผมพบว่า Causal loop diagram ช่วยให้คนได้อธิบาย mental model ของตัวเองออกมา ว่าในความเข้าใจของเค้า องค์กรที่ทุกอย่างทำงานสัมพันธ์กันอย่างเป็นระบบนั้น มันเกี่ยวพันกันอย่างไร อะไรเป็นเหตุเป็นผลของอะไร

ข้อดีอีกอย่างคือ causal loop diagram เปิดพื้นที่ให้มุมมองที่แตกต่างกัน เช่น มีคนคิดว่ายิ่งใช้เวลาทำ code review เยอะ quality ของ code โดยรวมก็ยิ่งดี ขณะที่สมาชิกอีกกลุ่มเห็นต่างว่ายิ่งทำเยอะ ก็ยิ่งทำร้ายคุณภาพโดยรวมของ code ได้มาแบ่งปันมุมมองที่แตกต่างกันได้ โดยไม่ต้องเถียงกัน

นอกจากนี้ พอเห็นตัวแปรหลาย ๆ ตัวที่สัมพันธ์กันข้ามฝ่ายงาน ช่วยให้สมาชิกเข้าใจว่าผลกระทบของผลงานที่ตัวเองทำมีผลกับภาพรวมขององค์กรอย่างไร ทำให้มุมมองทุกคนกว้างขึ้นครับ

สำหรับคนที่ยังไม่เห็นภาพเพราะยังไม่คุ้นเคยกับ causal loop diagram พี่อูเขียนอธิบาย basic ไว้ค่อนข้างดี สามารถอ่านเพิ่มเติมได้ในบทความด้านล่างครับ

และถ้าใครอยากฟังที่ผมกับเจนแบ่งปันในงาน Agile Tour Bangkok 2021 สามารถติดตามได้ที่กลุ่ม facebook นะครับ ล่าสุดผมได้ยินว่าติดปัญหาทางเทคนิคนิดหน่อย ทำให้วีดีโอจากงานโดนปิดไป ทางทีมงานกำลังแก้ไขอยู่ครับ

อ้างอิง

--

--