แปลข้อมูลจาก paper เรื่อง Teams that Finish Early Accelerate Faster: A Pattern Language for High Performing Scrum Teams
โดย paper นี้เขียนโดย 3 คน คือ
- Jeff Sutherland หนึ่งในผู้สร้าง Scrum และเป็นหนึ่งในกลุ่มผู้ร่วมประกาศ Agile Manifesto
- Neil Harrison
- Joel Riddle
สิ่งที่น่าสนใจจาก paper นี้ คือ รูปแบบของการสร้างทีม Hyperproductive Software Development ในกรอบของ Scrum
ประกอบไปด้วย 9 รูปแบบดังนี้
- Stable team
- Yesterday’s weather
- Swarming: One piece continuous flow
- Interrupt Pattern: Illigitimus Non Interruptus
- Daily clean code
- Emergency procedure
- Scrumming the Scrum
- Happiness metric
- Team that finish early accelerate faster
ข้อ 1-2 สำหรับทำให้ทีม sprint สำเร็จ
ข้อ 3-6 สำหรับช่วยให้ทีมแก้ไขปัญหาต่างๆ ที่เกิดขึ้น
ข้อ 7-8 สำหรับช่วยทำให้ทีมเข้าสู่สถานะ hyperproductivity
ข้อ 9 คือผลที่เกิดขึ้นกับทีม
จากทั้ง 9 ข้อ สามารถแบ่งออกเป็นกลุ่มย่อยๆ ได้ดังนี้
กลุ่มที่ 1 สำหรับช่วยให้ทีมพร้อม (Ready) ก่อนที่จะเริ่ม
Stable Team
ต้องรักษาทีมเอาไว้เสมอ ถ้าทีมทำงานเข้าขากันแล้ว อย่าไปแยกทีมหรือสลับคนไปมา
เพราะว่า ทีมที่เสถียรนั้นเขาจะรู้ความสามารถของทีม ว่าจะรับงานได้เท่าไร
ส่งผลทำให้ทางฝั่ง business สามารถทำนายได้ใกล้เคียงกับความเป็นจริงมากขึ้น
ไม่เช่นนั้นจะได้ผลที่ตรงกันข้าม
ในกรอบของ Scrum นั้น จำนวนสมาชิกในทีมประมาณ 3-9 คน
เป็นทีมที่มีขนาดเล็ก เนื่องจากต้องการลดการติดต่อสื่อสารที่ไร้ประสิทธิภาพ
และลดเส้นทางการพูดคุยที่มากเกินไป
แต่ทีมเล็กๆ ใช่ว่าจะประสบความสำเร็จเสมอไป
เช่น มีบางคนในทีมทำงานมากกว่า 1 project
ซึ่งส่งผลให้ศักยภาพของทีมลดลง
ดังนั้น ทีมจะต้องมีความเสถียรด้วยจึงจะประสบความสำเร็จ ( Small Team และ Stable Team )
Yesterday’s Weather
โดยปกติจำนวนของ point ที่ประเมินไว้แล้วทำสำเร็จใน sprint ล่าสุด
มักจะถูกใช้ในการทำนายเพื่อรับงานตามจำนวน point นั้นใน spring ถัดไปเสมอ
โดยทีมที่เสถียรแล้วจะรู้ว่าทีมตัวเองมีศักยภาพเท่าไร
และทีมจะใช้ข้อมูลจากอดีตมาช่วยทำนายอนาคต ( Yesterday’s Weather )
กลุ่มที่ 2 ช่วยให้ทีมสามารถทำงานใน Sprint สำเร็จ
Swarming
ให้ทุกๆ คนในทีมมาช่วยกันทำงานทีละ item ใน Sprint backlog
เพื่อทำให้แต่ละงานเสร็จเร็วที่สุดเท่าที่จะเป็นไปได้
แต่ละ item จะมีคนดูแลหลัก เรียกว่า Captain
โดยที่คนอื่นๆ ในทีมจะต้องช่วยเหลือเท่าที่ทำได้
เมื่อ item ทำเสร็จแล้ว ก็จะมีคนอื่นเป็น Captain สำหรับ item อื่นๆ ต่อไป
แล้วจะทำแบบนี้ไปเรื่อยๆ จนจบ Sprint
หลายต่อหลายทีมมักจะ fail เมื่อจบ Sprint
เนื่องจากแต่ละคนต่างทำงานของตนเอง มีงานทำมากมาย
โดยไม่ได้สนใจ item ที่มีความสำคัญสูงสุดก่อน
ดังนั้น Swarming จะช่วยทำให้ทีมช่วยกันทำงานในแต่ละ item ให้เสร็จเร็วที่สุด
แนวทางแบบนี้จะช่วยทำให้เห็นความเร็วที่แท้จริงของทีม
และนำไปใช้ในการทำนายต่อไป (Yesterday’s Weather)
Interrupt Pattern
การแบ่งเวลาสำหรับงานที่เข้ามาขัดจังหวะ
และจะไม่อนุญาตให้ทำงานเกินเวลาที่กำหนดไว้
สามารถจัดการการขัดจังหวะด้วยกฏ 3 ข้อดังต่อไปนี้
กฏข้อที่ 1
ทีมกำหนดเวลา buffer สำหรับงานที่ไม่ได้คาดหวังไว้ เช่น 30% ของเวลาใน Sprint
ดังนั้นการรับงานของทีมในแต่ละก็จะลดลงไป 30%
เช่นถ้าปกติรับงานได้ 60 point ต่อ sprint แล้วใน sprint ใหม่จะรับงานได้เพียง 40 point เท่านั้น เป็นต้น
กฏข้อที่ 2
ทุกๆ การร้องขอ หรือการขัดจังหวะ จะต้องผ่าน Product Owner เท่านั้น
เพื่อทำการคัดกรอง และ กำหนดลำดับความสำคัญ ตามแผนทางธุรกิจที่กำหนดไว้
แล้ว Product Owner จึงนำงานเหล่านั้นมาใส่ใน buffer ที่ทีมกำหนดไว้
กฏข้อที่ 3
ถ้างานมันล้น buffer ที่กำหนดไว้แล้ว ทีมจะต้องหยุดทำงานใน Sprint ทันที
แล้วมาทำการวางแผนใน Sprint นั้นใหม่อีกรอบ
และจะต้องแจ้งกลับไปยัง management ว่าจะต้องเลื่อนวันส่งมอบงานออกไปเมื่อไร
มีตัวอย่างของบริษัทที่ใช้ Scrum มีความยาวของ Sprint คือ 2 สัปดาห์
ทำมา 18 sprint ผลที่ได้คือ fail ทุกๆ sprint
แต่เมื่อนำกฏทั้งสามข้อมาใช้ พบว่า ทุกๆ sprint ประสบความสำเร็จ
ไม่มีการหยุดการทำงาน หรือ ยกเลิก sprint เลย
แถมมีความเร็วการทำงานที่สูงขึ้นเป็น 3 เท่าอีกด้วย
รูปแบบการจัดการงานที่เข้ามาขัดจังหวะ ส่งผลให้ทีมมีความเป็น self-organize
และหลีกเลี่ยงการหยุดทำงาน หรือ ยกเลิก sprint ลงไปได้
Daily Clean Code
การแก้ไขสิ่งที่ผิดพลาดๆ เล็กน้อย ในแต่ละวันช่วยทำให้ source code ของทีม ดีอยู่ทุกๆ วัน
ถ้าทีมไม่มาทำ clean code ทุกๆ วันแล้ว
เวลาที่ใช้สำหรับการกลับมาทำจะสูงมากๆ
จากผลวิจัยพบว่า ในการกลับมาแก้ไขนั้น ใช้เวลาถึง 24 เท่าตัว กันเลยทีเดียว
ดังนั้นมาทำ clean code กันทุกๆ วันเถอะนะ
โดยการทำ daily clean code นั้นทีมจะต้องกำหนดด้วยว่า
ทีมจะไม่สร้างปัญหา หรือกำหนดจำนวนปัญหาที่แก้ยาก ไปยัง Sprint ถัดๆ ไป
ทีมจะต้องช่วยกันลดจำนวน error หรือ ปัญหาต่างๆ ลงไปเรื่อยๆ
ด้วยการปรับปรุงไปในทุกวัน อย่างต่อเนื่อง
จนทำให้มีความสมดุลระหว่างความเร็วและคุณภาพของงาน
Emergency Procedure
เรียกง่ายๆ ก็คือ แผนสำรองยามฉุกเฉิน นั่นเอง
ทีมจะสังเกตง่ายๆ ได้จาก Burndown chart ของ sprint นั่นเอง
ถ้าพบว่าไม่มีการ burn เลยมาหลายวัน หรือมาถึงครึ่ง sprint แล้ว
ทาง ScrumMaster จะต้องเรียกใช้ Emergency Procedure ทันที
โดยที่ Emergency Procedure มีขั้นตอนการทำงานดังนี้ ( ทำเท่าที่จำเป็นเท่านั้นนะ ไม่ต้องทั้งหมด )
- เปลี่ยนแนวทางการทำงานของทีม เพื่อให้งานเสร็จ ลองทำในสิ่งที่แตกต่างออกไป
- หาคนช่วยเหลือในเรื่องต่างๆ ที่ทีมติดปัญหา
- ลดจำนวนของงาน หรือ ขอบเขตของงาน
- ยกเลิก Sprint หรือ วางแผนงานใหม่
- แจ้งผลกระทบของวันการส่งมอบให้ทาง management ทราบ
กลุ่มที่ 3 ทำให้เข้าสู่ Hyperproductivity
เป็นผลดีที่ได้รับจากสองกลุ่มแรก ประกอบกับรูปแบบต่างๆ ในกลุ่มนี้
จะทำให้ทีมเข้าสู่สถานะที่เรียกว่า Hyperproductivity
Scrumming the Scrum
ในกิจกรรมของ Scrum ที่เรียกว่า Sprint Retrospective นั้น
ให้ทีมเลือกปัญหาหรืออุปสรรคที่สำคัญมากๆ มา 1 เรื่อง
แล้วกำหนดแนวทางการปฏิบัติเพื่อ ทำให้ปัญหานั้นหายไป ก่อนที่ Sprint ถัดไปจะจบ
โดยให้เขียนเป็น item ใส่ acceptance test เข้าไปด้วยว่าจะเสร็จเมื่อใด
แล้วนำไปไว้ใน Sprint Backlog
และในกิจกรรม Sprint Review ก็ให้อธิบายถึง item นี้ด้วยว่าเป็นอย่างไร
การทำแบบนี้ จะช่วยให้ทีมสามารถปรับปรุงกระบวนการทำงาน
อย่างน้อย 1 เรื่องต่อ 1 sprint ซึ่งจะส่งผลให้ทีมมีความเร็วที่สูงขึ้นเรื่อยๆ
เพราะว่า สามารถแก้ไขปัญหาต่างๆ ลงไปได้นั่นเอง
Happiness Metric
ความสุขของคนในทีม เป็นตัววัดที่ดีมาก
เนื่องจากอารมณ์และความรู้สึกของทีม จะส่งผลอย่างมากต่อสิ่งที่กำลังทำ
ดังนั้นสิ่งที่ ScrumMaster ต้องค้นหาคือ สิ่งที่ทำให้ทีมมีความสุข
สามารถค้นหาด้วยการถามคำถาม 2 ข้อ กับทีม ดังนี้
- คุณรู้สึกดีอย่างไรต่อบริษัท
- คุณรู้สึกอย่างไรในกฏของทีม
อาจจะให้สมาชิกในทีมให้คะแนนความสุขตั้งแต่ 1 ถึง 5
โดยให้ทำการเก็บข้อความสุขของทีมไว้เสมอ
และดูว่าทีมรู้สึกอย่างไร และคอยดูว่าค่าเฉลี่ยความสุขของทีมนั้น
ส่งผลกระทบต่อความเร็วของการทำงานของทีมหรือไม่
Teams That Finish Early, Accelerate Faster
ทีมส่วนใหญ่มักจะรับงานมามากกว่าความสามารถของทีมเสมอ
ส่งผลให้ไม่สามารถทำงานได้เสร็จ หรือ อาจจะเสร็จแต่มีหนี้ให้ตามไปใช้เยอะมากๆ
ทำให้ทีมรู้สึกว่าแย่ ส่งผลต่อการพัฒนาของทีมเป็นอย่างมาก
ดังนั้น เริ่มต้นด้วยการรับงานไม่ต้องมากนัก เริ่มค่อยๆ รับเพิ่มเรื่อยๆ ตามศักยภาพของทีม
ในการรับงานเข้ามาในแต่ละ sprint ให้ใช้ Yesterday’s Weather
แล้วใช้งานรูปแบบต่างๆ ในการรับมือกับสิ่งที่เข้าขัดจังหวะ หรือ งานที่ไม่ได้คาดไว้
ซึ่งทำให้ทีมสามารถทำงานให้เสร็จได้เร็วขึ้น และจะเพิ่มขึ้นใน sprint ต่อๆ ไป
สามารถนำ Scrumming the Scrum มาใช้เพื่อมองดูทีมว่ามีปัญหาอะไรที่ยังต้องปรับปรุงให้ดีขึ้น
แล้วนำปัญหานั้นมาแก้ไขใน sprint ต่อไป
สุดท้ายแล้ว
รูปแบบทั้ง 9 ข้อนี้จะไม่เกิดผลเลย ถ้าไม่ลองพยายามทำตามอย่างเคร่งครัด
ดังนั้นแนะนำให้ทุกๆ ทีม ลองทำตามแต่ละรูปแบบ
หรือทำรวมๆ กันก็ได้ ตามความเหมาะสม
แล้วดูผลว่ามันช่วยปรับปรุงในเรื่อง ศักยภาพของทีม คุณภาพ และ ความสุขของคนในทีมหรือไม่
