Retrospective ด้วย Team Goal/Team Release

เป้าหมายหนึ่งของการทำ retrospective คือจะทำยังไงให้ทีม ได้เติบโต และพัฒนาขึ้นในฐานะของทีม มีวันหนึ่งได้มีโอกาสไป facilitate กิจกรรม retrospective ให้กับทีม เลยลองเอาไอเดียที่ได้มาจากตอนทำ product discovery คือการหา product goal และ product release มาประยุกต์ใช้กับทีมดู

สิ่งที่ได้ก็จะออกมาเป็นสิ่งที่เรียกว่า team goal และ team release

Team Goal

team goal หรือเป้าหมายของทีม จะเป็นเป้าหมายระยะยาว (long term goal) ที่ทีมวางร่วมกันว่ามีเพื่อกำหนด position ของทีมว่าเมื่อถึงช่วงเวลาที่กำหนดทีมอยากจะเป็นอย่างไร อยากจะแก้ปัญหาอะไร หรืออยากจะทำทำอะไรให้ประสบความสำเร็จ

Team Release

team release เป็น loop สั้น ๆ หรือเรียกได้ว่าเป็นเป้าหมายระยะสั้น (short term goal) เพื่อเอาไว้ตรวจดูว่าเราเดินมาถูกทางไหม เราเจอปัญหาอะไรบ้าง อะไรที่เป็นอุปสรรคต่อการจะไปถึงเป้าหมายระยะยาว

สิ่งสำคัญใน team release คือการตรวจเช็ค feedback จากทีม ว่า ตลอดช่วง release ที่ผ่านมา ทีมเจอปัญหาอะไรบ้าง มีอะไรที่ชอบ ไม่ชอบ อยากจะแก้ไขปรับปรุง และ การกำหนด action plan สำหรับ team release ถัดไป ว่าจะทำอะไรให้มันดีขึ้น หรือป้องกันไม่ให้เราล้มซ้ำที่เดิม

กิจกรรม

ในครั้งแรกที่เริ่มกิจกรรมนี้ จะเริ่มจากให้ทีมหาเป้าหมายระยะยาวร่วมกันก่อน โดยอาจจะเริ่มจากให้ทีมหาจากความเจ็บปวดร่วมกัน (common pain) หรืออาจจะให้ทีมตั้งเป้าหมายระยะยาวร่วมกันเลยก็ได้ (common long term goal) ระยะยาวนี่อาจจะเป็น 6 เดือน หรือ 1 ปี ส่วนวิธีการหาเป้าหมายระยะยาวร่วมกัน อาจจะใช้ design thinking หรือ brainstorm มาเป็นตัวช่วยก็ได้

เมื่อได้เป้าหมายระยะยาวร่วมกันแล้ว ก็มาหาเป้าหมายระยะสั้นด้วยวิธีเดียวกัน หรืออาจจะใช้วิธี brainstorm idea และใช้ dot-vote เพื่อหาเป้าหมายระยะสั้นเป็น action item ก็ได้ action item ควรจะมีเพียง item เดียว เพื่อให้ทีมสามารถโฟกัสกับ action item ที่ต้องทำ ควบคู่ไปกับงานปกติได้

เป้าหมายระยะสั้นจะใช้ระยะเวลาประมาณ 1–4 sprints แล้วแต่จะสะดวก (ถ้า sprint ปกติสั้นมาก อาจจะใช้ 2–4 sprints ก็ได้ ถ้า sprint ยาวมาก อาจจะใช้ 1 sprint ก็พอ) ทั้งนี้ระยะเวลาในการทำ action ควรจะยาวมากพอสำหรับ action นั้น ๆ เพื่อให้ทีมได้ลองทำ และสามารถเก็บ feedback จาก action ที่เพียงพอ

สมมติทีมกำหนดระยะเวลาสำหรับ action item ไว้ 2 sprints นั่นคือ อีก 2 sprints ใน session retrospective เราก็กลับมาเช็คว่าผลจาก action item เป็นอย่างไร สำเร็จ หรือไม่สำเร็จ ติดปัญหาอะไรบ้าง เสร็จแล้ว ลองเช็คดูว่า team goal ยังเป็นสิ่งที่ทีมยังอยากจะไปถึงอยู่หรือไม่ หรือมีอะไรเปลี่ยนไปจากเดิมแล้ว ถ้าต้องการเปลี่ยน team goal ก็กลับไปทำวิธีเดิม แต่ถ้า team goal ยังถูกต้องอยู่ ก็กลับไป brainstorm หา action item ใหม่

action item ใหม่ อาจจะคล้าย ๆ เดิม แต่มีการป้องกันหรือแก้ไขข้อผิดพลาดจาก team release ที่แล้วก็ได้ หรืออาจจะเป็น action item ใหม่เลย ที่แตกต่างจากของเดิมก็ได้ แต่ควรจะสอดคล้องกับ team goal

การกำหนด team release/team goal ที่ดี

team release/team goal ที่ดี ควรมีคุณสมบัติ S.M.A.R.T (เหมือนกับคุณสมบัติที่ดีของ goal ทั่ว ๆ ไป) คือ

• Specific — ชัดเจน ไม่เอาแบบลอย ๆ เช่น จะทำให้ดี อะไรคือทำให้ดี ไม่เคลียร์ บอกไปเลย จะทำอะไร
• Measurable — วัดผลได้ ไม่เอาแบบ จะเขียน test ให้มากขึ้น อะไรคือมากขึ้น มากขึ้นเทียบกับอะไร บอกไปเลย จะเขียน test ให้มี code coverage ตั้งแต่ 80% ขึ้นไป
• Achievable — ทำได้จริง อย่าตั้ง goal เว่อร์ไป เอาแบบพอจะทำได้ แต่ก็ไม่ใช่ว่าง่ายโคตร ง่ายซะจนไม่ได้พัฒนาอะไรเลย เอาแบบทำได้ แล้วเลยจุดนั้นไปนิดหน่อย
• Relevant — เกี่ยวข้องกัน team release ควรจะสัมพันธ์กับ team goal ไม่ใช่ว่า team goal บอกว่าอยากให้ทีมสามารถทำงานแทนกันได้ แต่ team release ตั้งว่า จะหัดภาษาโปรแกรมมิ่งใหม่ อันนี้ก็ดูห่างกันเกินไป
• Time-bound — มีกำหนดเวลาชัดเจน อย่างที่เล่าไปข้างต้น team release ประมาณ 1–4 sprints แล้วกลับมาดูกัน ส่วน team goal เป็นระยะยาว อาจจะ 6 เดือน หรือ 1 ปี

ท้ายที่สุด

ทีมอาจจะไปถึง goal หรืออาจจะไม่ถึง goal ที่ตั้งไว้ก็ได้ ถึงแม้จะไปไม่ถึง goal ที่เคยตั้งไว้เดิม ทีมก็จะพัฒนาตัวเองไปยัง goal ที่สอดคล้องกับสถานการณ์ และบริบทใหม่ได้อยู่ดี

เมื่อถึง goal แล้ว ทำอะไรต่อ

ตั้ง goal ใหม่แล้วทำต่อสิครับ จะรออะไร

pingback : https://chonla.com/2018/09/21/retrospective-with-team-goal-team-release/