Scrum Guide | 39. ข้อผิดพลาดที่พบบ่อยที่สุดระหว่าง Sprint Retrospective

Sprint Retrospective เป็นกิจกรรมที่สิ้นสุดทุก Sprint และในขณะเดียวกันก็เป็นการประชุม Scrum Team ที่ยากที่สุดครั้งหนึ่ง ข้อผิดพลาดที่พบบ่อยที่สุดระหว่าง Sprint Retrospective เกี่ยวข้องกับการหลีกเลี่ยงการสนทนาเกี่ยวกับประเด็นที่ละเอียดอ่อน ตลอดจนการขาดความมุ่งมั่นที่เป็นรูปธรรมซึ่งนำไปสู่การแก้ไขปัญหาที่ได้รับการวินิจฉัยแล้ว

ข้อผิดพลาดทั่วไประหว่าง Sprint Retrospective – สารบัญ:

1. บทนำ
2. ความโปร่งใสไม่เพียงพอ
3. เน้นปัญหาครั้งเดียวหรือความสำเร็จ
4. การเป็นตัวแทนของเจ้าของผลิตภัณฑ์มากเกินไป
5. ปัญหาการจัดการตนเอง
6. ภาระผูกพันมากเกินไป
7. ข้อผิดพลาดทั่วไประหว่าง Sprint Retrospective – Summary

บทนำ

ข้อผิดพลาดระหว่าง Sprint Retrospective เป็นเรื่องปกติธรรมดามาก เนื่องจากเป็น หนึ่งในการประชุมที่ยากที่สุด ในการดำเนินการให้สำเร็จ เนื่องจากต้องใช้วุฒิภาวะอย่างมากจากทีม นั่นเป็นเหตุผลที่ควรพิจารณาปัญหาที่เกิดขึ้นบ่อยที่สุดในทีมอื่น เพื่อให้คุณสังเกตเห็นอาการได้ง่ายขึ้นเมื่อดำเนินการ Sprint Retrospective ในทีม Scrum ของคุณ

ความโปร่งใสไม่เพียงพอ

ตาม Scrum Guide สมาชิกแต่ละคนในทีม Scrum มีหน้าที่ต้องซื่อสัตย์และกล้าหาญในการแสดงข้อกังวลและแสดงความคิดเห็นของพวกเขาในระหว่าง Sprint Retrospective อย่างไรก็ตาม ในทางปฏิบัติ ความมุ่งมั่นเพื่อความโปร่งใสนั้นเป็นสิ่งที่เรียกร้องอย่างมาก ด้วยเหตุนี้ สมาชิก Scrum Team จึงมักพยายามหลีกเลี่ยง

ปัญหาหนึ่งที่ยากต่อการระบุและแก้ไขคือการหลีกเลี่ยงการอภิปรายเกี่ยวกับข้อบกพร่องที่สังเกตพบในงานของทีม Scrum นี้สามารถนำไปสู่ปัญหาร้ายแรงมากขึ้นในระยะยาว

ภารกิจของ Scrum Master คือ การจับตาดูสถานการณ์ในทีมอย่างใกล้ชิด และสนับสนุนให้สมาชิกในทีมทุกคนมีความกระตือรือร้นในเชิงรุกตั้งแต่เริ่มต้น Sprint Retrospective

เน้นปัญหาครั้งเดียวหรือความสำเร็จ

ปัญหาอีกประการหนึ่งที่อาจเกิดขึ้นระหว่าง Sprint Retrospective คือ การให้ความสนใจไม่เพียงพอต่อพฤติกรรมของทีมที่เป็นวัฏจักรและซ้ำซาก และผลกระทบต่อประสิทธิภาพของทีม

เป็นการดีเสมอที่จะแสดงความยินดีกับสมาชิก Scrum Team หากพวกเขาประสบความสำเร็จอย่างยอดเยี่ยม อย่างไรก็ตาม Sprint Review ไม่ควรอุทิศให้กับการเฉลิมฉลอง เช่นเดียวกับความล้มเหลว หากมีบางอย่างล้มเหลวเนื่องจากเหตุบังเอิญหรือข้อผิดพลาดที่ได้รับการวินิจฉัยแล้ว ไม่ควรวิเคราะห์เหตุการณ์มากเกินไปในระหว่างการทบทวน Sprint

อย่างไรก็ตาม บางครั้งทีมงานได้อุทิศส่วนใหญ่ของ Sprint Retrospective ให้กับเหตุการณ์ดังกล่าว โปรดจำไว้ว่าจุดประสงค์ของ Sprint Retrospective คือการ มองหาวิธีปรับปรุงงานประจำวันของทีม ดังนั้น การประชุมไม่ควรหมุนไปรอบ ๆ ความสำเร็จครั้งเดียวหรือปัญหาที่มีแนวโน้มสูงที่จะไม่เกิดขึ้นอีก

การเป็นตัวแทนของเจ้าของผลิตภัณฑ์มากเกินไป

ในหลายองค์กร ตำแหน่ง Product Owner เท่ากับตำแหน่ง Product Manager Product Owner มักถูกมองว่าเป็นหัวหน้าทีม Scrum ด้วยเหตุนี้ จึงเกิดที่ทีมพัฒนาไม่ต้องการพูดถึงปัญหาการทำงานเป็นทีมต่อหน้าเขา

นั่นคือเหตุผลว่าทำไมการ สร้างความไว้วางใจซึ่งกันและกันระหว่างทีมพัฒนาและเจ้าของผลิตภัณฑ์ จึงเป็นสิ่งสำคัญ น่าเสียดายที่กระบวนการสร้างความไว้วางใจนั้นยากและยาวนาน นั่นเป็นเหตุผลที่บางครั้งจึงเป็นความคิดที่ดีที่เจ้าของผลิตภัณฑ์จะเลิกเข้าร่วม Sprint Retrospective ทั้งหมดหรือบางส่วนเพื่อเว้นที่ว่างสำหรับส่วนที่เหลือของทีมเพื่อพูดคุยกันอย่างอิสระ

ปัญหาการจัดการตนเอง

การจัดการตนเองหมายความว่าสมาชิกในทีม Scrum จะตัดสินใจด้วยตัวเองว่าใครจะทำงานบางอย่าง เมื่อใดและอย่างไร ในช่วง Sprint Retrospective ทีมงานจะพูดคุยถึงผู้คน ปฏิสัมพันธ์ของพวกเขา และแนวทางปฏิบัติของทีม จากนั้นจะตัดสินใจว่าปัญหาใดที่ต้องแก้ไขใน Sprint ที่จะเกิดขึ้น จะทำอย่างไรร่วมกับผู้รับผิดชอบในการดำเนินการ

หากเกิดปัญหาร้ายแรงขึ้นในทีมจัดการตนเอง อาจมีการล่อลวงในทีม Scrum ให้สละความรับผิดชอบ

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

ภาระผูกพันมากเกินไป

ทีม Scrum ที่กระตือรือร้นซึ่งปฏิบัติงานตาม เสาหลักสามประการของประสบการณ์นิยม ได้แก่ ความโปร่งใส การตรวจสอบ และการปรับตัว อาจประสบปัญหาในการให้คำมั่นสัญญาหลายครั้งมากเกินไปในคราวเดียว

หากคำมั่นสัญญาที่ทำโดย Scrum Team ระหว่าง Sprint Retrospective มากเกินไป จะมีความเสี่ยงสูงที่:

• จะไม่มีการปฏิบัติตามข้อผูกพันอย่างถูกต้อง
• ภาระผูกพันบางอย่างจะไม่ถูกดำเนินการเลย
• การเปลี่ยนแปลงที่เกิดขึ้นจะไม่ถาวร

ดังนั้นแนวปฏิบัติที่ดีคือทำการปรับปรุงไม่เกินสี่ครั้งในแต่ละ Sprint ซึ่งช่วยให้มีการปรับปรุงประสิทธิภาพของทีมอย่างค่อยเป็นค่อยไปแต่มีประสิทธิภาพ

ข้อผิดพลาดทั่วไประหว่าง Sprint Retrospective – Summary

เนื่องจาก Sprint Retrospective เป็นเหตุการณ์ที่ท้าทาย ปัญหามักเกิดขึ้นระหว่างการดำเนินการ เพื่อจัดการกับพวกมันได้ง่ายขึ้น คุณควรสังเกตสิ่งที่เกิดขึ้นบ่อยที่สุด ข้อผิดพลาดทั่วไประหว่าง Sprint Retrospective คือ:

• ความโปร่งใสไม่เพียงพอ – เมื่อสมาชิก Scrum Team ล้มเหลวในการจัดการกับความจริงใจในสถานการณ์ของทีมที่ยากขึ้น
• เน้นที่ปัญหาหรือความสำเร็จแบบครั้ง เดียว - เมื่อสมาชิก Scrum Team ให้ความสำคัญกับการพูดคุยถึงความสำเร็จและความล้มเหลว แทนที่จะพูดถึงประสิทธิภาพในระยะยาวของงานของทีม
• Product Owner เป็นตัวแทนมากเกินไป – เมื่อสมาชิกในทีม Scrum ปฏิบัติต่อเจ้าของผลิตภัณฑ์ด้วยความไว้วางใจที่จำกัดราวกับว่าเขาหรือเธอเป็นคนนอกทีมหรือหัวหน้างาน
• ปัญหาการจัดการตนเอง – เมื่อสมาชิก Scrum Team พยายามเปลี่ยนความรับผิดชอบต่อปัญหาและการตัดสินใจ

หากคุณชอบเนื้อหาของเรา เข้าร่วมชุมชนผึ้งที่วุ่นวายบน Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest

ผู้เขียน: แคโรไลน์ เบ็คเกอร์

ในฐานะผู้จัดการโครงการ Caroline เป็นผู้เชี่ยวชาญในการค้นหาวิธีการใหม่ๆ เพื่อออกแบบเวิร์กโฟลว์ที่ดีที่สุดและเพิ่มประสิทธิภาพกระบวนการ ทักษะในการจัดองค์กรและความสามารถในการทำงานภายใต้แรงกดดันของเวลาทำให้เธอเป็นคนที่ดีที่สุดในการเปลี่ยนโครงการที่ซับซ้อนให้กลายเป็นจริง

ดูกระทู้ทั้งหมด

คู่มือการต่อสู้:

1. อภิธานศัพท์ของคำศัพท์พื้นฐาน บทบาท และแนวคิด
2. Scrum คืออะไร?
3. ค่าการต่อสู้
4. วิธีใช้งาน Scrum ในบริษัทของคุณ
5. Scrum Team - มันคืออะไรและทำงานอย่างไร?
6. เจ้าของผลิตภัณฑ์คือใคร?
7. ข้อผิดพลาดที่พบบ่อยที่สุดของ Product Owner
8. Scrum Master คือใคร?
9. ลักษณะของ Scrum Master ที่ดี
10. ข้อผิดพลาดที่พบบ่อยที่สุดของ Scrum Master
11. สถิติและตัวชี้วัดใดที่ Scrum Master ควรติดตาม
12. ความร่วมมือระหว่าง Product Owner และ Scrum Master
13. ทีมพัฒนาใน Scrum
14. ข้อผิดพลาดที่พบบ่อยที่สุดของ Developers
15. สิ่งประดิษฐ์การต่อสู้
16. สเกลการต่อสู้
17. Sprint Backlog
18. Backlog สินค้าคืออะไร?
19. เรื่องราวของผู้ใช้คืออะไร?
20. สร้าง User Story ที่ดีที่สุดกับ INVEST
21. ข้อผิดพลาด User Story ที่พบบ่อยที่สุด
22. เกณฑ์การยอมรับเรื่องราวของผู้ใช้
23. การประมาณค่าและจุดเรื่องราวใน Scrum
24. การวางแผนโป๊กเกอร์
25. เกมประเมินทีม
26. กำหนดส่วนเพิ่ม
27. เหตุการณ์การต่อสู้
28. Sprint ใน Scrum คืออะไร?
29. ความมุ่งมั่นของทีม Scrum - เป้าหมายผลิตภัณฑ์ เป้าหมาย Sprint และคำจำกัดความของความสำเร็จ
30. แผนภูมิ Burndown คืออะไร?
31. จะสร้างและตีความแผนภูมิเบิร์นดาวน์ได้อย่างไร?
32. ข้อดีและข้อเสียของแผนภูมิการเบิร์นดาวน์
33. กระดาน Kanban ใน Scrum และ Scruban
34. Velocity in Scrum - ความเร็วของทีมพัฒนา
35. การต่อสู้รายวัน
36. การวางแผนการวิ่ง
37. Sprint Review
38. Sprint Retrospective คืออะไร?
39. ข้อผิดพลาดทั่วไประหว่าง Sprint Retrospective
40. บำรุง Backlog สินค้า