7 Pitfalls ของการทำ Squad และ Tribe ตาม Spotify Model
ถ้าคุณเคยได้ยิน หรือคุณอยู่ในทีมที่มีคำเรียกว่า Squad, Tribe หรือ Chapter แสดงว่าคุณน่าจะกำลังใช้ Spotify Model อยู่ ไม่ว่าคุณจะรู้ตัวอยู่หรือไม่ก็ตาม แต่สิ่งที่หลายคนอาจจะไม่รู้… คือโมเดลนี้มีหลุมพรางแอบซ่อนอยู่
ในบทความนี้ ผมจึงอยากมาแชร์ Pitfall ของการนำ Spotify Model ไปใช้ในแบบที่ไม่เหมาะสมหรือไม่ถูกต้องในแบบต่างๆ ที่ผมเคยได้เห็นมา พร้อมอธิบายว่าทำไมครับ
มาดูกันว่าคุณหลบทั้ง 7 Pitfalls นี้ได้มั้ย
อะไรคือ Spotify Model
ตั้งแต่ Henrik Kniberg และ Anders Ivarsson ได้แนะนำให้โลก Agile รู้จักกับ Spotify Model (การสเกล Agile ที่ใช้กับ Spotify ในขณะนั้น) เมื่อปี 2012 สิ่งนี้ก็กลายเป็นประเด็นร้อนและเป็นเทรนด์ในการทำ Agile Transformation ต่อมาอีกหลายปี
ด้วยความดัง(มาก)ของ Spotify Model ผมขอไม่เล่าละเอียดว่า Spotify Model หน้าตาเป็นอย่างไร แต่ถ้าใครอยากอ่านเพิ่มเติม สามารถดูได้ที่บทความด้านล่างนี้
ทั้งนี้ผมขอรีแคปสั้นๆ เกี่ยวกับ Squad และ Tribe ที่จะเป็นโฟกัสหลักเราสักนิด เริ่มจาก Squad ซึ่งก็คือทีม 1 ทีมนั่นแหละ เทียบเท่ากับ Scrum Team โดยเน้นว่าต้องเป็น Cross-functional คือมีคนที่มีทักษะรวมกันเพียงพอในการทำงานได้สำเร็จตั้งแต่ต้นจนจบ เช่น Design, Develop, Test และ Release ครบในตัว และแต่ละ Squad ก็จะมีเป้าหมายเป็นภารกิจระยะยาวของตัวเอง ซึ่งมักจะเป็นส่วนหนึ่งของ Product ในภาพใหญ่ ส่วน Tribe คือการรวมหลาย Squad ที่อยู่ใน Area ที่เกี่ยวข้องมาอยู่ด้วยกันเป็นเผ่าขึ้นมา
หลังจากผ่านมา 1 ทศวรรษ เราก็ได้เห็นคนนำ Spotify ไปใช้หรือปรับใช้เยอะแยะมากมาย และเป็นที่รู้กันว่า Spotify เองก็ไม่ได้ใช้โมเดลนี้แล้ว (ดูได้จากบทความ Failed #SquadGoals) แต่ได้มีการปรับเปลี่ยนพัฒนาตามความเหมาะสมไปเรื่อยๆ เพราะสิ่งนี้ไม่ใช่ Framework แต่เป็นแค่ Snapshot ของวิธีการทำงานของ Spotify เมื่อปี 2012 เท่านั้นเอง ตามที่ Henrik และ Anders ได้กล่าวไว้ใน White Paper ว่า…
“Spotify is (like any good agile company) evolving fast. This article is only a snapshot of our current way of working — a journey in progress, not a journey completed. By the time you read this, things have already changed.”
การประยุกต์ใช้
จริงๆ การนำโมเดลการทำงานที่ประสบความสำเร็จของคนอื่นมาใช้กับเรานั้นไม่ใช่เรื่องผิดแปลกอะไร เพราะเราไม่ได้ต้อง Reinvent the Wheel กันทุกๆ องค์กร แต่การนำไปใช้นั้น ย่อมไม่สามารถ Copy & Paste เฉยๆ ได้หรอก เพราะแต่ละองค์กรไม่เหมือนกัน เหมือนกับที่เสื้อผ้าไม่สามารถมีแค่ไซส์เดียวให้ใครใส่ก็ได้ (หรือถ้ามีพวก Free Size / One Size Fits All ก็มักจะไม่สวยอยู่ดี)
ดังนั้นสิ่งสำคัญที่ต้องรู้ เพื่อเลือกประยุกต์หรือ Adapt ใช้โมเดลของคนอื่นได้ คือ…
- เหตุผลเบื้องหลังการดีไซน์โมเดลแต่ละจุด เพื่อประกอบการตัดสินใจว่าเราจะทำแบบเดียวกันมั้ย หรือทำไม่ได้เพราะอะไร ซึ่งถ้าไม่เข้าใจเหตุผลของผู้ดีไซน์ เราอาจจะเลือกใช้ไปแก้ปัญหาผิดจุดผิดที่ผิดทางได้ง่ายๆ
- เข้าใจความต่อเนื่อง เป็น Dependency กันในแต่ละจุด เช่น การทำ A ทำได้เพราะทำ B ด้วย ซึ่งถ้าเราไม่เข้าใจจุดนี้ เราอาจจะหยิบแต่ A ไปทำ แล้วไม่ทำ B ก็อาจจะพังได้เลยนะ
เกริ่นมายาวแล้ว ผมขอเข้าเรื่อง Pitfall ต่างๆ ที่ผมเคยเห็นมาดีกว่า
Pitfall #1: Squad คนเยอะไป
ที่ผมได้เห็นมาคือ Squad ที่มีคน 20+ คน (มีทีมแบบนี้อยู่จริงๆ นะครับ) จะส่งผลชัดมากในการประชุม Daily Sync (หรือ Daily Scrum, Stand up Meeting, etc. แล้วแต่จะเรียก) เพราะกลายเป็นการที่แต่ละคนมา Report ให้หัวหน้าตัวเองฟัง แต่คนอื่นๆ ไม่ได้สนใจหรือไปทำอย่างอื่น แค่รอเวลาถึงคิวตัวเองพูด คนส่วนใหญ่ไม่เข้าใจงานของคนอื่นในระดับที่ทำแทนกันได้ ช่วยงานกันได้
ทฤษฎีในการสร้างทีมที่มีคนพอดีและไม่เยอะเกินไปนั้นไม่ใช่เรื่องใหม่ และเขียนไว้ชัดในหลายๆ ที่ เช่น ใน Scrum Guide ระบุว่าทีมต้องไม่เกิน 10 คน หรือที่ AWS ก็มีการใช้กฎ 2-pizza Team
เหตุผลเบื้องหลังกฎนี้คือการสร้างทีมที่มี Autonomy สูง และ Self-organizing ได้ในตัวเอง ดังนั้นทีมต้องมี Communication และ Visibility ภายในที่ดีมากในระดับที่ทุกคนเข้าใจงานทั้งหมดในทีม เข้าใจว่าใครทำอะไรอยู่ และสามารถช่วยงานกัน ทำแทนกัน ปรับเปลี่ยนการทำงานได้ตลอดเมื่อสถานการณ์เปลี่ยน และแน่นอนครับว่าพอคนเยอะเกินไป Communication ในระดับนี้ย่อมเกิดไม่ได้ แค่จะทำให้ทุกคนฟังงานของคนอื่นทั้งหมดทุกวันยังยากเลย
ถ้าจะพูดให้แรงขึ้นหน่อย ผมก็ขอพูดว่า
ทีมที่มีคนเกิน 12 คน ไม่ใช่ทีมครับ เป็นแค่การเอาคนมารวมๆ กัน แต่ไม่ได้มีความเป็นทีม
Pitfall #2: Squad ไม่ใช่คนทำงาน แต่เป็นตัวแทนทีมอื่น?!
กลายเป็นว่าบางส่วนของ Squad ดันไม่ใช่คนทำงานประจำ Squad แต่เป็นหัวหน้าหรือตัวแทนจากทีมอื่นที่มีความเกี่ยวข้องมาเข้าร่วมซะงั้น
จากที่ลองวิเคราะห์ดู สาเหตุอาจจะเกิดจากการอยากสร้าง Cross-functional Team เพื่อให้ Squad หนึ่งสามารถทำงานได้ตั้งแต่จนจบแบบสร้าง Value ให้กับองค์กรได้จริงๆ ซึ่งเป็นคอนเซ็ปต์ที่ดีมากครับ และจริงๆ การสร้าง Squad ก็ต้องเป็น Cross-functional Team
แต่การสร้าง Cross-functional Team ที่แท้จริง ต้องอาศัยการปรับโครงสร้างองค์กรมาช่วยพังทลายกำแพง Silo เดิมๆ ที่แบ่งทีมตามความสามารถเฉพาะงาน (เช่น ทีม Marketing, BA, Test) ให้กลายเป็น Working Team ใหม่ที่ประกอบด้วยคนจากแต่ละ Silo เดิมมารวมตัวกัน จนสามารถทำงานร่วมกันเป็น End-to-End ได้จริงๆ เพื่อลดปัญหาและ Overhead ของการส่งต่องานข้ามทีมกัน และลดกำแพง Silo ลง
แต่เนื่องจากหลายองค์กรเลือกที่จะยังไม่พัง Silo (เพราะเป็นเรื่องใหญ่และยาก) แต่แค่จัด Squad โดยให้มีคนจากทุก Silo มารวมกัน ดังนั้นหัวหน้าของทีม Silo ต่างๆ ย่อมรู้สึกไม่สะดวกใจที่จะให้ลูกน้องตนเองกระจายไปอยู่ตาม Squad และไม่ได้ Assign งานเองหรือรีวิวงานเองอีกต่อไป จึงใช้โมเดลที่ตัวเองไปร่วมอยู่กับ Squad เอง แล้วกลับมาสั่งงานน้องๆ ต่ออีกที ซึ่งไม่ได้ลดการส่งต่องานและยังคงเป็น Silo เหมือนเดิม
Flight Levels
ถึงตรงนี้ ผมคิดว่าน่าจะเป็นประโยชน์ที่จะพูดถึง Framework ที่ชื่อว่า Flight Levels สักหน่อย ซึ่งอาจจะเป็นทางเลือกในการแก้ปัญหานี้ได้ครับ เนื่องจากการสร้าง Cross-functional Team ที่แท้จริงนั้นยาก(มาก) Flight Levels จึงมองการทำงานออกเป็นหลายระดับ (Levels) โดยที่ Level 1 ล่างสุดคือทีมที่ทำงานในระดับ Operation ซึ่งก็อาจจะเป็น Silo Team แบบเดิมๆ ที่เราคุ้นเคยกันก็ได้ เช่น ทีม Test, Marketing แต่แน่นอนว่าทีมเหล่านี้ทำงานได้แค่ส่วนหนึ่งของสายพานการผลิตเท่านั้น ไม่ใช่งาน End-to-End จริงๆ ดังนั้นต้องอาศัยการ Coordinate กันอย่างดีของแต่ละทีมร่วมกัน กลายเป็น Level 2 (End-to-End Coordination) ซึ่งมีลักษณะเป็น Virtual Team มารวมตัวกัน เพื่อให้การ Coordinate ดีและคล่องตัว แต่ไม่ใช่ทีมจริงๆ ในลักษณะของ Scrum Team หรือ Squad
แน่นอนว่าถ้าเรากำลังสร้าง Coordination ในลักษณะ Virtual Team แบบนี้ เราคงใช้ทฤษฎีและวิธีปฏิบัติแบบเดียวกับที่ใช้กับ Scrum Team หรือ Squad ไม่ได้ (กลับไปดูข้อ 2 ในหัวข้อการประยุกต์ใช้ด้านบน) ยกตัวอย่างง่ายๆ เช่น การสร้าง Virtual Team แบบนี้ที่เอาตัวแทนทีมมาคุยกัน แต่มี Virtual Team สัก 3 ทีม แล้วใช้ Daily Scrum ทุกเช้า ก็คงไม่แปลกใจที่ตัวแทนทีมที่ต้องเข้า Daily Scrum ทุกเช้า 3 ทีม และอาจจะยังต้องกลับมาประชุม Daily ของทีมตัวเองอีก จนเกิดการ Burn Out พลอยทำให้ลาออก หรือบอกว่าการทำ Agile นั้นเหนื่อยเกินไป
ดังนั้นถ้าคุณกำลังสร้าง Squad ที่เป็นแค่ Virtual Team เอาตัวแทนทีมอื่นมารวมกัน อย่ารันทีมนี้แบบ Scrum หรือ Squad เด็ดขาด! (และจริงๆ ก็ไม่ควรเรียกว่า Squad)
Pitfall #3 : เอาทีมแบบเดิมๆ มาเรียกว่า Squad
ทีมแบบเดิมๆ ในที่นี้ ผมหมายถึงทีมที่รวมคนทำงานเฉพาะเรื่องเดียวกันมารวมกัน หรือก็เป็น Silo Team นั่นแหละ เพราะทีมแบบนี้ทำงานได้แค่เรื่องนี้เท่านั้น ไม่สามารถสร้างงาน End-to-End ได้ และไม่ใช่ Cross-functional Team นั่นเอง
สาเหตุก็คล้ายกับ Pitfall #2 เพราะว่าการทำ Cross-functional Team มันยาก คนจัดทีมเลยสบายใจกว่าที่จะยกทีมเดิมๆ มาวางเป็น Squad แล้วไปแก้ปัญหาการ Coordination ส่งต่องานกันที่ระดับ Tribe แทน แต่ก็ยังคงรัน Squad ไปตามแบบฉบับของ Spotify ซึ่งไม่ได้เหมาะกับทีมแบบนี้
ยกตัวอย่างเช่น Tribe สมมุติหนึ่งทำเรื่อง Marketing มีหน้าที่เพิ่มยอดขาย และมี Squad หนึ่งเป็นทีมที่ทำ Partner Promotion โดยเฉพาะ ซึ่งคนใน Squad นี้แบ่งงานกันไปตามพาร์ทเนอร์ เช่น นาย ก คุยกับพาร์ทเนอร์ประเภทห้างสรรพสินค้า และนาย ข คุยกับพาร์ทเนอร์ประเภทโรงพยาบาล เป็นต้น เราคงจินตนาการได้ไม่ยากว่า Daily Sync ของ Squad นี้ก็จะเข้าสู่โหมดที่แต่ละคน Report งานกับหัวหน้า และไม่ได้สนใจงานของคนอื่น เพราะ นาย ก กับ นาย ข แทบไม่เคยต้องประสานงานกันเลย แม้จะอยู่ Squad เดียวกัน และจะช่วยเหลือทำแทนกันก็ไม่ได้ด้วย และการจะทำ Retrospective ก็คงมีแต่ประเด็นส่งออกไปนอกทีม ไม่ใช่เรื่องที่จะปรับปรุงในทีมเองได้ (เพราะไม่ได้ทำงานร่วมกัน)
Pitfall #4 : หนึ่งคน ทำงานหลาย Squad
อาจจะดูคล้ายกับ Pitfall #2 แต่แทนที่ตัวแทนทีมด้วยคนเก่งเฉพาะด้านที่มีปริมาณน้อย เลยทำให้มีคนทำเรื่องนี้อยู่ในทุกทีมและทุก Squad ไม่ได้ (อันนี้ไม่ใช่ปัญหาเฉพาะ Spotify Model แต่สามารถพบเจอในการแบ่ง Scrum Team ได้เหมือนกัน)
ปัญหานี้ต้องแยกแยะก่อนว่าสาเหตุมาจากเรื่องสกิลเฉพาะด้านจริงหรือไม่ โดยอาจจะดูจากจำนวนคนที่วิ่งข้าม Squad มีเยอะมั้ย เพราะปัญหาจริงๆ อาจจะไม่อยู่ที่สกิลเสมอไป
1. ปัญหาสกิลเฉพาะทางเป็น Bottle Neck
อันนี้เราจะต้องพยายาม Scale สกิลนี้ให้เกิดขึ้นในทุกทีมให้ได้ เป็นปัญหาที่ต้องแก้ในระยะยาว อาจจะทำไม่ได้ในเวลาสั้นๆ (แต่ถ้าไม่เริ่มแก้ ก็จะไม่มีวันแก้ได้) แนวทางการแก้ปัญหานี้มีได้หลากหลาย
- สร้างทีมเฉพาะสกิลนี้ออกมาเป็น Supporting Team ข้างนอก แต่จะไม่เหมาะถ้าสกิลนี้ถูกใช้อยู่ตลอดเวลาจากทุก Squad
- ใช้คอนเซ็ปต์ Travelers ของ LeSS Framework ที่แปลง Expert กลายเป็น Traveler เวียนไปช่วยงานทุกทีมพร้อมกับค่อยๆ Build สกิลให้คนในทีมนั้นไปด้วย
- ใช้คอนเซ็ปต์ Guild ของ Spotify เองในการส่งเสริมการแชร์ความรู้และ Knowledge บางเรื่องระหว่าง Squad
2. ปัญหาไม่ใช่เรื่องสกิล
อาจจะดูได้จากคนส่วนใหญ่ใน Squad ทำงานหลาย Squad ไปด้วยพร้อมๆ กัน อันนี้น่าจะเป็นการแบ่งทีมที่ผิดและไม่ได้เข้าใจว่าจริงๆ Squad ควรจะต้องเป็น Dedicated Team ซึ่งก็ต้องกลับมาทำความเข้าใจกันก่อนว่า Spotify Model นั้นทำไปเพื่อสร้างทีมเล็กๆ หลายทีมที่ Self-managing และมี Autonomy ในตัว ดังนั้นต้องมีความเป็นทีมสูงมาก และมี Trust ในทีมที่ดี ทีมที่ไม่เห็นว่างานคนอื่นๆ ในทีมมีอะไรบ้าง (ซึ่งอาจจะอยู่นอก Squad) และคนไม่ได้มีเวลาให้กับทีมเต็มที่ ย่อมทำให้ทีม Self-managing ไม่ได้ พาลส่งผลให้คนรับงานหลายทางเกิดอาการล้าและ Burn out ตามมาด้วย
ถ้าคุณกำลังสร้างทีมที่ไม่ใช่ Dedicated Team แต่เป็นแค่ Virtual Team อย่าใช้ Spotify Model แต่หาโมเดลอื่น (เช่น Flight Levels) ที่เหมาะสำหรับคุณ
Pitfall #5 : มีตำแหน่ง Squad Lead
แน่นอนว่าใน Spotify Model ไม่ได้มี Role นี้อยู่ แต่ก็ไม่ผิดถ้าเราจะสร้าง Role อะไรมาเพิ่มให้เหมาะกับองค์กรเรา แต่! เราก็ต้องกลับไปถกกันถึงจุดประสงค์ของ Spotify Model ในการสร้างทีมย่อยหรือ Squad ให้มี Autonomy ดี มี Alignment สูง และ Self-organizing ซึ่งประเด็นหลังนี่แหละที่ขัดต่อการมี Team Lead เพราะ Self-organizing ย่อมเกิดไม่ได้ถ้าจะต้องให้ Lead คอยสั่งการเรื่องต่างๆ อยู่เสมอ ดังนั้นเราจะพบเห็นการเปลี่ยนแปลงจากตำแหน่ง Lead แบบเดิมๆ ไปเป็น Servant Leader ในโครงสร้างทีมที่ Self-organizing อาทิ Scrum Master คือ Servant Leader ใน Scrum Team หรือ Agile Coach ก็คือ Servant Leader ใน Spotify Squad นั่นเอง
งาน Servant Leader นั้น ด้วยชื่ออาจจะฟังดูเหมือนง่าย เพราะแค่คอยรับใช้ (Serve) ทีม แต่จริงๆ แล้วยากกว่าการเป็น Lead แบบเดิมมาก เพราะจะต้องเปลี่ยนจากการคอยสั่งงานและติดตามงาน กลายเป็นการดูแลให้ปัจจัยทุกอย่างรอบด้านส่งเสริมให้ทีมสามารถทำงานได้ ตัดสินใจเรื่องต่างๆ เอง และบริหารจัดการงานเองได้ โดยที่ตนเองไม่ต้องออกคำสั่งอีกต่อไป ซึ่งสิ่งนี้ไม่ได้เกิดขึ้นเพียงแค่จากการหยุดออกคำสั่ง แล้วหันมาเป็น Facilitator ของการประชุมแทน (ไม่เชื่อลองทำดูได้ครับ ผมรับประกันว่าพังแน่นอน) แต่การเปลี่ยนแปลงนี้จะต้องใช้เวลาพอสมควรสำหรับ Lead ในการค่อยๆ สร้างสภาพแวดล้อมที่ดีให้ทีมสามารถช่วยกันคิดและตัดสินใจได้ โดยอาจจะเริ่มจากเรื่องเล็กน้อย แล้วค่อยๆ เพิ่มความรับผิดชอบให้ทีมตัดสินใจมากขึ้นเรื่อยๆ ในขณะที่ Lead ต้องคอย Coach หรือสอนทักษะที่ทีมต้องมีในการตัดสินใจเรื่องต่างๆ มากขึ้นด้วยเช่นกัน
ถ้าเราจะมีตำแหน่ง Squad Lead ก็ย่อมได้ แต่ถ้าจุดประสงค์ของการสร้าง Squad นั้นเพื่อก่อให้เกิด Self-organizing Team ก็อย่าลืมภาระหน้าที่ในการเป็น Servant Leader ด้วยเช่นกัน และบางทีอาจจะดีกว่าถ้าเราจะเปลี่ยนไม่ใช้ชื่อที่มีคำว่า “Lead” เลยในที่สุด
Pitfall #6 : Squad เดียว แต่อยู่ในหลาย Tribes
ต้องเล่าก่อนว่า Tribe สำหรับ Spotify คือการรวมกลุ่มกันของ Squad ที่ทำเรื่องใกล้เคียงกัน อยู่ใน Feature Area เดียวกัน ซึ่งแต่ละ Squad อาจจะมี Dependency พึ่งพากันด้วยระดับหนึ่ง โดยเมื่อรวมทุก Squad ใน Tribe แล้วควรมีจำนวนคนไม่เกิน 100 คน (Dunbar’s Number) และมีหัวหน้าเผ่า (Tribe Lead) ที่คอยดูแลสารทุกข์สุกดิบต่างๆ ให้กับคนในเผ่า แต่ไม่ได้เป็นคนสั่งการ เพราะ Squad ต่างก็มี Autonomy ในตัวเอง
คราวนี้ Pitfall แปลกๆ ที่ผมเจอมาคือการสร้าง Tribe ที่ไม่ได้มองในภาพ Feature Area เดียวกัน หรือมองภาพนี้ไม่ขาดจริงๆ เลยเกิดทำให้แต่ละ Squad ตกอยู่ได้หลายๆ Tribe ซึ่งผมมองว่าสร้างความสับสนให้คนทำงานมาก แค่การสร้าง Matrix Organization แบบ Spotify ก็ยากที่จะทำความเข้าใจแล้ว แต่พอคนๆ นึงอยู่ได้ในหลาย Tribe (และในกรณีที่ผมเจอคืออยู่ได้ในหลาย Squad ด้วย) มันยิ่งยากต่อการเข้าใจและจัดการมาก และอาจส่งผลให้ Squad ต้องรับงานจากหลายทาง (เพราะว่า Tribe ถูกสร้างตาม Dependency ที่มีต่อกันสูง แสดงว่า Squad ที่อยู่หลาย Tribe ก็จะมี Dependency จำนวนมากนั่นเอง) และไม่รู้จะโฟกัสงานจากทางไหนเผ่าไหนก่อนดี หรือแย่ไปกว่านั้นก็คือทำมันทุกอย่างจากทุกทางเลย ก็จะทำให้ทุกงานเสร็จช้าไปหมด
การทำงานหลายอย่างพร้อมกัน บางครั้งอาจถูกเข้าใจผิดว่าเป็นการทำงานได้เยอะ มีประสิทธิภาพสูง แต่จริงๆ แล้วมีทฤษฎีและหลักการมากมายคัดค้านการกระทำแบบนี้ เช่น การใช้ WIP Limits ใน Kanban หรือกฎ Little’s Law เป็นต้น
Pitfall #7 : สร้าง Tribe ตาม OKR
อันนี้ฟังแว้บแรกอาจจะดูไม่ผิดอะไร เพราะถ้าเรามี Squad หลายๆ Squad ที่ทำเพื่อ OKR เดียวกัน การจะนำมารวมกลุ่มกันเป็น Tribe ก็คงไม่แปลก แต่ต้องดูให้ดีด้วยว่าแต่ละ Squad นี้พึ่งพาและมี Dependency ต่อกันภายใน Tribe มากกว่าข้างนอก Tribe จริงหรือไม่
แต่สาเหตุหนึ่งที่ผมไม่ค่อยเห็นด้วยกับการแบ่ง Tribe ตาม OKR เพราะองค์กรส่วนใหญ่มีหลาย OKR และแต่ละทีม Squad ก็มักจะต้องตอบโจทย์หลาย OKR ด้วยเช่นกัน ยกตัวอย่างเช่น ทีม Marketing Squad ที่อยู่ในบริษัทที่มี OKR#1 เพิ่มยอดขาย และ OKR#2 Retain ลูกค้าเก่า ก็คงไม่สามารถเลือกได้ว่าจะทำแค่ OKR ข้อใดข้อหนึ่งเท่านั้น ดังนั้นในเคสจริงที่ผมได้เห็นมา จึงเกิดการสร้าง Tribe หลาย Tribe (ตามจำนวน OKR) และแทบทุก Squad ก็จะต้องอยู่ในแทบทุก Tribe เหล่านี้ กลายเป็นภาพขั้นกว่าของ Pitfall #6 ไปในที่สุด ซึ่งจริงๆ ถ้าเพียงองค์กรลองมองและปรับ Tribe ให้ Simple ตรงตัวมากขึ้น เหลือเพียงแค่ 1–2 Tribe ภาพการทำงานจะดูดีขึ้นเยอะเลยทีเดียว
ดังนั้นผมแนะนำให้สร้าง Tribe โดยคำนึงถึง Dependency ระหว่าง Squad ที่ต้องพึ่งพากันเป็นหลักก่อน และอย่าเอา OKR หรือภาพองค์กรเก่า หรือสิ่งอื่นใด มาเป็นตัวบ่งบอกว่าควรจะมี Tribe อะไรบ้าง ถ้ามันไม่ช่วยลด Dependency นี้ได้
ถึงตรงนี้ ผมขอแทรกความเห็นส่วนตัวเล็กน้อยนอกตำรา Spotify Model ว่าการสร้าง Tribe นอกจากเพื่อลดปัญหา Dependency แล้ว ยังอาจจะใช้ส่งเสริม Alignment ได้ด้วย เช่น Squad ที่ควรจะต้อง Align ไปในทางเดียวกัน อาจจะเหมาะสมที่จะอยู่ใน Tribe เดียวกัน และมี Tribe Lead คอยดูแลให้ Alignment มีสุขภาพดีอยู่เสมอ (แต่ก็ย้ำอีกทีว่า OKR ไม่ใช่ Alignment นะครับ)
สรุป Key Takeaways
จาก Pitfalls 7 ข้อที่เล่ามา ล้วนแต่เป็นสิ่งที่ผมได้เคยประสบพบเจอมา เลยอยากมาเล่าสู่กันฟังครับ และขอทิ้งท้ายเป็น Key Takeaways เล็กน้อยว่า
- ถ้าอยากใช้ Spotify Model สำคัญมากที่คุณจะต้องสร้าง Cross-functional Team ให้ได้ด้วย ซึ่งส่วนใหญ่คือการที่ต้อง Restructure องค์กรด้วยนะ อย่าไปใช้ Spotify Model ทับลงบน Silo เดิมๆ!
- ทำให้ทุกอย่างตรงไปตรงมา เข้าใจง่ายๆ เช่น 1 คน อยู่ได้แค่ 1 Squad และ 1 Squad ก็อยู่ได้แค่ 1 Tribe นะ (อย่าสร้าง Unnecessary Complexity)
- ถ้าทำสองข้อข้างบนไม่ได้ ผมแนะนำใช้โมเดลหรือ Framework อื่นดีกว่า เช่น Flight Levels ที่สามารถปรับใช้กับ Silo แบบเดิมๆ ได้เพื่อให้การทำงานร่วมกันดีขึ้น
ทั้งนี้อย่าลืม Agile Frameworks ตัวอื่นๆ ที่ใช้ดีมีประโยชน์ไม่แพ้กันเป็นทางเลือกให้ลองไปปรับใช้ดู ซึ่งถ้าเราสามารถทำ 2 ข้อแรกได้จริงๆ ก็ไม่จำเป็นต้องใช้แต่ Spotify Model เพราะเรายังมี LeSS หรือ Scrum@Scale ให้ใช้ได้เช่นกัน
สำหรับชาวเทคคนไหนที่สนใจเรื่องราวดีๆแบบนี้ หรืออยากเรียนรู้เกี่ยวกับ Product ใหม่ๆ ของ KBTG สามารถติดตามรายละเอียดกันได้ที่เว็บไซต์ www.kbtg.tech
