เมื่อ Scrum ไม่ทำงาน: การเปิดเผยข้อบกพร่อง

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

1. ขาด วิสัยทัศน์ หรือ เป้าหมายที่ชัดเจน

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

หากไม่มีวิสัยทัศน์ที่ชัดเจน ทีมอาจเสียเสียงและสูญเสียการมุ่งมั่นได้ง่าย หากเจ้าของผลิตภัณฑ์ไม่สามารถให้วิสัยทัศน์และเป้าหมายของผลิตภัณฑ์ที่ชัดเจน Scrum จะไม่มีประสิทธิภาพ

2. การสื่อสารที่ไม่เป็นกลาง

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

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

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

ในกรณีใดก็ตามหากทีมขาดการสื่อสารที่มีประสิทธิภาพหรือไม่มีการมีส่วนร่วมร่วมกัน Scrum อาจไม่สามารถให้ผลลัพธ์ที่ต้องการได้

3. การปิดบังปัญหา

สามารถเกิดขึ้นเมื่อบางสมาชิกในทีมไม่ยอมรับปัญหา ไม่แก้ไขปัญหา แค่ปิดบังปัญหาหรือแก้ไขปัญหาในงานที่ทำเองอย่างไม่มีประสิทธิภาพ

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

สิ่งนี้ไม่เพียงแต่ป้องกันปัญหาเล็กๆ ไม่ให้กลายเป็นอุปสรรคใหญ่ แต่ยังสร้างสภาพแวดล้อมที่ส่งเสริมการแก้ไขปัญหาอย่างมีประสิทธิภาพ

4. ลำดับความสำคัญที่ไม่โปร่งใส

สมาชิกในทีมอาจตีความข้อความได้ต่างกันเนื่องจากขาดบริบทหรือความชัดเจน อาจไม่เข้าใจความเร่งด่วนหรือความสำคัญของงานบางส่วน ทำให้เกิดการจัดลำดับที่ไม่ถูกต้องหรือการตอบสนองที่ล่าช้า

สิ่งนี้เป็นที่ท้าทายอย่างยิ่งในทีมระยะไกลที่การสื่อสารทางเสียงอาจทำให้เกิดความเข้าใจผิดหรือความรู้สึกว่าห่างหายจากสมาชิกในทีม

ในกรณีนี้ กระดาน Scrum อาจเป็นทรัพยากรที่มีคุณค่า - ช่วยให้ทุกคนสามารถสื่อสารความคืบหน้างานของตนเองให้กับทีมที่เหลือได้อย่างชัดเจน นี่เป็นวิธีการส่งเสริมความโปร่งใสในทีม

อย่างไรก็ตาม การใช้ประโยชน์จากกระดาน Sc

6. ขาดความ มุ่งมั่น หรือ ทรัพยากรไม่เพียงพอ

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

องค์กรต้องรับรองว่าทีม Scrum ได้รับทรัพยากรและการฝึกอบรมที่เพียงพอและสมาชิกต้องมุ่งมั่นกับผลิตภัณฑ์และกันเอง นั่นคือเวลาที่เหตุการณ์เกิดขึ้น - เหตุการณ์ Scrum เช่น การประชุมรายวัน การวางแผนสแปรินต์ และการสรุปผล ให้โอกาสที่มีความสำคัญสำหรับการทำงานร่วมกันของทีม การสื่อสารและการแลกเปลี่ยนความคิด

13 บอร์ด Scrum ของ Easy Redmine ให้พื้นที่ทำงานที่มีการทำงานร่วมกันและการสื่อสารของทีมที่ดีขึ้นในเหตุการณ์เหล่านี้ มี 3 ประเภทของบอร์ด Scrum: 

1. บอร์ด Product Backlog ช่วยในการจัดการและกำหนดลำดับความสำคัญของ PBIs ที่นี่จะสร้าง Backlog และมีการปรับปรุง ผลลัพธ์คืองานที่ชัดเจนและมีลำดับความสำคัญพร้อมสำหรับสแปรินต์
   
   
   
   
2. บอร์ด Sprint Overview ช่วยทีมวางแผนและติดตามความคืบหน้าของสแปรินต์ปัจจุบัน ให้ภาพรวมชัดเจนของเป้าหมายและ PBIs ในสแปรินต์ ที่นี่บนบอร์ดนี้เรากำหนดเป้าหมายสแปรินต์ วางแผนสแปรินต์ระหว่างการสแปรินต์ และปิดสแปรินต์ระหว่างการทบทวน
   
   
   
   
3. สุดท้าย บอร์ด Team Sprint ให้ความสำคัญกับงานที่ทำรายวันและเป็นเครื่องมือที่ช่วยในการสร้างสรรค์ระหว่างการประชุมรายวัน ที่สมาชิกในทีมสามารถพูดคุยและอัปเดตบอร์ดเกี่ยวกับความคืบหน้าและอุปสรรคที่เป็นไปได้ ทีมแบ่งงานที่วางแผนไว้เป็นโพสต์-อิทธิพลเล็ก ๆ เพื่อให้มีภาพรวมที่ดีขึ้นและทำงานร่วมกันได้ดียิ่งขึ้น
   
   
   
   

7. เพิ่ม คอลัมน์เพิ่มเติม ในบอร์ดทีม

Scrum ไม่กำหนดวิธีการตั้งค่าบอร์ดทีมสแปรินต์ แต่เราทราบจากประสบการณ์ว่าเมื่อเราเริ่ม เพิ่มคอลัมน์เพิ่มเติมในบอร์ด Scrum มันอาจทำให้ ลดประสิทธิภาพของการใช้ Scrum ในรูปแบบที่แท้จริง 

ในขณะที่การปรับเปลี่ยนบางอย่างอาจดูเป็นประโยชน์สำหรับการตอบสนองความต้องการของทีมเฉพาะหรือการปรับปรุงการติดตาม แต่มันอาจเสี่ยงที่จะทำให้หลักการพื้นฐานของ Scrum ลดลง

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

เป็นความรับผิดชอบของทีมทั้งหมดที่จะ ทำให้ PBIs เสร็จสมบูรณ์โดยไม่คำนึงถึงบทบาทของบุคคล นั่นเป็นเหตุผลที่คอลัมน์ที่เน้นบทบาท (เช่น "การทดสอบ") ไม่แนะนำ เพราะบางครั้งมันสร้างความรู้สึกว่าบุคคลที่มีบทบาทเฉพาะไม่รับผิดชอบในการทำ PBIs นอกจากนี้ คอลั