#priwreadbooks Agile Coaching — Chapter 13— Driving Change with Retrospectives (สรุป)

Photo by Jan Kopřiva on Unsplash

Previous chapter:

• Chapter 1 — Starting the Journey
• Chapter 2 — Working with People
• Chapter 3 — Leading Change
• Chapter 4 — Building an Agile Team
• Chapter 5 — Daily Standup
• Chapter 6 — Understanding What to Build
• Chapter 7 — Planning Ahead
• Chapter 8 — Keeping It Visible
• Chapter 9 — Getting to “Done”
• Chapter 10 — Driving Development with Tests
• Chapter 11 — Clean Code
• Chapter 12 — Demonstrating Results

ใช้การไตร่ตรอง (ส่องกระจก) เป็นประจำเพื่อปรับปรุงให้ดียิ่งขึ้น

Henrik Kniberg สังเกตว่า “หากไม่มีการทำ retrospective คุณจะพบว่าทีมยังคงทำผิดพลาดซ้ำแล้วซ้ำเล่า” ทีมไม่สามารถหลุดพ้นจากวงจรที่เจ็บปวดได้ จนกว่าพวกเขาจะใช้เวลาทำความเข้าใจกับสิ่งที่เกิดขึ้นและเปลี่ยนแนวทางของตนเอง

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

เรามักจะเจอทีม Agile ที่เคยทำ retrospective แล้วล้มเลิกไป เพราะพวกเขารู้สึกว่ามันไม่ได้ทำให้เกิดการเปลี่ยนแปลงใดๆ ดังนั้นการดำเนินการต่อไปเป็นการเสียเวลาเปล่า

สถานการณ์นี้มักเกิดจากทีมไม่รู้วิธีการทำ retrospective ที่ถูกต้อง

Facilitating a Retrospective

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

• พวกเขามีข้อมูลเชิงลึกอะไรบ้างจากรอบการทำงานครั้งล่าสุด
• พวกเขาต้องการปรับปรุงด้านใด
• แนวคิดใดที่พวกเขาสามารถดำเนินการในรอบการทำงานครั้งต่อไป

มอง retrospective เป็นสะพานเชื่อมระหว่างรอบการทำงานในอดีตและรอบการทำงานในอนาคต

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

ต้องใช้เวลา

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

มีปัญหามากเกินไปที่จะแก้ไขในครั้งเดียว

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

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

“กลิ่น” บางอย่างที่ระบุว่า retrospective ไม่เวิร์ค

• เทศกาลแห่งไอเดีย — สมาชิกในทีมจะถูกขอให้เสนอแนวคิดโดยไม่ต้องพูดถึงสิ่งที่เกิดขึ้นในรอบการทำงานครั้งล่าสุด ปัญหาถูกกลบเกลื่อน การดำเนินการอาจไม่ได้เกี่ยวข้องกับการแก้ปัญหา และมักจะเกี่ยวกับการลองของเจ๋งๆ แทนที่จะแก้ไขสิ่งที่มีปัญหา
• บทเรียนเชิงประวัติศาสตร์ — ค่อนข้างเหมือนกับการขุดค้นทางโบราณคดีที่ให้ผลลัพธ์เฉพาะรายการ “สิ่งที่เป็นไปด้วยดี” และ “สิ่งที่ต้องปรับปรุง” แต่ไม่มีการดำเนินการใดๆ เนื่องจากไม่มีการอภิปรายเกี่ยวกับวิธีการปรับปรุง การเปลี่ยนแปลงถูกปล่อยให้เป็นหน้าที่รายบุคคล แทนที่จะถูกนำมาวางแผนร่วมกันในการทำงานครั้งต่อไป
• เปลี่ยนแปลงโลก — ทีมงานมุ่งมั่นกับรายการการดำเนินการที่ทะเยอทะยาน โดยไม่พิจารณาว่าจะมีเวลาที่จะทำให้เสร็จในรอบการทำงานครั้งต่อไปหรือไม่ สิ่งนี้นำไปสู่ความผิดหวัง เนื่องจากการดำเนินการไม่เสร็จสิ้น และทีมงานก็จะเพิ่มการดำเนินการเพิ่มเติมใน retrospective ทุกครั้ง
• ปราถนาที่จะทำ — การดำเนินการที่กล่าวถึงนั้นค่อนข้างคลุมเครือและไม่มีเจ้าของ เช่น “ปรับปรุงการสื่อสาร” หรือ “ปรับโครงสร้างใหม่ให้มากขึ้น” สิ่งเหล่านี้ไม่ใช่การกระทำ หากไม่มีการพูดคุยเพิ่มเติม ทีมงานก็ไม่รู้จริงๆ ว่าต้องทำอย่างไร
• ไม่มีเวลาปรับปรุง — ทีมงานใช้เวลาห้าถึงสิบนาทีหลังจากการ Demo เพื่อพูดคุยอย่างรวดเร็วเกี่ยวกับสิ่งที่เกิดขึ้น และเรียกสิ่งนั้นว่า retrospective นี่เป็นสัญญาณว่าทีมไม่เห็นประโยชน์ หากทีมงานบางคนมีแนวคิดในการปรับปรุงให้ดีขึ้น พวกเขาจะเผชิญกับความยากลำบากในการนำไปปรับใช้ เพราะไม่มีพื้นที่ที่สามารถรับการสนับสนุนจากทีม
• ความดุเดือด — ทีมงานพูดถึงสิ่งเลวร้ายที่เกิดขึ้น โดยไม่รับผิดชอบในการปรับปรุงสถานการณ์ให้ดีขึ้น นี่อาจเป็นการระบายและปลดปล่อยความตึงเครียดในทีม และสามารถกลายเป็นการตำหนิกันได้อย่างง่ายดาย

retrospective คือ การเปลี่ยนแปลงให้ดีขึ้น ซึ่งจะเกิดขึ้นไม่ได้เลยหากปราศจากการพูดคุยถึงสิ่งที่ทีมสามารถทำได้จริง

Norm Kerth สนับสนุนให้เรานำเรื่องราวออกมา แล้วขุดหาทองคำ
ทองคำ คือสิ่งที่เราได้เรียนรู้จากการไตร่ตรองถึงสิ่งที่เคยเกิดขึ้น

มองย้อนกลับไป

จำเป็นต้องได้รับการซื้อไอเดียจากทีม เพื่อให้การเปลี่ยนแปลงยังคงอยู่

สร้างการสนับสนุนสำหรับการปรับปรุงให้ดีขึ้น โดยเริ่มจากการทบทวนสิ่งที่ได้เรียนรู้ในรอบการทำงานครั้งล่าสุด

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

ใช้เวลาในการฟังสิ่งที่ทุกคนพูด

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

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

คุณอาจต้องการให้ทีมระบุว่าพวกเขารู้สึกอย่างไรเกี่ยวกับเหตุการณ์นั้น เช่น

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

• ขอให้ทีมวาดภาพว่า การทำโครงการนี้สร้างความรู้สึกอย่างไรกับพวกเขา และแปะภาพเหล่านั้นบนผนังในการประชุม จากนั้นเปิดโอกาสให้แต่ละคนอธิบายภาพวาดของตน การวาดภาพ อาจจะฟังดูแปลกๆ แต่การทำแบบฝึกหัดนี้สามารถใช้เพื่อนำเสนอหัวข้อที่จริงจังได้
  คนเรามักจะเก่งในการหาอุปมาอุปไมยสำหรับสิ่งที่แสดงออกมาเป็นคำพูดได้ยาก ตัวอย่างเช่น สมาชิกในทีมคนหนึ่งวาดรูปคนติดอยู่ในกล่อง เมื่อเราถามเขาเกี่ยวกับเรื่องนี้ เขาอธิบายกับเพื่อนร่วมทีมว่า เขาทำงานด้วยตัวเองนานเกินไป และไม่รู้สึกว่าเป็นส่วนหนึ่งของทีมอีกต่อไป
• ดึงข้อมูลเชิงลึกจากประสบการณ์ที่ได้ล่าสุด เริ่มต้นด้วยการสำรวจเส้นเวลาเพื่อพยายามระบุตำแหน่ง เดินตามเส้นเวลา อ่านออกเสียงบันทึกย่อแต่ละรายการ หากข้อความใดที่คุณรู้สึกงง ให้เชิญทีมงานมาชี้แจง ทำอย่างระมัดระวังโดยไม่ต้องให้บุคคลที่เขียนข้อความนั้นมาอธิบาย ค้นหาสาเหตุที่แท้จริง
  หากงานในรอบนี้ดำเนินไปได้ด้วยดี อะไรคือปัจจัยที่ทำให้เกิดสิ่งนี้ หากคุณพบข้อความทั่วไป เช่น “สภาพแวดล้อมที่จะทำการทดสอบเสีย” หรือ “ลูกค้ายุ่งเกินไป” ให้ขอตัวอย่าง เพื่ออธิบายปัญหาให้ทีมเข้าใจประเด็นได้ดีขึ้น
• หากคุณใช้โน้ตที่มีสีเพื่อบ่งบอกถึงความรู้สึกของทีม คุณจะเห็นรูปแบบที่โน้ตที่มีสีเดียวกันมักจะรวมกันเป็นกลุ่มรอบๆ เหตุการณ์สำคัญ จุดสูงสุดและต่ำสุดของเส้นอารมณ์จะทำเช่นเดียวกัน สิ่งเหล่านี้แสดงความแตกต่างในประสบการณ์ของบทบาทที่แตกต่างกัน ตัวอย่างเช่น คุณอาจเห็นนักพัฒนาทั้งหมดวาดเส้นบวกในตอนท้าย เนื่องจากพวกเขาทำงานทั้งหมดเสร็จสิ้น แต่ผู้ทดสอบอาจวาดเส้นเชิงลบมากกว่า เพราะเขาทำการทดสอบทั้งหมดในวันสุดท้าย ดึงความสนใจของทีมไปที่เส้นแบ่งเพื่อกระตุ้นให้พวกเขาหารือเกี่ยวกับสิ่งที่เกิดขึ้น
• หลังจากที่คุณดำเนินการตามไทม์ไลน์แล้ว ทีมจำเป็นต้องเลือกหัวข้อที่สำคัญที่สุดตัดทอนรายการนี้ให้เหลือเพียงสองหรือสามอันดับแรก โดยใช้การลงคะแนนแบบจุด สมาชิกในทีมแต่ละคนจะได้รับคะแนนโหวตสามคะแนน โดยการวาดจุดถัดจากหัวข้อที่พวกเขาต้องการจะพูดคุยมากที่สุด พวกเขาสามารถกระจายจุดระหว่างหัวข้อหรือสามารถใส่มากกว่าหนึ่งจุด หากหัวข้อหนึ่งมีความสำคัญต่อพวกเขามากกว่าที่เหลือทั้งหมด รวบรวมจำนวนจุดหลังจากทุกคนลงคะแนนเพื่อระบุว่าหัวข้อใดที่จะนำไปวางแผนปฏิบัติการ
• เมื่อคุณได้แยกหัวข้อที่ทีมต้องการเน้นแล้ว ให้เปลี่ยนไปตั้งหน้าตั้งตารอการปรับปรุงกระบวนการที่ทีมสามารถทำได้ในรอบการทำงานถัดไป

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

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

มองไปข้างหน้า

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

ทีมต้องดำเนินการเพื่อดำเนินการเปลี่ยนแปลง และการกระทำต้องทำให้เสร็จ

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

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

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

ก่อนตัดสินใจดำเนินการใดๆ ให้ปรึกษากับทีมว่ามีเวลาเท่าใดในรอบการทำงานถัดไปที่พวกเขาสามารถอุทิศให้กับการปรับปรุงกระบวนการในขณะที่พัฒนาซอฟต์แวร์เรื่องใหม่

เริ่มต้นด้วยก้าวเล็กๆ

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

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

การดำเนินการไม่ได้เกี่ยวกับการแก้ไขปัญหาเสมอไป คุณต้องเข้าใจปัญหาก่อนที่จะแก้ไขได้

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

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

เมื่อคุณมีข้อมูลเพิ่มเติม คุณสามารถแก้ไขปัญหาได้โดยตรง และดูว่าการเปลี่ยนแปลงได้แก้ปัญหาหรือไม่

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

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

รองเท้าที่หลากหลาย

มีหนังสือค่อนข้างแปลกจาก Edward De Bono ชื่อ Six Action Shoes แสดงให้เห็นชัดเจนว่ามีการกระทำประเภทต่างๆ โดยเปรียบกับรองเท้าประเภทต่างๆ

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

กระบวนการพื้นฐาน

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

เมื่อคุณมีชุดการดำเนินการที่ทั้งทีมพอใจแล้ว คุณสามารถสรุปการประชุมได้

อย่าลืมว่าหลังจาก retrospective แล้ว การดำเนินการเหล่านี้จำเป็นต้องนำมาพิจารณาในการวางแผนครั้งต่อไป เขียนไว้บนกระดาน เพื่อไม่ให้ลืม

ออกแบบ Retrospective

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

ตัดสินใจว่าคุณจะต้องใช้ระยะเวลานานเท่าใดโดยพิจารณาจากระยะเวลาของรอบการทำงาน จำนวนคนในทีม และพิจารณาว่าจะมีสมาชิกทีมระยะไกลเข้าร่วมหรือไม่ (remote)

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

แน่นอนว่าคุณไม่จำเป็นต้องใช้จนหมด จบเร็วก็ไม่เป็นไร

นี่คือตัวอย่างวิธีแบ่งเวลา:

• ทบทวนเป้าหมายของการประชุม และเตือนทีมเกี่ยวกับกฎพื้นฐาน (5 นาที)
• สร้างไทม์ไลน์ (15 นาที)
• ขุดไทม์ไลน์เพื่อดูข้อมูลเชิงลึก (15 นาที)
• เลือกหัวข้อที่จะมุ่งเน้น (10 นาที)
• ตรวจสอบความคืบหน้าของการดำเนินการก่อนหน้านี้ (5 นาที)
• สร้างแนวคิดสำหรับการปรับปรุง (15 นาที)
• การวางแผนปฏิบัติการ (15 นาที)

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

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

คำสั่งหลักเป็นกฎพื้นฐาน

“ไม่ว่าเราจะค้นพบอะไร เราเข้าใจและเชื่ออย่างแท้จริงว่าทุกคนทำหน้าที่ได้ดีที่สุดเท่าที่จะทำได้ โดยพิจารณาจากสิ่งที่พวกเขารู้ในขณะนั้น ทักษะและความสามารถ ทรัพยากรที่มีอยู่ และสถานการณ์ที่อยู่ตรงหน้า”

ทำให้ปลอดภัยในการสำรวจสิ่งที่ผิดพลาด

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

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

มุ่งเน้นไปที่วิธีการปรับปรุงกระบวนการของทีม หากผลการปฏิบัติงานของแต่ละคนปรากฏขึ้น ให้เปลี่ยนโฟกัสกลับไปที่การดำเนินการของทีม

ในครั้งแรกที่คุณดำเนินการทำ retrospective ให้คุณเขียนกฎพื้นฐานและอธิบายให้ทีมทราบ หากบทสนทนาเริ่มเป็นเชิงลบเกินไป คุณสามารถเตือนทีมให้คิดถึงสถานการณ์ที่กดดันให้เกิดสิ่งนั้น แทนที่จะโทษไปที่ตัวบุคคล

Retrospectives ในวงกว้าง

แม้ว่า retrospective จะมุ่งเน้นไปที่ปัญหาเฉพาะหน้าซึ่งส่งผลต่อทีม แต่จะมีปัญหาภายนอกทีมที่ไม่สามารถแก้ไขได้ นี่เป็นสัญญาณว่าคุณต้องโฟกัสกว้างขึ้นเพื่อดูภาพรวมที่ใหญ่ขึ้น กับกลุ่มที่ใหญ่ขึ้น

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

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

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

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

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

Retrospective Prework

ตัวอย่างแบบสำรวจที่ผู้เขียนได้ส่งไปยังผู้เข้าร่วมก่อน เพื่อรวบรวมประเด็นที่พวกเขาต้องการหารือ

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

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

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

อุปสรรคที่อาจเจอ

การกระทำเดียวกันเกิดขึ้นซ้ำแล้วซ้ำอีก

มักเกิดจากการไม่แบ่งการดำเนินการออกเป็นงานที่สามารถทำได้ในรอบการทำงานเดียว

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

หากการกระทำเล็กๆ น้อยๆ ไม่สำเร็จ ทีมงานจำเป็นต้องหารือกันว่าทำไม

ถ้าทำอะไรไม่เสร็จเลยในแต่ละรอบการทำงาน ก็ไม่มีประโยชน์อะไรในการทำ retrospective

สมาชิกในทีมเงียบ

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

อย่างไรก็ตาม ระบุให้ชัดเจนว่ามันโอเคที่จะพูดว่า “ขอผ่าน”

ทีมมักจะคร่ำครวญ

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

รักษาความเป็นกลาง

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

หากมีการทำงานแบบ Agile หลายทีม ให้ลองเปลี่ยนไปเป็น facilitator ให้กับทีมอื่น หรือให้คนในทีมผลัดกันมาทำตำแหน่งนี้