#priwreadbooks Agile Coaching — Chapter 4 — Building an Agile Team (สรุป)
Previous chapter:
การทำงานในทีม Agile ด้วยความใกล้ชิดกันนั้นเป็นเรื่องน่าตื่นเต้น แต่การทำงานร่วมกันไม่ได้เกิดขึ้นในทันที ต้องใช้เวลาทำให้มันค่อยๆ ชัดเจนขึ้น ถ้าทีมไม่สามารถดึงผู้คนให้มารวมตัวกันได้ ซอฟต์แวร์ที่พวกเขาสร้างขึ้นจะสะท้อนสิ่งนี้ออกมา
คุณสามารถช่วยทีมได้ด้วยการกำหนดเงื่อนไขสำหรับการทำงานเป็นทีม โดยเริ่มจาก ให้เวลาพวกเขาทำความรู้จักกัน ปรับปรุงพื้นที่ทำงานเพื่อให้ทีมมีสภาพแวดล้อมที่สนับสนุนการทำงานร่วมกัน และค้นหาวิธีที่คุณสามารถช่วยเหลือทีมให้สร้างความรู้สึกร่วมกันว่าโครงการนี้มุ่งไปที่ใด
เมื่อเรามีทีมที่แข็งแกร่งเพียงพอ คุณจะสังเกตได้ว่าพวกเขาไม่ได้แค่ทำตามวิธีปฏิบัติ แต่เมื่อเจอปัญหา พวกเขาจะสามารถพลิกแพลงและปรับเปลี่ยนวิธีการทำงานได้เพื่อแก้ปัญหานั้น
ใช้เวลาในการรู้จักทุกคน
สร้างความเชื่อใจด้วยการทำงานร่วมกัน สร้างความเข้าใจในมุมมองของผู้อื่นที่มีกับปัญหา นอกเหนือจากการ Meeting ในการทำงานแล้ว ให้รวมถึงการกินข้าวด้วยกัน หรือ Outing เป็นการสร้างกาวเชื่อมทางสังคม ผูกทีมเอาไว้ด้วยกัน
ทำความรู้จักทีมเพื่อสร้างความเข้าใจกัน ถ้าเกิดมีใครในทีมรู้สึกไม่โอเคกับใครบางคนในทีม ให้ลองหาเวลานัดเพื่อไปพูดคุยกันส่วนตัว
การสร้างความเชื่อใจ
ความเชื่อใจเกิดจากพื้นฐานความเข้าใจในตัวอีกคน ไม่ต้องบอกทุกอย่างเกี่ยวกับเราให้กับทุกคนฟัง แต่ก็ไม่ได้มีความลับ เช่นการเล่าเรื่อง ความท้าทายที่แต่ละคนเคยเจอในอดีต เล่าได้ตั้งแต่สมัยยังเป็นวัยเยาว์จนถึงการทำงานครั้งแรก ทำให้เป็นพื้นที่ปลอดภัยในการเปิดเผยความรู้สึก สร้างความโปร่งใส เปิดใจรับฟัง ยอมรับเมื่อทำผิด ทำให้การขอความช่วยเหลือเป็นเรื่องปกติ
ความเชื่อใจจะเกิดขึ้นได้ก็ต่อเมื่อพวกเขารู้สึกปลอดภัย แต่ถ้ามันมีวัฒนธรรมของการชอบว่าคนอื่นเมื่อมีคนทำผิด มันก็จะไม่มีใครกล้าเปิดเผย ในฐานะโค้ชเราต้องซัพพอร์ททีมเพื่อให้แก้ปัญหาเหล่านี้ รวมถึงเรียนรู้ว่า ควรให้ Feedback เวลาไหน และเวลาไหนควรที่จะเงียบเพื่อฟัง
สิ่งที่หนังสือแนะนำ: ให้ทุกคนลองทำ MBTI ดู จะได้รู้ว่า Type ของแต่ละคนที่อยู่ในทีมเป็นแบบไหน
สร้างพื้นที่ให้ทีม
มีพื้นที่ให้ทีมสามารถใช้ร่วมกันได้ เพื่ออำนวยความสะดวกในการสื่อสาร ในส่วนนี้ควรมีทั้งส่วนที่ทำงาน ส่วนพักผ่อน รวมไปถึงห้องประชุม สร้างพื้นที่และสิ่งแวดล้อมที่ทำให้เรามีความสุขในการทำงานด้วยตัวเอง
เมื่อนำหลักการของ Agile เข้ามา เราอาจจะเจอการต่อต้านเกี่ยวกับไอเดียที่ Tester ควรนั่งข้างๆ กับนักพัฒนา หรือว่านั่งข้างๆ กับ Product Manager แต่ถ้าทุกคนได้นั่งทำงานร่วมกัน มันคือการสร้าง Informative Workspace ที่จะช่วยให้ทุกคนมีความรู้สึกร่วมกันในการตัดสินใจ
ไม่ใช่แค่พื้นที่ทางกายภาพที่เราต้องสนใจ แต่ก็ต้องซัพพอร์ทสภาพแวดล้อมในออนไลน์ด้วย เช่น การสร้าง Wiki หรือแชร์ respository สำหรับงานเอกสาร หรือมี Shared network drives และพวกเขายังต้องมีความชัดเจนเกี่ยวกับการตั้งค่าสำหรับการพัฒนาและการทดสอบในสภาพแวดล้อมที่สอดคล้องกันอีกด้วย
บทบาทที่สมดุล
ทำให้ทุกคนรู้สึกว่าพวกเขาเป็นส่วนหนึ่งของทีม ทำให้หน้าที่ความรับผิดชอบของแต่ละคนชัดเจน ให้เห็นทั้งทีม ส่วนมากแล้วฝั่งคนที่อยากได้ กับคนที่เป็นผู้ผลิตมักไม่เข้าใจกัน บางทีทางออกที่ดีที่สุดคือ
- Near-customer คนที่ลงไปช่วยเก็บความต้องการ ช่วยเขียน Requirement นั่งทำงานกับทีม เช่น Business Analyst
- Far-customer คนที่ตัดสินใจเกี่ยวกับความสำคัญทางธุรกิจ เช่น Product Manager ที่ทำงานใกล้ชิดกับ Business Operations, ทีมการตลาด
ถ้าฝั่งไหนมีงานล้นหนักเกินไป ก็จะไม่สามารถส่งมอบงานได้อย่างมีคุณภาพ
- Dev ไม่พอ ทำให้งานช้า ฝั่งธุรกิจก็เสียใจกับผลลัพธ์ที่ได้
- ถ้างานเยอะเกิน จน Dev ไม่มีเวลาที่จะทำอย่างอื่นเลย ก็จะ burnout ไปอีก
ในฐานะโค้ช เราต้องทำให้ปัญหาเหล่านี้ชัดเจนพอที่จะให้ระดับ Management สามารถเห็นปัญหานี้ได้
เติมพลังให้ทีม
ทีมที่ยอดเยี่ยมมักมีแรงจูงใจในตนเอง แต่บางครั้งเราก็พบว่าทีมอาจจะเจอสภาพติดขัดได้บ้าง พยายามให้พวกเขาหาแรงขับของตัวเองให้เจอ เช่น
- งานที่ไม่ง่ายไปไม่ยากไป ทำให้มันมีความท้าทายที่พอดี เพียงพอที่จะทำให้คนมีความสุขสูงสุดในการทำงานให้สำเร็จ
- สร้างวัฒนธรรมที่ยอมรับได้สำหรับการทดลอง เพื่อให้เรียนรู้ปัญหาและวิธีการแก้ไข เช่นเดียวกับที่คุณโทมัส เอดิสัน เคยกล่าวว่า “ผมไม่เคยพลาด ผมแค่เจอ 10,000 หนทางที่พบว่ามันไม่สามารถใช้งานได้” การพัฒนามากกว่า 1 Solution อาจจะรู้สึกว่ามันเสียเวลา แต่มันก็เป็นหนทางที่ดีในการที่จะเรียนรู้และมีราคาถูกมากกว่าที่จะรับมือกับปัญหาที่จะเกิดขึ้นในภายหลังถ้าเราตัดสินใจพัฒนาในทางเลือกที่ผิด
- หาเป้าหมายที่น่าสนใจ ช่วยให้ทีมมองเห็นภาพรวมและเป้าหมายของสิ่งที่พวกเขากำลังทำอยู่
- ให้ทีมได้เจอกับผู้ใช้งานจริง ให้พวกเขาได้รับรู้ว่า พวกเขาสามารถพัฒนาของที่กำลังทำอยู่ให้ดีได้มากขึ้นไปอีกได้อย่างไร
- ช่วยในภาพของโอกาสในโครงการและวิธีที่อาจเชื่อมต่อกับเป้าหมายส่วนตัวของพวกเขา
- ให้ความชัดเจนว่าพวกเขามีความเป็นอิสระมากน้อยเพียงใดเกี่ยวกับการออกแบบ สร้าง และทดสอบซอฟต์แวร์ เมื่อพวกเขาเข้าใจว่า พวกเขาไม่จำเป็นต้องรอการอนุญาต ก็สามารถปล่อยให้พวกเขาเริ่มต้นได้เลย
- อย่าลืมเผื่อเวลาว่างให้พวกเขาได้เสาะหาไอเดียใหม่ เรียนรู้สิ่งใหม่ ทำความสะอาด เก็บ Bug เพื่อสร้างแรงบันดาลใจ สร้างความสุขในการทำงาน สิ่งนี้จะช่วยปรับปรุงพลังงานของทีม
- ช่วยทีมค้นหามินิโปรเจ็กต์ของตนเองที่อยู่ในแต่ละโปรเจ็กต์ ด้วยการฟังและกระตุ้นให้พวกเขาติดตามแนวคิดของตัวเอง
ฉลองให้กับความสำเร็จ
ยินดีกับความสำเร็จในทุก Release เชิญทีม Management มาเข้าร่วมการเสนอผลงาน การได้รับ feedback จากผู้ใช้งานก็เป็นการกระตุ้นได้ดีอีกทางหนึ่ง
อย่าหมดกำลังใจ
เวลาที่คนเรารู้สึกไม่สบายใจหรือหมดกำลังใจ เกิดจากสถานการณ์ที่เขากำลังเจออยู่ เช่น ความเครียดหรือวัฒนธรรมองค์กร หาสาเหตุของสิ่งเหล่านั้นให้เจอ อาจจะไม่ใช่เรื่องของอุปกรณ์ที่ใช้อยู่ แต่เป็นสิ่งที่อยู่ภายในจิตใจของพวกเขา ในฐานะโค้ช เราจำเป็นต้องคุยกับทีม เพื่อให้รู้ว่าอะไรที่รบกวนพวกเขาอยู่และหาทางปรับปรุงพัฒนาให้ดียิ่งขึ้น
ระวังเรื่องสิ่งจูงใจ
สิ่งจูงใจเป็นตัวกระตุ้นเรื่องของประสิทธิภาพรายบุคคลได้ดี แต่มันสามารถทำลายการทำงานร่วมมือกันเป็นทีมได้ เพราะพวกเขาอาจจะกำลังแข่งขันกันเพื่อโบนัสอยู่ ถ้าจะให้รางวัลควรให้เป็นทีมที่สามารถทำงานได้ดี ถึงเป้าหมายด้วยกัน ไม่ใช่แค่รายบุคคล
อุปสรรคที่อาจเจอ
ทีมไม่ได้เป็น Cross-functional
พื้นฐานของการทำ Agile คือ ทีมที่รวมตัวกันของกลุ่มคนที่มีความถนัดที่หลากหลายเพื่อมาสร้างซอฟต์แวร์ที่มีคุณภาพร่วมกัน ถ้าเจอว่าทุกคนต่างมีหลายงานต้องรับผิดชอบ พยายามทำให้พวกเขาได้มาใช้ชีวิตอยู่ร่วมกัน มีปฏิสัมพันธ์กันทั้งในออนไลน์ และถ้าเจอตัวกันได้ ก็ออกไปกินข้าวด้วยกันบ้าง
ไม่มีลูกค้าอยู่ในสถานที่
บางทีมที่ลูกค้าอาจจะไม่ได้อยู่ในสถานที่เดียวกัน หรือคนละ timezone พยายามให้ลูกค้ามาพบปะทีมงานแบบตัวเป็นๆ บ้างสักครั้ง หลังจากนั้นก็ทำให้เกิดการสื่อสารอย่างสม่ำเสมอ ผ่านทางโทรศัพท์หรือช่องทางที่ไม่เป็นทางการอื่นๆ เช่น การแชท มนุษย์มีสายตาที่ตอบสนองต่อการเห็นหน้า พยายามให้ทีมเปิดกล้องเมื่อพูดคุยกัน เป็นเรื่องน่าประหลาดใจที่การมีภาพนิ่งของคนที่ไม่อยู่ในห้อง ก็สามารถสร้างความแตกต่างได้
ทีมใหญ่เกินไป
ถ้ามีทีมมากกว่า 10 คนจะเริ่มเกิดปัญหาเรื่องการสื่อสารและความรับผิดชอบภายในทีม การประชุมที่ประกอบด้วยคนจำนวนมากก็ใช้เวลานานมากกว่า รวมถึงยากที่จะให้ทุกคนมีปฏิสัมพันธ์ร่วมกันได้ พยายามหาทางที่จะแบ่งย่อยคนใน Project ให้กลายเป็นทีมเล็กๆ แต่มีเป้าหมายเดียวกัน เรื่องนี้สามารถศึกษาต่อได้ในเรื่องของ Scaling Lean and Agile Developement
ทีมเป็นทรัพยากรร่วม (Resource Pool)
การทำ Agile จะทำได้ดีกว่าหากเป็น Single Team การทำงานหลายโปรเจคในเวลาเดียวกัน เราจะเจอปัญหาว่าลำดับความสำคัญของแต่ละโปรเจคที่เปลี่ยนไป ก่อให้เกิดการขัดขวางในบางโปรเจค ซึ่งเป็นผลกระทบต่อเนื่องกัน
พยายามอย่าเอา Agile เข้าไปใช้ ถ้ายังมีการทำงานเช่นนี้อยู่
เกิดการกีดกันคนในทีมของตัวเอง
ถ้าพบว่าทีมพยายามหลีกเลี่ยงการทำงานกับใครคนใดคนหนึ่งในทีม ลองดูว่ามันมีปัญหาอะไร ให้เข้าไปคุยกับทีมเพื่อให้เขาอธิบายสิ่งที่เกิดขึ้นนี้ อาจจะให้ทาง HR เข้ามาช่วยสังเกตการณ์และหาทางแก้ไขด้วย
ทีมไม่รู้สึกถึงการมองเห็น
ทีมมักจะโดดเดี่ยวเมื่อขาดการปฏิสัมพันธ์กับทีมอื่น และไม่มีส่วนร่วมในเป้าหมายทางธุรกิจ อาจเป็นการคุ้มค่าที่จะลองเพิ่มการมองเห็นผลงานของทีมต่อผู้มีส่วนได้ส่วนเสีย รวมถึงเพิ่มความคิดเห็นต่อทีมเกี่ยวกับมูลค่าทางธุรกิจที่เกิดจากงานของพวกเขา
