3 อย่างที่ทำให้ผมเข้าใจ LeSS
Scrum primer เล่าว่า ในสกรัมมีคนหนึ่งคนเป็น product owner มีอีกคนเป็นสกรัมมาสเตอร์และทีมมีขนาด ประมาณ 5–9 คน คำถามที่ผมได้ยินบ่อย ๆ คือ ถ้าองค์กรเรามีคนมากกว่าสิบคนหล่ะ เราจะ scale Scrum ยังไง?
ผมเชื่อว่าทางที่ดีที่สุดคือ “อย่า scale” และถ้าเลือกไม่ได้จริง ๆ ผมจะทำ Large Scale Scrum (LeSS)
LeSS ถูกคิดโดยชาย 2 คนชื่อ Craig Larman และ Bas Vodde ด้วยความตั้งใจที่จะบิดสกรัมให้น้อยที่สุดเพื่อรองรับขนาดทั้งองค์กร
ผมใช้เวลานานมากพยายามทำความเข้าใจมัน และวันนี้ที่รู้สึกว่าผมเริ่มเข้าใจ LeSS มากขึ้น เพราะผมเข้าใจกลไลของของ 3 สิ่งมากขึ้น ดังนี้
- วิธีทำ product backlog refinement ด้วยคนเยอะ ๆ
- วิธีพัฒนาซอฟต์แวร์ด้วยคนเยอะ ๆ
- วิธีการทำ retrospective ด้วยคนเยอะ ๆ
Product backlog refinement
กิจกรรม product backlog refinement เป็นกิจกรรมเดียวเลยที่ทีมเปลี่ยนสมาธิจากงานที่ตัวเองกำลังผลิตอยู่ในมือ มามองอนาคตว่าใน sprint ถัด ๆ ไปจะมีอะไรเข้ามาบ้าง เป็นช่วงเวลาแห่งการเรียนรู้ บ่อยครั้งมีการแลกเปลี่ยนความรู้ ความคิดเห็นระหว่าง business domain กับ technical constraints กัน บางครั้งก็มีการทำ design studio เล็ก ๆ ในกิจกรรมนี้ด้วย ซึ่งตอนที่เป็นสกรัมทีมเดียว อะไร ๆ มันก็เรียบง่ายไปหมด เพราะเราเอาทีมขนาด 5–7 คนรุมคุยทีละเรื่อง ๆ ได้ แต่พอคนเยอะ ๆ เช่น 20–30 คน บางครั้งก็อาจจะถึง 50 คน เพราะมี domain expert ในเรื่องต่าง ๆ เข้ามาร่วมกิจกรรมนี้ด้วยเพื่อถ่ายโอน domain knowledge ให้กับทีมพัฒนา ซึ่งส่งผลให้เราไม่สามารถนั่งคุยทีละเรื่อง ๆ ได้แล้ว ไม่งั้นมันจะไม่ทัน เทคนิคหนึ่งที่ LeSS แนะนำคือให้ทำ multi-team product backlog refinement โดยสร้าง mixed-up group ที่มีสมาชิกจากหลาย ๆ ทีมรวมกันในแต่ละกลุ่ม แล้วคุยหลาย ๆ เรื่องพร้อม ๆ กัน ในห้องใหญ่ ๆ ห้องเดียวกัน ติดอะไรจะได้เดินถามกันได้
การทำแบบนี้ ทำให้เรา delay การตัดสินใจว่าทีมไหนจะทำ item อะไรไป ตอนทำ sprint planning ครั้งหน้าได้ ทำให้ sprint planning work เหมือน Scrum ธรรมดา คือ product owner เรียงของตาม priority ไว้ แล้วทุกทีมก็ไปหยิบงานที่สำคัญสุดมาทำจนทำไม่ไหว
Collective code ownership
หลังจากเข้าใจว่าความรู้เรื่อง requirement ใหม่ ๆ มันไหลเข้าสู่ทีมที่มีคนมากมายอย่างไร ถัดมาคือผมก็มาทำความเข้าใจว่าการที่มีคน 30 คนเขียนโค้ดใน product เดียวกันเนี่ย ทำอย่างไร
จากประสบการณ์ของผม collective code ownership เป็นคำตอบ นั่นคือสมาชิกทุกคนต้องสามารถแก้ได้ทุกส่วน ไม่มีเส้นแบ่งว่านี่โค้ดฉัน นี่โค้ดเธอ แล้วใช้เหตุการณ์ตอนมี code conflict หรือตอนทำ unit tests ของคนอื่นแดงเป็น trigger ให้เราลุกไปคุยกันเพื่อแลกเปลี่ยนข้อมูลและแก้ปัญหาร่วมกันโดยไม่แบ่งแยกว่าใครอยู่ทีมใคร เพราะเราทุกทีมล้วนทำ product เดียวกัน
Retrospective
พอเข้าใจวิธีที่คนหลาย ๆ คนรุมสร้าง product ร่วมกันอย่างไร ถัดมาคือเข้าใจว่าคนหลาย ๆ คนจะแบ่งปันการเรียนรู้ที่เกิดขึ้นใน sprint ที่ผ่านมาได้อย่างไร เพราะมันมีรายละเอียดและเรื่องราวที่คุยกันเยอะมาก ๆ ใน retrospective
โชคดีมาก ๆ ที่ปี 2019 ผมมีโอกาสได้ไป LeSS Conference ที่มิวนิค เสน่ห์อย่างหนึ่งของ LeSS Conference คือเค้าใช้กิจกรรมที่ทำ ๆ กันใน LeSS ในการจัด Conference ท้ายงานก็เลยมีการทำ retrospective สำหรับคนเป็นร้อยคน
ซึ่งทุกกลุ่มก็ทำ retrospective พร้อม ๆ กัน แต่เงื่อนไขคือ ของที่ถูกพูดจะต้องถูก catpure ไว้ลงบน flipchart หลังจากนั้นก็มีช่วงเวลา gallery walk ให้ทุกคนเดินชมผลลัพธ์จาก retrospective ของทีมอื่นได้ใน timebox ที่กำหนด
ช่วงนั้นผมก็ได้เห็นสิ่งที่บทสนทนาที่ทั้งเหมือนและต่างกับทีมตัวเอง ส่วนที่เหมือนก็รู้สึกสั่นพ้อง ส่วนที่ต่างก็ได้เปิดหูเปิดตา
เนี่ยแหละ ผมในฐานะสกรัมมาสเตอร์ พอผมเข้าใจวิธีเก็บ requirement, วิธีสร้างผลิตภัณฑ์ และ วิธีเรียนรู้ร่วมกันสำหรับคนหลายสิบคน ทำให้ผมคิดว่าผมเข้าใจ Large Scale Scrum ขึ้นมากเลย อย่างไรก็ดี ถ้าไปถามเพื่อนร่วมงานผมที่ชื่อเจนที่เป็น product owner ของ LeSS Example ที่เราทำด้วยกัน ก็ได้จะของอีก 3 อย่างมาที่แตกต่างกันนิดหน่อย เพราะมันมาจากมุมมองของ product owner
ถ้าจะให้เล่าย่อ ๆ เจนเห็นด้วยกับ 1. product backlog refinement และ 2. collective code ownership แต่สำหรับเจน อย่างที่ 3 คือการที่ทีม take ownership เรื่องการ clarify requirement เอง
บางที่ใช้สกรัมอาจจะมี discovery team และ delivery team อยู่แยกกัน โดย delivery team คือ development team ในสกรัม ส่วน discovery team เป็นผู้ช่วย product owner ที่ช่วย clarify requirement จาก business แล้วเอามาเล่าให้ทีมฟัง โดยอาจจะมีสมาชิกใน delivery team ผลัดเวรกันเข้ามาแจมใน discovery session Jeff Patton เรียกสิ่งนี้ว่า Dual track development
แต่สำหรับ Large Scale Scrum ซึ่งเป็นการกางสกรัมครอบทั้งองค์กร ทีมจะขยาย Definition of Done มาครอบคลุมเรื่องการ clarify requirement ด้วย ทำให้คนที่มีความสามารถในการ clarify requirement กลายเป็นสมาชิกในทีม และทำ discovery session ภายใน product backlog refinement พร้อมกับสมาชิกทุก ๆ คนในทีม มันเลยไม่มี 2 วงอีกต่อไป มันเป็นทีมนี่แหละ ที่ไปสัมภาษณ์ domain expert เองเพื่อเอาความรู้นั้นมาพัฒนาโดยไม่ผ่านใครเล่า ทำให้ product owner ที่ว่างจากการ clarify requirement พุ่งสมาธิไปที่การจัด priority สำหรับ item ล่วงหน้า 2–3 sprints ได้ (ประมาณ 100 ใบสำหรับ 8 ทีม, สมมติว่ารับทีมละประมาณ 4 ใบต่อ sprint)
เนี่ยแหละ อย่างที่ 3 ที่เจนมองเห็นจากมุม product owner ถ้าให้เจนมาเขียนบทความเอง คงเล่าได้อรรถรสกว่านี้พันเท่า ให้สกรัมมาสเตอร์เล่า ก็ได้คร่าว ๆ แค่นี้แหละ สุดความสามารถผมละ :P
