คุณอาจจะไม่ต้องการ Sprint Review Meeting
หลังจากวิดีโอบันทึก session ของผมในงาน Agile Thailand 2016 ได้ถูกแชร์ออกไป (ขอบคุณกูโค้ดที่ช่วยบันทึกวิดีโอเอาไว้ครับ) คำถามที่ผมถูกถามจากคนที่ได้ดูมากที่สุดคือ “แล้วทำ sprint demo/review ตอนไหน?” 🤔
ตอนแรกผมค่อนข้างประหลาดใจกับคำถามนี้ เพราะผมไม่รู้ว่า sprint demo หรือ sprint review คืออะไร!? แต่พอคุยๆกับคนที่มีถามก็พอจะจับใจความได้ว่ามันคือกิจกรรมหนึ่งของ Scrum ที่พอจบ Sprint แล้วก็มาคุยกัน มา demo ให้ลูกค้าดูว่าทำอะไรไปบ้าง ทำนองนั้น ข้างล่างนี้คือที่ไป search มา:
So at the end of each sprint, a sprint review meeting is held. During this meeting, the Scrum team shows what they accomplished during the sprint. Typically this takes the form of a demo of the new features.
— Mountain Goat Software
ทำให้การ demo ตอนจบ Sprint เป็นเรื่องไม่จำเป็น
คำตอบของผมคือที่ทีมผมไม่มี Sprint Review Meeting เพราะมันได้กลายเป็นเรื่องไม่สำคัญไปแล้ว เรืองมันมีอยู่ว่าเรามี server ตัวหนึ่งที่ถูกเรียกว่า Demo server ไว้สำหรับส่งของที่เราทำเสร็จให้ลูกค้าดูและเราตั้งเป้าหมายร่วมกันไว้ว่า
💪 เราจะ deploy ขึ้น demo server อย่างน้อยวันละหนึ่งครั้ง
ความจริงคือเราไม่ได้แบบนั้นทุกวันหรอก แต่เราก็ทำมันได้บ่อยมากๆ ตัวเลขที่ผมมีคือเฉลี่ยแล้วเรา deploy 45 ครั้งต่อหนึ่งเดือนใน 6 เดือนหลังสุด บริษัทผมทำงานสัปดาห์ละ 4 วัน หนึ่งเดือนเราทำงาน 16 วัน เฉลี่ยแล้วเราจึง deploy 3 ครั้งต่อวัน
หมายความว่าลูกค้าจะได้เห็น feature ใหม่หรือการแก้ไข defect ทุกวัน(วันละหลายครั้ง) สิ่งที่คุณจะได้เมื่อคุณเดินทางมาถึงจุดนี้ก็คือ
- ลูกค้าเรียนรู้ระบบได้เองโดยไม่จำเป็นต้องให้เราสอน ทำไม? เพราะมันเปลี่ยนแปลงไปจาก version ก่อนหน้านี้เพียงเล็กน้อย
- ลูกค้าให้ feedback เราได้ทันที และ feedback นั้นจะมีขนาดเล็กมากเพราะมันเป็น feedback เพิ่มเติมเพียงเล็กน้อยจาก version ก่อนหน้า เมื่อมันเล็กมาก(โดยส่วนใหญ่)เราก็ไม่ต้องการอธิบายอะไรมากมาย เราสามารถเข้าใจได้โดยใช้เพียง daily meeting หรือแม้กระทั่งผ่าน chat
- ลูกค้าให้ feedback และได้เห็นการเปลี่ยนแปลงอยู่ตลอดเวลา สามารถลองใช้ได้ทันที จึงไม่มีเหตุผลอะไรต้องจัดการประชุมเพื่อ demo ระบบอีก
และนั่นเป็นที่มาของการหายไปของ Sprint review meeting — During this meeting, the Scrum team shows what they accomplished during the sprint — เพราะเรา show ไปหมดแล้ว
Next: Sprint Planning 15 นาที ⏰
อีกเป้าหมายหนึ่งที่เราตั้งขึ้นมาแล้วลองทำก็คือ ลดเวลา Sprint planning ให้เหลือน้อยที่สุด (จับได้แล้วใช่ไหมว่าพวกผมเกลียดการประชุม) ซึ่งจุดที่เรามาถึงได้ก็คือการทำให้ Sprint planning meeting ที่ทำตอนเริ่ม sprint เหลือแค่ 15 นาทีเท่านั้น (เวลาที่ดีที่สุดของเราคือ 5 นาที) ใช่ครับ มันเร็วพอๆกับ Daily scrum meeting เลย
ทำยังไง?
มันก็เป็นผลพวงมาจากการที่เรา demo ของได้ทุกวันนั่นแหละครับ พอลูกค้าสามารถให้ feedback เราได้รวดเร็ว พวกเขาก็จะวางแผนการ release ได้ดีขึ้น
แทนที่จะต้องรอคิดเรื่องนี้ตอนได้เห็นของตอนจบ sprint พวกเขาก็คิดเรื่องนี้ได้ทุกวัน
พอคิดได้ทุกวัน การวางแผนว่าจะทำอะไรบ้าง จะเอาอะไรบ้าง ก็ย้ายจาก Sprint planning meeting มารวมอยู่กับ Daily scrum meeting แทน
พอมันไม่เหลืออะไรให้คุยใน planning meeting เราก็ยกเลิก…ไม่ครับ เราไม่ยกเลิกเพราะเราอยากไปเจอหน้ากันบ้าง เจ้า Sprint planning meeting ก็เลยยังอยู่เพื่อให้ทีมผมกับทีมลูกค้าได้มาเจอกัน
อย่างที่ผมพูดเอาไว้ใน session: Phoenix ว่าหัวใจสำคัญที่สุดในการส่งมอบ software คือความสามารถในการส่งมอบที่รวดเร็ว ความเร็วนี้ไม่ใช่การเขียนโค้ดที่เร็วเพียงอย่างเดียว แต่คือการจัดการที่ดีเพื่อให้จินตนาการในหัวของลูกค้ากลายเป็นของที่จับต้องได้ในระยะเวลาที่สั้นที่สุด ยิ่งสั้นเท่าไหร่ เราจะรู้เร็วเท่านั้นว่าสิ่งที่เรามันถูกหรือผิด ซึ่งนั่นจะนำไปสู่การสร้างของที่ทั้งถูกใจและถูกต้องในท้ายที่สุด
จุดนี้คือสิ่งที่ทีมของผมจับจ้องและพยายามปรับปรุงอยู่เสมอ และเมื่อทำได้ดี มันก็เปิดโอกาสในการปรับปรุงจุดอื่นๆใน Process ของการทำงานของทีมได้ต่อ ซึ่งนั่นคือสาเหตุที่ตอนนี้เราไม่มี Sprint review meeting อีกต่อไปนั่นเองครับ
