จุดเริ่มต้นของ LeSSEx
ประมาณ 8 ปีที่แล้ว ช่วงนั้นผมกำลังโฟกัสกับการเป็น trainer อยู่ มีโค้ชตาม start up บ้าง แต่ล้วนเป็น engagement สั้น ๆ ไม่เกิน 3 เดือน ช่วงนั้น สกรัมค่อนข้างได้รับความนิยมในวงการ startup ของไทย สังเกตจากจะเห็น sprint backlog ตาม coworking space ต่าง ๆ startup ในไทยที่ผมได้พบเจอตอนนั้น ล้วนหยิบบาง practice ของสกรัมไปปรับใช้ไม่มากก็น้อย ส่วนในบริษัทใหญ่ ๆ ผมยังไม่ค่อยเห็นเท่าไหร่
แล้ววันหนึ่ง พี่รูฟ ก็ชวนผมไปโค้ชใน enterprise แห่งหนึ่งกัน…
พี่รูฟ: จั๊วะ ไปโค้ช enterprise กัน
ผม: ไม่เอาอ่ะ (ตอบไม่ต้องคิดเลย)
พี่รูฟ: ทำไมอ่ะ?
ผม: โค้ช startup 2–3 เดือนพี่ก็เห็น significant change ละโค้ช enterprise 2–3 ปียังไม่รู้เลยว่าจะได้เห็นอะไรเปลี่ยนแปลงไหม คนมันเยอะมาก และเงื่อนไขต่าง ๆ มันก็ซับซ้อนกว่ามาก
ผมในตอนนั้นยังไม่มีลูก ยังไม่ได้มีภาระทางบ้านอะไรต้องรับผิดชอบ เป็นช่วงเวลาที่มีทั้ง connection และกำลังที่จะทำงานอย่างเต็มที่ ผมให้ความสำคัญกับเวลาของตัวเองในวัยนั้นมาก เพราะผมรู้ว่ามันเป็นช่วงเวลาทองสั้น ๆ ที่อาจจะมีช่วงเดียวในชีวิต ผมไม่อยากใช้เวลาทองทั้งหมดกับการทำให้ชีวิตการทำงานของผู้คนในองค์กรเดียวดีขึ้น ผมอยากให้คนอีกหลาย ๆ องค์กรในไทยได้เห็นแนวการทำงานที่ผมวาดฝันไว้ จนกระทั่งพี่รูฟตอบผมกลับมา ซึ่งคำตอบนั้นเปลี่ยนชีวิตผมไปทั้งชีวิต
ตอนนี้ สกรัมเป็นอะไรที่เค้าใช้กันทั่วไปแล้วใน startup แต่ใน enterprise ยังไม่ค่อยมีคนใช้ ถ้าเราพิสูจน์ให้เห็นไม่ได้ว่า สกรัมมันเวิร์คใน enterprise ได้ด้วย สกรัมก็จะเป็นแค่ของเล่นใน startup ต่อไป อย่าลืมว่าคนกว่า 70% ในวงการไอทีไทย ส่วนใหญ่ใช้ชีวิตใน enterprise ไม่ใช่ใน startup ถ้าเราอยากให้วงการมันเปลี่ยนแปลง เราก็ต้องทำให้เค้าเห็นว่ามันทำได้
8 ปีต่อมา บริษัทออด-อี ได้มีโอกาสร่วมกันค้นหาวิธี adopt สกรัมกับองค์กรในหลาย segment ทั้ง telecom, investment, banking, หน่วยงานรัฐ, retail, real estate, พลังงาน, ฯลฯ
วันนี้ ผมเห็นว่าทุก enterprise ที่ผมรู้จัก ล้วนมีสกรัมทีมอยู่ในองค์กร เห็น head hunter ตามหา product owner และ Scrum master กันเต็มไปหมด บ่อยครั้งผมก็ได้เมลชวนว่า enterprise นี้เปิดรับ Scrum master หรือ project manager เงินเดือนดีมาก มาทำไหม :D
อีกสิ่งที่ผมเห็นคือ ในหลาย ๆ enterprise ให้สกรัมเป็นแค่โรงงานผลิตของ แล้วส่วนที่เหลือยังทำงานแบบเดิม หรือไม่ก็พยายามเอา Kanban มาครอบสกรัม เพื่อดูภาพรวม ซึ่งเป็นวิธีที่ผมคิดว่าไม่เวิร์ค ถ้าให้ตอบสั้น ๆ ผมจะสรุปว่า
การเอา Kanban มาครอบสกรัม ก็เหมือนเอากระดาษมาห่อไฟ ทำยังไงมันก็ไม่ยั่งยืน – ผมพูดเอง
ถ้าให้ตอบยาว ๆ สาเหตุที่ผมไม่เห็นด้วยกับการเอา Kanban board มาครอบสกรัม หรือเอา tribe มาครอบทีม หรือเอา Agile coach มาขี่คอ Scrum master มี 3 สาเหตุดังนี้
Dependency กับองค์กร
สกรัมเป็น Agile framework สำหรับ product development เราเอาแค่บางส่วนไปใส่ในสกรัมทีมไม่ได้ เพราะจะทำให้สกรัมทีมติด dependency ขององค์กร แบบนั้น สุดท้ายก็จะช้าเท่าเดิม
อไจล์ใน non-IT ไม่มีจริง
เหมือนกับที่ Marc Andreessen เขียนไว้ในบทความ Why software is eating the world ของเขาเมื่อ 9 ปีที่แล้ว ยุคนี้ซอฟต์แวร์มันลงไปในทุกอณูของชีวิตเราแล้ว วิชาเขียนโปรแกรมกลายเป็นวิชาบังคับเหมือนวิชาเลขในหลาย ๆ โรงเรียน หลาย ๆ องค์กรมี developer อยู่ใน business unit ของตัวเอง หรือไม่ก็หา partner ที่คอยพัฒนาให้เป็นประจำ เพราะกว่าจะรอ unit head ของฝั่ง business และไอ้ที align กัน sprint มันก็วนไป 2–3 รอบแล้ว ความประหยัดที่ได้จากเส้นแบ่งระหว่าง business กับ ไอที มันไม่เพียงพอให้เราชนะคู่แข่งได้อีกต่อไป หลายองค์กรเริ่มให้ความสำคัญกับความสร้างสรรค์ที่เกิดจากการเอา business กับไอทีมานั่งทำงานในทีมเดียวกันมากขึ้น
Retrospective พิการ
ความเปลี่ยนแปลงเกิดจากการเอาคนที่มีอำนาจที่จะเปลี่ยนแปลง กับคนที่มีข้อมูลว่าควรจะเปลี่ยนตรงไหนมานั่งคิดบนโต๊ะเดียวกัน ถ้าเราเอา Kanban มาครอบไอที ผู้มีอำนาจก็จะได้ข้อมูลที่จะเปลี่ยนแปลงจากรายงานแห้ง ๆ ซึ่งจริงแค่ไหนก็ไม่รู้ ผมเห็นผู้บริหารหลายท่านเจอกับปัญหาเดิม ๆ วนมาซ้ำแล้วซ้ำเล่า ไม่ว่าจะปรับอะไรไปก็ตาม ปัญหาเดิม ๆ ก็วนกลับมาอีก ซึ่งเป็นสัญญาณว่ามีอะไรซักอย่างผิดปรกติ
ถ้ามีโต๊ะมหัศจรรย์ที่ผู้บริหารกับสมาชิกของทีมสามารถนั่งแก้ปัญหาร่วมกันได้ก็คงดี บนโต๊ะนั้น เราจะพบว่าปัญหาเดิม ๆ ของทีมมันจะเปลี่ยนไปทุกครั้ง เพราะรายละเอียดปลีกย่อยในปัญหามันไม่เหมือนเดิมซักครั้ง มันมากับความเจ็บปวดที่แตกต่างกัน และการสนับสนุนที่ได้จากการตัดสินใจอย่างยากลำบากของผู้บริหารเพื่อจะช่วยทีมแก้ปัญหามันก็จะไปถึงทีม ทีมจะรู้สึกได้ถึงการสนับสนุนซึ่งเติมความภักดีและกำลังใจให้ทีมต่อสู้ใน sprint ถัดไป
สกรัมเอาทุกคนที่เกี่ยวข้องกับการพัฒนามาอยู่ในทีม จะได้ไม่ต้องมานั่งนัดประชุมกัน เพราะคนเหล่านี้ควรมีจังหวะเดียวกัน และผู้บริหารควรจะมีหน้างานจริงเพียงอันเดียวเพื่อจะมาดูงานว่าน้อง ๆ ติดอะไร ต้องการการสนับสนุนตรงไหน การยอมรับที่จะแยกฟังก์ชันงานอื่น ๆ ออกไปเป็น dependency ของสกรัมทีมจำกัดประโยชน์ที่เราจะได้จากสกรัมอย่างมหาศาล และขอบเขตการพัฒนาจะถูกจำกัดแค่ภายในทีม แต่ไปไม่ถึงทั้งองค์กร
ผมเชื่อใน LeSS
Large Scale Scrum (LeSS) เป็นสิ่งที่ Bas กับ Craig คิดขึ้นมาว่าจะบิดสกรัมให้น้อยที่สุดเพื่อให้มันเวิร์คสำหรับทั้งองค์กรที่มีขนาดใหญ่กว่า 1 สกรัมทีมได้ยังไง
ซึ่งผมคิดว่าถ้าจะทำให้ LeSS เป็นมากกว่าภาพสวยงามในนิทาน ก็ต้องพิสูจน์ให้มันเห็นว่าเวิร์คได้ในชีวิตจริง
ออด-อีทีมไทยเลยตัดสินใจหาอาสาสมัครจากชาว ODDS ประมาณ 260 คนตอนนี้ ที่อาสาจะมาเป็นตัวอย่างที่จะทำงานให้ใกล้เคียงกับ LeSS ในตำราที่สุด เพื่อให้ผู้คนมาดูได้ว่ามันเวิร์คยังไง แล้วเราก็เลือกแมวน้ำมาเป็นทีมแรกที่เราจะชวน
ก่อนจะเริ่ม flip ให้เข้ากับ structure ของ LeSS ทีมแมวน้ำเป็น 1 ทีมใหญ่ที่มีขนาด 16 คน มี daily Scrum เดียวกัน มี sprint backlog เดียว ทำ sprint 1 week และมีเจนเป็นทั้ง product owner และ Scrum master ในคนเดียวกัน
เรา kick off ด้วย Volunteering
จาก The three principles สำหรับ LeSS Adoption ข้อสาม Use Volunteering เค้าบอกว่าให้หาอาสาสมัครตอนที่จะ form team ใหม่ ผมในฐานะ Scrum master ก็เลยถามสมาชิกในทีมแมวน้ำว่า เรามีเจตนาอยากจะทำตัวอย่างให้คนในวงการไอทีไทยดูแบบนี้ พวกเค้าพวกเค้าสนใจจะเข้าร่วมแค่ไหนตั้งแต่ 1–5 โดย 1 คือไม่อยากเลย และ 5 คือไม่อยากพลาด และเจนในฐานะ product owner ของทีมนี้ก็ให้ความมั่นใจกับทีมว่าเค้าตอบอะไรก็ได้ แล้วเราจะมาหาทางออกร่วมกัน เช่น ถ้าส่วนใหญ่บอกว่าจะไม่ลอง พวกเราคงไปชวนทีมอื่นเล่น ถ้าครึ่ง ๆ บอกไม่อยากลอง คงมีครึ่งหนึ่งเป็น LeSS และอีกครึ่งก็ทำตัว department อื่นในองค์กรใน LeSS adoption แล้วเราก็เริ่ม work ไปจากตรงนั้น หรือถ้าส่วนน้อยบอกว่าไม่อยากลอง เราอาจจะต้องมาหาทางออกร่วมกันว่าเค้าอยากเข้าเมืองตาหลิ่วแล้วหลิ่วตาตามเพื่อทำงานเดิมมากกว่า หรืออยากจะหาทีมใหม่ใน ODDS ที่สิ่งแวดล้อมใกล้เคียงกับแบบที่เค้าอยากอยู่มากกว่า แต่ไม่ว่าเค้าจะเลือกทางไหน มิตรภาพของเราและการงานเค้าจะไม่ได้รับผลกระทบ
ผมบอกพวกเค้าว่าถ้ามีตัวเลขในใจแล้วให้ชูกำปั้นขึ้นมา มันเป็น 2 นาทีที่นานมากสำหรับผม
ปรากฏว่าทุกคนตอบ 5! ซึ่งทำให้ผมประหลาดใจ และก็แอบดีใจมาก (ผมพยายามมากที่จะไม่แสดงมันออกไป) ด้วยเหตุผลต่าง ๆ กันไป เช่น บางคนมองว่าเป็นโอกาสที่จะได้เรียนรู้ บางคนบอกว่ายังไงก็ได้เงินเหมือนเดิม และถ้ามันอาจจะเป็นประโยชน์กับวงการไอทีไทยด้วยก็ถือเป็นโบนัส และกิจกรรมแรกของทีม LeSSEx (อ่านว่า เลส-เอ็กซ์ ที่ย่อมาจาก LeSS Example) ก็เริ่มต้นขึ้น
เผาธงทีมเก่า
ผมให้พวกเค้าเริ่มด้วยการเอา A4 มาสร้างป้ายชื่อแมวน้ำขึ้นมาโดยทุกคนต้องมีส่วนขีดเขียนในป้ายชื่อนั้น เสร็จแล้วให้ทุกคนฉีกคนละทบแล้วเอามาคืนผมเพื่อเป็นสัญลักษณ์ของการจบวัฒนธรรมของทีมเดิม เพื่อเปิดพื้นที่ให้วัฒนธรรมของทีมใหม่เบ่งบาน
แล้วก็ต่อด้วย self-designing team exercise โดยมี rules ดังนี้
- ทีมต้องมีขนาด 5–9 คน (ตาม Scrum rules)
- ทุกทีมมีจำนวนสมาชิก พอ ๆ กัน
- ทุกทีมสามารถทำได้ตั้งแต่เก็บ requirement, UX, UI, เขียนโค้ด, test, deploy ของขึ้น production
- ถ้ามีช่วงอายุยิ่งต่าง ยิ่งได้คะแนนเพิ่ม เช่น ช่วง 20+, 30+, 40+
- ยิ่งมีหลายเพศ ยิ่งได้คะแนนเพิ่ม
- ยิ่งมีสถานบันที่จบมาเยอะ ยิ่งได้คะแนนเพิ่ม
- ทุก ๆ 10 ซ.ม. ของส่วนสูง จะได้ 1 คะแนน เช่น 150+, 160+, 170+, …
แล้วทีม Black cat กับทีม Pilot ก็ถือกำเนิดขึ้น!
หลังจากนั้นพวกเค้าก็ใช้เวลาทำป้ายชื่อทีมใหม่ ตกลง working agreement ของแต่ละทีม แล้วตกลง Definition of Done ของทีมตัวเอง แล้วผมก็สรุป shared Definition of Done สำหรับทั้ง product ให้พวกเค้าและ product owner รับรู้ร่วมกัน และบอกทั้งสองทีมให้ช่วยกันและกันขยาย DoD ของอีกทีมเพื่อให้ shared DoD ของทั้ง product เรากว้างขึ้น
ถ้าอยากรู้เรื่อง self designing team workshop มากกว่านี้ สามารถอ่านได้จาก case study นี้ของ BMW Group ในบทความที่เกี่ยวข้องด้านล่างนะครับ
9 Sprint ผ่านไป…
ผมใช้เวลาช่วงแรกทำความรู้จักกับทีมนี้ จำชื่อทีละคน แพร์กับทุกคน ให้รู้ว่าใครชำนาญตรงไหน ชอบสไตล์การแพร์แบบไหน และเข้าใจ character ของทั้ง 2 ทีมที่เกิดใหม่ว่าในฐานะทีม เค้าอยู่กันด้วยธรรมเนียมปฏิบัติอย่างไร
ผ่านมา 9 sprints ผมถามตัวเองว่า อะไรที่เด่นสำหรับทีมนี้? คำตอบผุดออกมาคือ พวกเค้าเขียนโค้ดแบบ single branch โดยไม่ทำ TDD ซึ่งผมไม่ค่อยเห็นทีมที่ทำแบบนี้ได้ ต้องยอมรับว่าพวกเค้าเขียนโค้ดและ design software เก่งจริง ๆ
ความช่วยเหลือที่พวกเค้ามีให้กันเป็นเรื่องน่าทึ่งมาก สมาชิกทุกคนมีมากกว่าหนึ่งทักษะ ทีม pilot ตกลงกันว่า ทุก sprint ต้องไป pair กับคนอื่นทำของที่ตัวเองไม่ถนัดที่สุด 1 อย่าง ไม่ว่าจะเป็นการเขียน frontend, backend, deploy ของขึ้น server, automate test, ฯลฯ ขณะที่ทีม Black cat ตกลงกันว่าต้องสลับที่นั่งทุก sprint เพราะธรรมชาติพวกเค้า เค้าจะแพร์กับคนที่นั่งใกล้ ๆ กัน
ผมได้เรียนรู้เกี่ยวกับ LeSS เยอะขึ้นมาก มีหลายอย่างที่ผมกับเจนถอดบทบาท Scrum master และ product owner วางไว้ แล้วมานั่งถกกันในฐานะนักเรียน LeSS ว่าในสถานการณ์แบบนี้ ต้องปรับใช้ยังไง ถึงจะใกล้เคียง ideal ที่สุดเพื่อให้คู่ควรที่จะเป็นตัวอย่างให้ผู้คนมาดู
ถึงตอนนี้ ผมคิดว่าวิธีที่พวกเค้าทำ Multi-team Product Backlog Refinement เป็นตัวอย่างหนึ่งที่น่าสนใจ เพราะผมไม่ค่อยเห็นคนปริมาณมากขนาดนี้ clarify requirement ปริมาณมหาศาล (ใน LeSS แต่ละ sprint เราต้อง clarify requirement เยอะมากเพื่อให้พอแต่ละ sprint) ได้อย่างมีประสิทธิภาพขนาดนี้
ยังมีอีกหลายเรื่องที่ผมได้เรียนรู้จากการทดลองนี้ ไว้ผมจะค่อย ๆ แกะมาเล่าให้ฟังทีละเรื่องนะครับ ผมตั้งใจจะบันทึกชั่วขณะเหล่านี้ไว้ในบทความ เผื่อมันจะเป็นประโยชน์กับคนอื่น
สำหรับใครที่อาจจะสนใจมาดูให้เห็นกับตาว่ากลุ่มคนเล็ก ๆ ที่ตั้งใจสุดชีวิตที่จะทำ Large Scale Scrum ให้ใกล้เคียงกับตำราที่สุดเป็นยังไง สามารถติดต่อมาหาผมหรือเจนก็ได้นะครับ ผมเชื่อว่าการมาเยี่ยมเยียนของคุณน่าจะเติมกำลังใจให้กับสมาชิกทุกคนในทีมไม่น้อยทีเดียว
