A Proper way to do retrospective
หลังจากได้ฟัง Clubhouse ของต่างชาติเกี่ยวกับการทำงานของ Product & Engineer ก็มีประเด็นที่เค้าพูดกันถึง Retrospective มักจะ focus ผิดจุด เลยอยากเขียนเอาไว้เตือนความจำ
Retrospective ควรจะ focus ว่าเราจะ deliver value ให้ customer ได้เร็วขึ้นอย่างไร มี process ตรงไหนที่ทำให้ deliver value ช้า เช่น build นาน, ต้องรอ manual test, รอ review code นาน, แก้ code หลายรอบ, product spec ไม่เคยนิ่ง, ติด breaking change deploy ไม่ได้ ฯลฯ
ทำไมต้อง focus แค่ deliver value?
High-performance team กับ normal team ต่างกันตรง speed ในการ deliver value ทีมที่ deliver ได้เร็วกว่าจะมีเวลามากกว่าในทุกๆ เรื่อง เช่น เมื่อส่ง feature ได้เร็ว ทีมก็จะมีเวลาในการแก้ไขปัญหาได้เร็วด้วยเช่นกัน สามารถทดลอง idea ได้มากกว่า iterate ได้เร็วกว่า
ปัญหาของการทำ Retrospective แบบทั่วๆ ไป
- Retrospective ส่วนใหญ่ focus แค่ feeling ของคนในทีม ไม่ได้ focus เรื่องการ improve process ให้ deliver value ได้เร็ว
- มีแต่ปัญหา list ออกมา แต่ไม่มี solution/action ออกมา
- มี solution/action แต่ไม่มี ownership ที่ชัด
- มี ownership แต่ไม่มีการ follow up progress และ action ไม่เกิด
- มี action และ ownership แต่ปัญหาต้องการ buy-in จากคนอื่นๆ ซึ่ง owner ไม่มี power มากพอ
- มี action มี power แต่ปัญหาถูกแก้ช้าเกินไป ไม่ถูกทำให้มีความสำคัญ
ถ้าทำ retrospective ที่ focus on improve deliver process และมีการแก้ไขปัญหาได้เร็ว ทีมจะทำงานได้เร็วขึ้น สนุกขึ้น มีความสุขมากขึ้น และด้วย speed นี้จะทำให้ team ทิ้งห่างจากทีมอื่นๆ ได้เร็วยิ่งขึ้น