โมเดลทีม Squad ของ Spotify นั้นล้มเหลว

"แม้แต่ Spotify เองก็ไม่ได้ใช้ 'the Spotify model' อย่าคุณใช้มันเลย"

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

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

บทความนี้อธิบายอย่างละเอียดว่าโมเดลนั้นผิดพลาดตรงไหน สิ่งที่เรียนรู้ได้จากความผิดพลาดของ Spotify และโมเดลอื่นที่แนะนำแทน

ผู้ร่วมเขียนไวต์เปเปอร์ฉบับนั้นและ Agile coach ของ Spotify เคยบอกคนนอกมานานแล้วว่าอย่าทำตามสิ่งนี้

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

ทำไมมันถึงทำงานได้ไม่ดี?

1. การบริหารแบบเมทริกซ์ไปแก้ปัญหาที่ผิด (Wrong Problem)

ทีม agile แบบ full-stack ทำงานได้ดีอยู่แล้ว แต่การบริหารในรูปแบบเมทริกซ์กลับสร้างปัญหาเพิ่มมากขึ้น

→ ทีมของ Spotify มีโครงสร้างที่คงอยู่ยาวนานอยู่แล้ว ดังนั้นข้อดีเรื่องไม่ต้องเปลี่ยนผู้จัดการเมื่อย้ายทีมจึงมีประโยชน์จำกัดมาก

→ ผู้จัดการสายวิศวกรรมรับผิดชอบเพียงระดับการพัฒนาอาชีพ แต่ไม่ได้ช่วยเรื่องทักษะความสัมพันธ์ระหว่างบุคคลและด้านอื่น ๆ

→ ไม่มีผู้จัดการคนเดียวที่ดูแลวิศวกรทั้งหมดของแต่ละทีม คนที่ทำหน้าที่คล้าย mini-CEO อย่าง product manager จึงไม่มีคู่เทียบแบบ mini-CTO นั่นหมายความว่าไม่มีใครรับผิดชอบการสนับสนุนทีมเทคนิคหรือการต่อรองลำดับความสำคัญ หากเกิดความเห็นไม่ตรงกันภายในทีมเทคนิค product manager ต้องไปเจรจากับวิศวกรทุกคนเอง ถ้ายังไม่จบ ก็ต้องไปเจรจากับ engineering manager ฝั่ง backend/web/mobile อย่างน้อย 3 คน หรือ escalate ไปถึงหัวหน้าฝ่ายวิศวกรรมของแผนก

[ สิ่งที่เรียนรู้ได้จากความผิดพลาดของ Spotify ]

→ โดยทั่วไปในทีม product-design-tech จะมีวิศวกรมากกว่า จึงควรมีผู้จัดการที่ดูแลวิศวกรทั้งหมดเพื่อให้มีเส้นทางสำหรับการ escalate เมื่อเกิดความขัดแย้งภายในทีม

→ product manager ควรมีเพื่อนร่วมงานระดับเท่าเทียมสำหรับคุยเรื่องเทคนิคได้ เช่นเดียวกับความสัมพันธ์ระหว่าง CEO และ CTO

2. พึ่งพาความเป็นอิสระของทีมมากเกินไป

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

เมื่อบริษัทใหญ่ขึ้น ความสามารถที่ซ้ำซ้อนกันในแต่ละทีมจะถูกรวมเป็นทีมใหม่เพื่อเพิ่มประสิทธิภาพ

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

→ Spotify ไม่ได้กำหนดกระบวนการร่วมมาตรฐานสำหรับการทำงานข้ามทีม แต่ละทีมเข้าร่วมในแบบของตัวเอง ทำให้ผลิตภาพของทั้งองค์กรลดลง

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

[ สิ่งที่เรียนรู้ได้จากความผิดพลาดของ Spotify ]

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

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

→ วิธีประเมินความสำเร็จก็ควรถูกกำหนดโดยผู้บริหารด้วย เพื่อให้สามารถประสานลำดับความสำคัญของการทำงานข้ามทีมได้

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

"ถ้าจะให้ผมเลือกสิ่งเดียวที่อยากย้อนกลับไปแก้ที่ Spotify มันคือเราไม่ควรเน้นเรื่อง autonomy มากเกินไป" - Joakim Sunden อดีต Agile Coach ของ Spotify

3. การทำงานร่วมกันเป็นเพียงความสามารถที่ถูกสมมติว่ามีอยู่

แม้ Spotify จะเปิดให้แต่ละทีมควบคุมวิธีการทำงานของตนเองได้ แต่หลายคนกลับไม่มีความเข้าใจพื้นฐานเกี่ยวกับ agile เพียงพอ

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

ไม่มีภาษากลางสำหรับประเมินปัญหาในกระบวนการ วิธีแก้ หรือการวัดผลอย่างมีประสิทธิภาพ ในความเป็นจริงมันไม่ใช่ agile ด้วยซ้ำ แต่เป็นเพียง "Not-Waterfall"

Spotify มี "Agile coach" ที่คอยสอนและเสนอแนวทางปรับปรุงกระบวนการให้แต่ละทีม เจตนาดี แต่มีโค้ชไม่พอที่จะช่วยทุกทีม

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

[ สิ่งที่เรียนรู้ได้จากความผิดพลาดของ Spotify ]

→ การทำงานร่วมกันเป็นทักษะที่ต้องอาศัยความรู้และการฝึกฝน ผู้จัดการไม่ควรสมมติว่าผู้คนเข้าใจ agile practices ที่มีอยู่แล้ว

→ เมื่อบริษัทใหญ่พอ แต่ละทีมต้องการองค์กรสนับสนุนที่ช่วยให้วางแผนภายในทีมและทำให้การทำงานข้ามทีมเกิดขึ้นได้ Program Management ควรรับผิดชอบต่อ planning process ส่วน Program Manager ที่ทำหน้าที่เต็มเวลาควรทำให้ทีมทำงานได้เหมือนที่ Product Manager และ Engineering Manager ต่างทำบทบาทของตนเองพร้อมทั้งร่วมมือกันได้

4. เมื่อตำนานถูกสร้างขึ้นแล้วจะเปลี่ยนยาก

การที่ Agile Scrum เสนอคำอย่าง burndown หรือ sprint ก็เพราะต้องตั้งชื่อให้แนวคิดใหม่ที่ถูกนำเสนอ

Spotify นำเสนอคำใหม่อย่าง Missions, Tribe, Squads, Chapter Lead ซึ่งสร้างภาพลวงว่า "เราสร้างสิ่งที่ต้องเลือกใช้คำพิเศษบางอย่างเท่านั้นถึงจะอธิบายได้"

หากตัดคำพ้องที่ไม่จำเป็นเหล่านี้ออกไป Spotify model ก็เป็นเพียงกลุ่มของ "Cross-Functional Team" ที่มี autonomy มากเกินไปและมีโครงสร้างการจัดการที่อ่อนแอ

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

[ สิ่งที่เรียนรู้ได้จากความผิดพลาดของ Spotify ]

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

→ จงเพิ่มประสิทธิภาพด้านความเข้าใจ เพื่อรักษาผลิตภาพขององค์กร ควรประเมินคุณค่าของทุกสิ่งใหม่ที่คนในองค์กรต้องเรียนรู้

*** ให้ทำแบบนี้แทน (แน่นอนว่าไม่มีทางลัด)

เหตุผลที่คุณค้นหา Spotify model อาจเป็นเพราะต้องการออกแบบโครงสร้างทีมของคุณเอง แต่อย่าหยุดแค่นี้ จงศึกษาเพิ่มเติม

มีบริษัทจำนวนมากที่ผ่านการทดสอบของเวลายาวนานกว่า Spotify และได้เขียนเรื่องนี้ไว้มากกว่า

Spotify ในปี 2012 ไม่สามารถหาวิธีรักษาความเร็วและความคล่องตัวของทีมเล็กไว้ในองค์กรขนาดใหญ่ได้

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

คำแนะนำของผู้เขียนเกี่ยวกับวิธีทำงานแบบอื่น

• องค์กร product-development-design ของคุณมีคนมากกว่า 200 คนหรือไม่? ตอนที่ผมอยู่ Fitbit นั้น "Scaled Agile Framework" เหมาะมาก

• ถ้าน้อยกว่า 200 คน ผมแนะนำ "Shape Up By Basecamp" สตาร์ตอัปถัดไปของผมก็ตั้งใจจะใช้โครงสร้างแบบนี้

• ลองอ่านหนังสือ "Essential Scrum" และ "Team Topologies"

[sonim1]

ขอบคุณสำหรับบทความดี ๆ ครับ

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

ตั้งแต่ต้นปีนี้ เราได้ยึดตาม Shape Up ของ Basecamp และผลลัพธ์คือเราสามารถส่งมอบคุณภาพของผลิตภัณฑ์ที่ดีขึ้นได้

[godrm]

จริงด้วยครับ กรณีศึกษาความล้มเหลวก็สำคัญพอ ๆ กับกรณีศึกษาความสำเร็จเลยนะครับ

[xguru]

ตอนที่ white paper เรื่อง "Scaling Agile" ฉบับนี้ถูกเผยแพร่ครั้งแรก ผมตกใจมากจนเอาไปแชร์และเขียนลงบล็อกด้วย... เป็นบทความที่ช็อกจริง ๆ เศร้าเลย

หนึ่งในแนวทางที่ผู้เขียนแนะนำคือ "Shape Up ของ Basecamp" ซึ่งเคยแนะนำไว้ใน GeekNews แล้ว สำหรับองค์กรขนาดเล็ก ผมก็แนะนำแนวทางนี้เช่นกัน

Shape Up - วิธีทำงานอย่างยอดเยี่ยมขององค์กรขนาดเล็ก [PDF] https://th.news.hada.io/topic?id=427

[xguru]

ปฏิกิริยาของพนักงาน Spotify ต่อบทความนี้

ฉันอยู่ที่นั่นมา 6 ปี และนี่แม่นยำ 100% https://twitter.com/solomonjames/status/1258930064441425920

ฉันลาออกในปี 2019 และเหตุผลใหญ่ที่ลาออกก็คือปัญหาที่อยู่ในบทความนี้ https://twitter.com/ayyyylo/status/1253658456621539328

ปฏิกิริยาจากคนอื่นที่ทำตามแล้วล้มเหลว

Zalando ทำตามในปี 2016 และก็รู้ได้อย่างรวดเร็วว่าวิธีนี้ใช้ไม่ได้ผล https://twitter.com/chilicoder/status/1253429837185691656

Typeform ก็พยายามทำตามสิ่งนี้แล้วล้มเหลว https://twitter.com/jharmn/status/1252229296522842121

ทันทีที่ Spotify เขียนเรื่องนี้ลงบล็อก เราก็ลองทำตาม และมันเป็นหายนะ https://twitter.com/braedon/status/1256122236424957953