เทมเพลต Sprint Retrospective สำหรับทีมวิศวกรรม

ทำไม Retro ส่วนใหญ่ถึงไม่ก่อให้เกิดการเปลี่ยนแปลง

Sprint Retrospective มีปัญหาเชิงโครงสร้างที่เทมเพลตไม่แก้ คือทีมสร้างไอเดียการปรับปรุงแต่ไม่ได้ทบทวนมัน Retro ผลิต action item ห้าข้อ Retro ถัดไปเปิดด้วยกระดานเปล่า ปัญหาเดิมก็โผล่ขึ้นมาอีก

เทมเพลตด้านล่างฝังการทบทวนไว้ในช่วงเปิดประชุมเพื่อไม่ให้ถูกข้าม การเปลี่ยนแปลงเพียงจุดเดียวนี้ช่วยเรื่องประสิทธิภาพของ Retro ได้มากกว่าการปรับรูปแบบใดๆ

วาระการประชุม (คัดลอกไปใช้ได้เลย)

ระยะเวลา: 60 นาทีสำหรับ Sprint 2 สัปดาห์ 45 นาทีสำหรับ Sprint 1 สัปดาห์
รูปแบบ: มีผู้ดำเนินรายการ พร้อมบอร์ดร่วมแบบ async (Miro, FigJam, Notion — เลือกได้ตามใจ)

ส่วนที่ 1 — การทบทวน action item (10 นาที)

อ่าน action item ของ Sprint ที่แล้วทีละข้อ
ทำเครื่องหมายแต่ละข้อ: เสร็จแล้ว / กำลังทำ / ยกเลิก (เหตุผลสั้นๆ สำหรับข้อที่ยกเลิก)
ยกข้อที่ยังไม่เสร็จไปข้างหน้า อย่าถกเถียงมันใหม่ตอนนี้

ส่วนที่ 2 — ภาพรวมข้อมูล (5 นาที)

Velocity ของ Sprint เทียบกับเป้า
งานที่ไม่ได้วางแผนซึ่งใช้เวลาเกินหนึ่งวัน
เหตุการณ์หรือการเข้าเวร
การเปลี่ยนขอบเขตกลาง Sprint
นำข้อมูลขึ้นหน้าจอโดยยังไม่ต้องถกเถียง

ส่วนที่ 3 — สิ่งที่ทำได้ดี (10 นาที)

ทีมเพิ่มรายการแบบ async ก่อนการประชุม หรือภายใน 3 นาทีแรก
ถกเถียง 2-3 อันดับแรก ข้ามรายการที่เห็นตรงกันอยู่แล้วชัดเจน
อย่าเสียเวลากับสิ่งที่นำไปปฏิบัติไม่ได้

ส่วนที่ 4 — สิ่งที่ควรปรับปรุง (15 นาที)

รูปแบบเดียวกัน: ป้อนข้อมูลแบบ async ถกเถียงรายการที่มีสัญญาณสูงสุด
สำหรับแต่ละรายการ: เกิดขึ้นครั้งเดียวหรือเป็นรูปแบบที่วนซ้ำ? เฉพาะรูปแบบเท่านั้นที่กลายเป็น action item
หน้าที่ของผู้ดำเนินรายการคือเปลี่ยน "เรื่องนี้น่าหงุดหงิด" ให้เป็นอะไรที่เจาะจงและเปลี่ยนแปลงได้

ส่วนที่ 5 — Action item (15 นาที)

แต่ละรายการต้องมี: รายละเอียด ผู้รับผิดชอบหนึ่งคน (ไม่ใช่ "ทีม") กำหนดส่ง
ตั้งเป้าไว้ไม่เกิน 2-3 รายการ มากกว่านั้นจะทำให้ความรับผิดชอบเจือจาง
ยกรายการที่ยังไม่เสร็จจากส่วนที่ 1 มาต่อ

ปิดท้าย (5 นาที)

ประเมิน Retro เองแบบ +/-/delta อย่างรวดเร็ว
ยืนยันว่าสรุปจะส่งออกก่อนสิ้นวัน

อะไรที่รูปแบบ Retro ยอดนิยมพลาดไป

Start/Stop/Continue และ What Went Well/What to Improve/Action Items ต่างก็เป็นรูปแบบที่ใช้ได้ ปัญหาไม่ได้อยู่ที่รูปแบบ — แต่อยู่ที่เทมเพลตแทบไม่เคยฝังขั้นตอนการทบทวนไว้ตอนต้น ขั้นตอนนั้นเป็นสิ่งเดียวที่สร้างความต่อเนื่องของความรับผิดชอบจาก Retro หนึ่งไปยังอีกอันหนึ่ง หากไม่มีมัน Retro ก็เป็นเครื่องผลิตความรู้สึก ไม่ใช่เครื่องผลิตการเปลี่ยนแปลง

เทมเพลตยังไม่จัดการเรื่องวินัยของกรอบเวลาด้วย "สิ่งที่ควรปรับปรุง" ยืดเยื้อแทบทุกครั้งเพราะมันดึงอารมณ์มากกว่า "สิ่งที่ทำได้ดี" หากไม่มีกรอบเวลาที่เข้มงวด Retro 60 นาทีก็จะกลายเป็นการถกเถียง 90 นาทีและ action item ที่รีบทำ 5 นาทีตอนท้าย ทั้งที่ action item คือส่วนเดียวที่เปลี่ยนแปลงอะไรได้

ช่องว่างที่สาม: action item ถูกเขียนเป็นคำสั่งกำกวม "ปรับปรุงการสื่อสารระหว่างฝ่ายหน้าบ้านและหลังบ้าน" ไม่ใช่ action item "ซาร่าห์จะนัดซิงก์รายสัปดาห์ 30 นาทีระหว่างหัวหน้าฝ่ายหน้าบ้านและหลังบ้าน เริ่มวันจันทร์หน้า" ต่างหากที่ใช่ ผู้รับผิดชอบและวันเริ่มต้นต้องถูกระบุในห้องประชุม — ทีหลัง ความเจาะจงจะจางลง

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

ทำไมสรุป Retro จึงเขียนยากกว่าบันทึก Standup

สรุป Standup นั้นสั้น สรุป Sprint Planning มีโครงสร้าง แต่สรุป Retrospective ยากเพราะเนื้อหายุ่งเหยิง — sticky note การถกเถียงที่กระโดดไปมาระหว่างส่วนต่างๆ ทั้งความรู้สึกและข้อมูลปนกัน ใครก็ตามที่เขียนสรุปต้องประกอบเรื่องราวที่เชื่อมโยงกันขึ้นใหม่จากการประชุมที่เดินไปหลายทิศทางพร้อมกัน

Pavleur จัดการเรื่องนี้ได้ดีเพราะความยุ่งเหยิงนั้นพอดี มันเก็บทุกอย่างที่พูดระหว่างการประชุมและทุกอย่างที่อยู่บนหน้าจอ — บอร์ดร่วม กราฟ velocity จากส่วนที่ 2 ticket เหตุการณ์ที่มีคนอ้างถึงในส่วนที่ 4 รายงานหลังการประชุมมีโครงสร้าง พร้อม action item ที่ดึงมาจากสิ่งที่ตัดสินใจในห้องประชุมจริงๆ (พร้อมผู้รับผิดชอบและวันที่ตามที่ระบุ) ไม่ต้องประกอบร่างใหม่ ไม่ต้องเก็บกวาดหลังการสนทนา

เครื่องมือถอดเสียงแบบเสียงอย่างเดียวเก็บได้แต่คำพูด แต่ไม่ได้เก็บบริบทภาพ ใน Retro ภาพมักเป็นส่วนที่สำคัญที่สุด — บอร์ด sticky note กราฟที่เผยรูปแบบ ticket ที่ยึดการถกเถียงไว้ บริบทนั้นไม่มีอยู่ในสรุปแบบเสียงอย่างเดียว สำหรับการเปรียบเทียบเครื่องมือโดยตรง: Pavleur เทียบกับทางเลือกอื่น

รูปแบบความล้มเหลวที่พบบ่อยใน Retro

action item เดียวกันปรากฏใน Retro สามครั้งติดต่อกัน ส่วนที่ 1 ต่อรองไม่ได้ ถ้ารายการหนึ่งไม่เคยได้ทำสักที ให้ยกเลิกมันพร้อมเหตุผลที่ระบุ หรือส่งเรื่องขึ้นไป — อย่ายกมันไปข้างหน้าอย่างไม่มีที่สิ้นสุด

การถกเถียงกลายเป็นการระบายโดยไม่มีข้อสรุป หน้าที่ของผู้ดำเนินรายการในส่วนที่ 4 คือการแปล "กระบวนการนั้นมันพัง" ให้เป็นสิ่งที่เจาะจงและเปลี่ยนแปลงได้หนึ่งอย่าง ถ้าทำให้เจาะจงไม่ได้ใน 30 วินาที มันจะไปอยู่ในที่พักหัวข้อ

ไม่มีใครเพิ่มรายการแบบ async ก่อนการประชุม ส่งบอร์ดล่วงหน้า 24 ชั่วโมง หว่านด้วย 2-3 รายการเพื่อทลายปัญหาผืนผ้าใบเปล่า การประชุมดำเนินได้ดีกว่าเมื่อทุกคนมาถึงพร้อมสิ่งที่จดไว้แล้ว