RETROSPECTIVE: เมื่อทีมเกิด DRAMA ทำไง ?

RETROSPECTIVE: เมื่อทีมเกิด DRAMA ทำไง ?

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

Retrospective คืออะไร

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

ผมรู้จักการทำ Retrospective ครั้งแรกในวันเดียวกับที่ผมรู้จัก Agile เป็นครั้งแรกที่งาน Agile Thailand 2013 ในวันนั้นมี Session หนึ่งที่ผมไปเข้าในตอนบ่ายชื่อว่า Retrospective: The art of continuous improvement ซึ่งสิ่งที่ดีที่สุดใน Session นี้นอกจากได้รู้ว่า Retrospective คืออะไรแล้วยังได้ฟังประสบการณ์จริงๆด้วยว่าทำแล้วเกิดอะไรขึ้นต่อมาและนั้นคือเหตุผลให้ผมอยากทำมาตลอดแต่ไม่มีโอกาสและที่สำคัญไม่มีดราม่า

Drama นั้นสำคัญไฉน

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

Good Bad Try

จริงๆแล้ววิธีการทำ Retrospective นั้นมีหลายแบบมากๆแต่ที่ผมรู้จักและเลือกที่จะเอามาใช้คือ Good Bad Try ครับจริงๆแล้วผมบอกตามตรงเลยว่าผมไม่รู้ว่า Good Bad Try แบบจริงๆตามหลักการนั้นทำยังไงนอกจากมีคำว่า Good Bad Try และให้ทุกคนในทีมเอากระดาษโพสอิทไปแปะแต่สิ่งที่ผมจะกล่าวต่อไปคือขั้นตอนการทำ Good Bad Try ในแบบฉบับของทีมผมเอง

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

  • สิ่งที่คิดว่าตัวเองทำได้ดี
  • สิ่งที่คิดว่าตัวเองทำได้ไม่ดี
  • สิ่งที่คิดว่าตัวเองควรจะปรับปรุง

ซึ่งแน่นอนว่าการให้มนุษย์ยอมรับข้อผิดพลาดของตัวเองหรือแม้กระทั่งบอกข้อดีของตัวเองนั้นเป็นเรื่องที่ยากมากพอๆกันผมกำหนดเวลาให้ 7 นาทีในการเขียนสิ่งดังกล่าวแล้วเอามันไปแปะมันไว้บนบอร์ดช่วงห้านาทีแรกเป็นช่วงที่ผมรู้สึกได้ทันทีเลยว่าเป็นช่วงเวลาเปิดใจทีมการจะเขียนอะไรสักอย่างลงไปในกระดาษกลายเป็นเรื่องที่ยากพอๆกับการเขียน Method เพื่อแก้ปัญหาซักอย่างหนึ่งแต่พอผ่านพ้น 5 นาทีแรกไปแล้วทุกคนในทีมก็เริ่มรู้สึกว่ามีอะไร "อยากจะเขียน" มากขึ้นเรื่อยๆหลายๆเรื่องเป็นเรื่องที่ชวนขบขันและไม่จริงจังแต่หลายๆเรื่องกลายเป็นเรื่องที่เราทุกคนในทีมไม่เคยคิดเลยว่าเราจะคิดเหมือนๆกันพอหมด 7 นาทีในขณะที่ทุกคนในทีมกำลังสนุกกับการเริ่มเขียนสิ่งที่ "ตัวเองคิด" ลงไปในกระดาษผมต่อเวลาให้ทีมอีก 3 นาทีจนหมดเวลาก็มีกระดาษโพสอิทติดอยู่ใต้หัวข้อเต็มไปหมด (โดยเฉพาะ Try)

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

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

เมื่อถึงเวลาดูบอร์ดหลายๆอย่างเป็นไปตามคาดไว้นั้นแสดงให้เห็นว่าไม่ว่าจะเป็นข้อดี, ปัญหาหรือสิ่งที่เราพยายามจะแก้ไขหลายๆอย่างนั้นดูเหมือนเราจะเข้าใจมันดีอยู่แล้วแต่หลายๆอย่างทีมของเราไม่เคยคิดมาก่อนเลยว่ามันจะเป็นปัญหาหรืออย่างน้อยในมุมมองของคนอื่นๆในทีมข้อสำคัญคือข้อความในกระดาษโพสอิทแต่ละอันก็เหมือน Task ที่เราเขียนไว้ใน Backlog หลายๆครั้งเราที่เราไม่เข้าใจว่าคนอื่นเขียนอะไรลงไปสิ่งที่จะตามมาก็คือเราต้องให้เจ้าของกระดาษโพสอิทนั้นอธิบายซึ่งถ้ายังไม่เข้าใจอยู่ต้องจบด้วยคำว่า "ยกตัวอย่างเช่น" (เอาเทคนิคนี้มาจาก TPSE Conference) เมื่อเรายกประเด็นในเรื่องใดขึ้นมาพูดแล้วสิ่งที่ตามมามักจะเป็นวิธีแก้ปัญหาและสิ่งที่คนนั้นควรจะปรับปรุงซึ่งหลายๆครั้งคนที่ถูกพูดถึงในการ์ดเองก็มองข้ามวิธีเหล่านี้ไปสิ่งนี้ผมถือว่าเป็นสิ่งที่เราได้อะไรมากที่สุดจากการทำ Retrospective ในครั้งนี้เลย

การจบ Retrospective

เทคนิคนี้ผมยอมรับเลยว่าเอามาจากการไปฟัง Session นี้ที่งาน Agile Thailand 2013 โดยในขณะที่เรายังรู้สึกอินกับการเปิดใจและยอมรับความคิดเห็นของทีมในแต่ละประเด็นอยู่นั้นเมื่อถึงจุดที่ใกล้จะสิ้นสุดทุกคนในทีมจะรู้สึกคล้ายๆกันคือยอมรับข้อผิดพลาดและมุ่งมั่นที่จะเริ่มการปรับปรุงตัวเองเพื่อทีมแต่ก่อนที่จะจบนั้นผมเริ่มด้วยการกล่าวขอบคุณทุกคนในทีมและเพื่อนบางคนที่อยู่ที่ห้องโปรเจ็คในเวลานั้นมันเป็นช่วงเวลาที่ผมรู้สึกดีมากๆผมกล่าวขอบคุณทุกคนจากใจจริงขอบคุณทุกคนที่เปิดใจและทำให้เรารู้สึกร่วมกันความรู้สึกที่ทำให้เราเป็นทีมเดียวกัน (หลังจากผ่านวันที่โหดร้ายมาในตอนบ่ายวันเดียวกันนั้นเอง) ซึ่งหลังจากนั้นทีมเราก็ประชุมกันต่อในหัวข้อต่อไปแต่สิ่งหนึ่งที่ผมรู้สึกได้ในเวลานั้นก็คือ Mindset ของทีมได้เปลี่ยนไปแล้วและมันกำลังจะไปในทางที่ดีขึ้นหรืออย่างน้อยผมก็เชื่อว่ามันจะเป็นอย่างนั้น

สิ่งที่ผมเรียนรู้จากการทำ Retrospective ครั้งนี้

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

Original post at: https://yothinix.blogspot.com/2013/12/retrospective-drama.html