Spotify Engineering Culture … อย่า Copy / Paste นะ
ช่วงครึ่งปีที่ผ่านมา ผมมีโอกาสได้รู้จัก Agile Process ที่มาจาก Spotify แล้วผมก็เห็นหลายๆที่พูดถึงเรื่องนี้โดยเข้าใจว่ามันเป็น Agile Methodoloy แบบหนึ่ง (เหมือน Scrum หรือ Kanban) แต่มันไม่ใช่นะ มันเป็นการ Scale Agile Team แบบ LeSS หรือ SAFe เลย อยู่ๆหยิบมาทำเลยมันจะพังเอา ผมจึงอยากจะเอามาเล่าให้ฟัง เผื่อว่าจะมีประโยชน์กับใครหลายๆคนที่คิดจะเอากระบวนการนี้ไปใช้ ลองอ่านดูครับ
Geek Alert!!!
ในบทความนี้มีการอ้างอิง Scrum พอสมควร ผู้อ่านควรที่ความรู้พื้นฐานเกี่ยวกับ Scrum ครับ
Spotify Engineering Culture
ผมเคยอ่านเจอในพันทิพย์ที่มีน้องคนไทยคนนึงมีโอกาสไปฝึกงานเป็น iOS developer ที่ Spotify ตาม link นี้ครับ ตอนนั้นก็ไม่ได้สนใจมากนักเพราะไม่คุ้นหูกับ Agile ของ Spotify เลย (ตอนนั้นสนใจแค่ Scrum) จนกระทั่งได้มีส่วนร่วมกับการนำมาใช้ ตอนแรกผมก็สงสัยว่าเราใช้ process อะไรกันนะ มันคล้าย Scrum แต่ก็ไม่เหมือนซะทีเดียว จะว่าเป็น SAFe หรือ LeSS ก็ไม่ใช่ แต่เราเรียกทีมว่า Squad และกลุ่มของทีมว่า Tribe ก็เลยลองเอา 2 คำนี้ไป Google ดู ก็เจอว่าเป็นกระบวนการของ Spotify นี่เอง
!!! Disclaimer (by Spotify) !!!
ในเอกสารที่ผมใช้ reference บทความนี้ระบุไว้ว่า กระบวนการนี้เป็นแค่ Snapshot การทำงานใน Spotify เท่านั้น (ผมเจอแค่ล่าสุดปี 2012) มันเป็น in progress journey นะไม่ใช่ completed journey ถึงวันนี้มันน่าจะเปลี่ยนไปเยอะแล้ว
โครงสร้างทีมของ Spotify
เรามาลองทำความรู้จักโครงสร้างทีมของ Spotify Engineering Culture กันก่อนครับ
Tribe / Tribe Lead
การแบ่งทีมของ Spotify จะมีการแยกออกเป็น Tribe โดยที่ Tribe จะเป็นกลุ่มของทีมที่ทำงานที่ใกล้เคียงกัน เช่น ทำระบบหนึ่งด้วยกัน ซึ่งใน Tribe จะมี Tribe Lead เป็นหัวหน้าทีมที่คอยดูแลทิศทางของงานใน Tribe ทั้งหมด
Squads
Squad เป็นทีมย่อยๆ ที่อยู่ใน Tribe โดยที่ Squad หนึ่งจะอยู่ใน Tribe เดียว แต่สามารถ ทำงานร่วมกับ Squad อื่นใน Tribe อื่นได้ โดยที่แต่ละ Squad จะทำงานเสมือนเป็นบริษัท startup เล็กๆในองค์กรเพื่อให้มีความคล่องตัวสูงสุด มี mission เป็นของตัวเองที่ align กับ mission ขององค์กรด้วย
Note: ผมไม่รู้ว่าที่ Spotify นั้น Squad สามารถย้ายไปอยู่ Tribe อื่นได้ไหมนะ ผมเข้าใจเอาเองว่าไม่ได้ — แต่เอาจริงๆ ก็น่าจะได้นะ
Product Owner
แต่ละ Squad จะไม่มีหัวหน้าที่ชัดเจน แต่จะมี PO 1 คนที่คอยจัด priority ของ Product Backlog ให้กับ Squad Team Members คล้ายกับ PO ใน Scrum และคอยทำงานร่วมกับ Squad อื่นทั้งใน Tribe ตัวเองและ Tribe อื่น เพื่อให้แน่ใจว่า priority ใน Product Backlog นั้นไปในทิศทางเดียวกับ roadmap ของ Tribe และองค์กร
Squad Members
แต่ละ Squad จะมีสมาชิกแบบ cross-functional เหมือน Scrum เป็น self-organizing team แต่ไม่จำกัดว่าจะใช้วิธีทำงานแบบไหน ทีมจะใช้ Scrum ก็ได้ จะเป็น Kanban หรือผสมกันก็ได้หมด แล้วแต่ความเหมาะสม
Chapter / Chapter Lead
Chapter จะเป็น local group ใน Tribe เพื่อเป็น area of expert สำหรับกลุ่มของคนที่มี skill แบบเดียวกัน ซึ่งจะคล้ายทีมแบบ traditional เช่น เป็นทีม SA, DBA, Tester เป็นต้น โดยจะมี Chapter Lead เป็น line manager ที่คอยทำหน้าที่เป็นพี่เลี้ยงหรือโค้ชให้กับ Squad member รวมถึงกำหนดเรื่อง incentive ให้กับ Squad Member ด้วย
Guild
Guild จะเป็นเหมือน community สำหรับคนที่สนใจในเรื่องเดียวกัน (community of interest) เพื่อให้เกิดการเวที่สำหรับแลกเปลี่ยนความรู้และประสบการณ์ร่วมกัน โดยที่ Guild จะเป็น group ที่อยู่ข้าม Tribe เช่น Guild Machine Learning, Guild Blockchain เป็นต้น เพราะฉะนั้นใครจะอยู่ Guild ไหนและกี่ Guild ก็ได้
Agile Coach
เป็น role ที่ทำหน้าที่เป็นโค้ชให้กับ PO และ Squad Member เพื่อให้ทุกคนเข้าใจถึง value ของ Agile โดยเน้นไปที่ Core Values และ Agile Principles มากกว่า process
How It's Come?
พออ่านดูแล้วผมก็รู้สึกว่ามันมีกลิ่นอายของ Scrum นะ ก็เลยไปดู video ที่ Spotify แชร์ไว้บน website เค้าเล่าให้ฟังว่า เริ่มแรก Spotify ก็ใช้ Scrum นี่แหละ แต่พอเริ่มมีทีม Scrum มากขึ้น อุปสรรคเรื่องการประสานงานระหว่างทีม และ Activity ต่างๆ ของ Scrum ก็เริ่มไม่จำเป็นละ เค้าก็เลยคิดวิธีการนี้ขึ้นมา โดย…
- คงสมาชิกและ PO เอาไว้และเรียกใหม่ว่า Squad เพื่อไม่ให้ถูกจำกัดด้วยกฏของ Scrum
- เมื่อไม่ใช่ Scrum และทีมเป็นเหมือน mini-startup ที่ต้องดูแลกันเอง จึงไม่จำเป็นต้องมี ScrumMaster หรือ SquadMaster
- แล้ว ScrumMaster ที่มีอยู่แล้วทำยังไง ก็ดึง ScrumMaster ออกมาจากทีม และเปลี่ยนเป็น Agile Coach แทนเพื่อให้เป็น Agile Principles Coach มองภาพกว้างกว่าแค่ Scrum และโค้ชทั้ง Tribe แทน มากกว่าจะเป็น master of process
- แล้ว Manager หรือ Specialist ละ? ก็ให้เป็น Chapter Lead เพื่อเป็นกาวที่คงโครงสร้างขององค์กรไว้ เป็น line manager และให้คอยโค้ชด้าน Technical หรือ skill ที่ Chapter Lead เชี่ยวชาญด้วย
แล้ว Squad ทำงานกันยังไง?
เนื่องจาก Spotify ทำ Product เดียวเท่านั้น คือ Spotify แม้ว่า Spotify จะมีทั้งแบบ Windows/macOS App, Web, Mobile App (native iOS / Android) และระบบ Backend แต่เค้าก็มองว่าสิ่งเหล่านั้นเป็นแค่ component ไม่ใช่ Product นะ แต่ละ Squad จะทำงานกันประมาณนี้…
- คิด feature ที่คิดว่ามีประโยชน์กันเอง แล้วทำกันเอง end-to-end
- พอเสร็จแล้วก็เอา feature นั้นขึ้น production กันเองเลย (อาจจะมี Operation Squad ช่วยเหลือ)
- เปิดให้ user จริงในวงแคบๆ ได้ทดลองใช้ก่อน ถ้า user ใช้แล้วไม่พอใจ ไม่ชอบ หรือไม่มีใครใช้ feature นั้นก็จะตายไปเอง แต่ถ้า feature นั้น user ชอบ ก็จะค่อยๆ ขยายวงของ user ที่เห็น feature นั้นให้กว้างขึ้นและคอย measure ตลอดเวลา ถ้าสุดท้ายมันดีจริง ทุกคนก็จะได้ใช้มัน
- เป็นเจ้าของ feature นั้น แต่ใครจะเข้ามาแก้หรือ enhance ก็ได้ ตกลงกันเอง
ฟังแล้วก็เหมือนจะดูดี แต่ผมพบว่าการเปลี่ยนโครงสร้างมาเป็น Tribe/Squad มันไม่ง่ายขนาดนั้น ทำไมเหรอครับ ลองดูภาพ 2 ภาพนี้ครับ
2 ภาพนี้แสดงให้เห็นถึง Culture, Guideline รวมถึงวิธีการทำงานร่วมกันระหว่าง roles และทีมต่างๆ ใน Spotify ซึ่งเยอะมาก ผมมองว่าการที่ Spotify ทำได้ น่าจะเป็นเพราะว่าเค้ามี Agile Culture ที่แข็งแกร่งอยู่แล้ว (เพราะเดิมทำ Scrum กันอยู่) เมื่อเปลี่ยนโครงสร้างมาเป็นแบบ Tribe / Squad มันก็เลยไปได้ แต่กับองค์กรที่ไม่ได้มี Agile Culture มาก่อน แล้วจู่ๆ มาปรับโครงสร้างตาม Spotify มันไม่น่าจะดีนะ ผมลองหยิบมา 5 ข้อเพื่อเทียบดูว่า ถ้าเราหยิบมาทำเลย เราจะเจอความท้าทายแบบไหนบ้าง
- Squad — ในแต่ละ Squad ต้องมี PO และทีมที่เป็น cross-functional team การเปลี่ยนโครงสร้างแล้วเอาคนมาใส่ไม่ยากครับ แต่การมี PO ที่เป็น PO จริงๆ และทีมที่มีหลักการทำงานแบบ startup นี่ไม่น่าจะเกิดทันทีที่เปลี่ยนโครงสร้าง และยิ่งเป็นองค์กรที่ไม่เคยทำ Agile ด้วยแล้ว น่าจะเป็นเรื่องที่ท้าทายมากเลยทีเดียว
- Product — Spotify มอง product ของตัวเองชัดเจนตั้งแต่แรก มี Vision/Goal ชัดเจน แต่ผมพบว่าหลายๆ องค์กรยัง define Product ของตัวเองไม่ถูกเลย หรือบางองค์กรอาจจะชัดเจนว่า Product ของตัวเองคืออะไร แต่การสื่อสารให้ทุกคนในองค์กรเข้าใจว่า Product ขององค์กรส่งมอบคุณค่าอะไรให้ลูกค้าก็ยังไม่ชัดเจน
- Release Train — เรื่องนี้เกี่ยวข้องกับ Technical Excellence และการทำ Automation ถ้าองค์กรไหนยังมี deployment / release process แบบ manual ที่ต้องผ่านการอนุมัติโดย manager อยู่ เราอาจจะต้องแก้ตรงนี้ก่อนทำ Agile เลยด้วยซ้ำ
- Agile Coach — ScrumMaster เป็นตำแหน่งที่มีน้อย เหมือน rare monster ใน Pokemon เลย ยิ่ง Agile Coach ด้วยแล้วยิ่งหายากเข้าไปใหญ่ และถ้าไม่มี Agile Coach โอกาสที่ทุกคนจะกลับไปแก้ปัญหาด้วยวิธีเดิมๆมีสูงมาก
- Define (Definition) of Awesome (DoA) — องค์กรส่วนใหญ่เน้นไปที่ทำ feature ออกมาให้เสร็จ แต่ DoA ของ Spotify เน้นไปที่การวัดว่า feature ที่ release ออกไปนั้น ลูกค้าได้ “value” จริงๆ ไหม (มันเจ๋งยังไง แล้วมันเจ๋งจริงไหม) ผมพบว่าการเปลี่ยนมุมมองไปเห็นคุณค่าของ outcome มากกว่า output มีอุปสรรคเยอะมากเลย โดยเฉพาะการวัดผลแบบเดิมๆ ด้วย KPI หรือ OKR แบบผิดๆ
มันมีอีกหลายเรื่องเลย แต่แค่ 5 เรื่องนี้เราก็พอจะเห็นแล้วว่ามันไม่ง่ายที่จะทำ Agile Transformation โดยการ copy เอา structure และ process ของ Spotify มา paste ใส่เลย ก่อนที่จะตัดสินใจลงมือทำเราคงต้องศึกษาให้ดีก่อนว่าทำไม Spotify ทำแล้ว Success ไม่งั้นเราจะพบกับการทำ Agile Transformation ที่เจ็บปวดมากเลย
Conclusion
การเปลี่ยนแปลงเป็นเรื่องที่ดีครับ เริ่มแล้วเจอปัญหาก็ช่วยกันคิดช่วยกันแก้มันเป็นเรื่องที่ดีมากเลย แต่ก็ต้องมีการเตรียม mindset ที่ดีด้วย เพราะระหว่างทางเราจะเจอปัญหาที่คิดไม่ถึงแน่ๆ แต่ยังไงก็แล้วแต่ ผมคิดว่าการ transform กับการ Scale มันคนละเรื่องกัน เอามาทำพร้อมกันนี่ต้องคิดให้หนักเลย
การ Scale Agile Team ไม่ได้มีวิธีเดียวครับ มันมีอีกหลายวิธีเลย เช่น Large Scale Scrum (LeSS), Scale Agile Framework (SAFe), หรือการใช้เทคนิค Flight Level ของ Klaus Leopold (— กรณีที่ใช้ Kanban — แก้ไข: ไม่จำเป็นต้องเฉพาะ Kanban ตาม comment ของพี่ปอมครับ ขอบคุณครับ) ซึ่งแต่ละวิธีก็มีข้อดีข้อเสียของมัน ที่ Spotify ทำเพราะต้องการ Scale Scrum Team แสดงว่าที่ผ่านมาเค้าเป็น Agile Organization อยู่แล้ว เพราะฉะนั้น Spotify Engineering Culture ก็เป็นแนวทางที่ดี แต่ต้องศึกษาดีๆก่อนนะ
ผมจำไม่ได้ละว่าได้ยินมาจากไหน ถ้าไม่ใช่ รูฟ จั๊วะ เจน ก็น่าจะ Bas Vodde พูดในคลาส LeSS นี่แหละ (แต่จำได้ขึ้นใจเลย) เค้าบอกว่า…
ถ้าแค่ Scrum ทีมเดียว ยังทำได้ไม่ดี ก็ยังไม่ต้องคิดเรื่องการ Scale ทีม
ก็หวังว่าบทความนี้จะมีประโยชน์กับคนที่คิดจะใช้วิธีนี้ไม่มากก็น้อยครับ ^_^
References :-
- Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds (PDF) :- https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf
- แชร์ประสบการณ์ฝึกงานในบริษัท Mobile Application ระดับโลก :- https://pantip.com/topic/34009887
- Spotify engineering culture (part 1) :- https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
- Spotify engineering culture (part 2) :- https://labs.spotify.com/2014/09/20/spotify-engineering-culture-part-2/
- LeSS :- https://less.works
- SAFe :- https://www.scaledagileframework.com
- Flight Level :- https://www.leanability.com/en/blog-en/2017/04/flight-levels-the-organizational-improvement-levels/
