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 ส่วนใหญ่ไม่ใช่ปัญหาในตัวงานแต่เป็นปัญหาที่เกี่ยวกับสภาพแวดล้อมการทำงาน
• ผมเป็นคนจริงจังเกินไปในสายตาของเพื่อนร่วมทีม ซึ่งก็เป็นทั้งข้อดีและข้อเสียในเวลาเดียวกัน