Spotify का Squad टीम मॉडल एक विफलता था

"Spotify खुद भी 'the Spotify model' का इस्तेमाल नहीं करता। आप भी इसे मत अपनाइए."

2012 में मशहूर हुआ Spotify का "Scaling Agile" श्वेतपत्र उनकी आकांक्षा भर था, इसे पूरी तरह कभी लागू नहीं किया गया.

श्वेतपत्र वास्तविकता से अलग था, लेकिन भर्ती में उपयोगी होने के कारण इसे वैसे ही रहने दिया गया, और लेखक ने कंपनी छोड़ने के बाद इसे ठीक करने के लिए यह लिखा.

यह लेख विस्तार से बताता है कि उस मॉडल में क्या गलत था, Spotify की गलतियों से क्या सीखा जा सकता है, और कौन-से वैकल्पिक मॉडल बेहतर हैं.

उस श्वेतपत्र के सह-लेखक और Spotify के Agile coaches पहले से ही बाहरी लोगों से कहते रहे थे कि इसका अनुसरण न करें.

"जब हमने वह श्वेतपत्र लिखा था, तब भी हम वैसा काम नहीं कर रहे थे। वह सिर्फ आंशिक महत्वाकांक्षा और अनुमान था। लोगों ने ऐसी चीज़ की नकल करने में बहुत मेहनत की जो वास्तव में अस्तित्व में ही नहीं थी."

यह ठीक से काम क्यों नहीं कर पाया?

1. मैट्रिक्स मैनेजमेंट ने गलत समस्या (Wrong Problem) हल की

फुल-स्टैक agile टीमें अच्छी तरह काम कर सकती हैं। लेकिन मैट्रिक्स ढांचे वाला प्रबंधन और ज़्यादा समस्याएँ पैदा करता है

→ Spotify की टीमें लंबे समय तक बनी रहने वाली संरचनाएँ थीं, इसलिए किसी दूसरे टीम में जाने पर मैनेजर बदलने की ज़रूरत न पड़ना बहुत सीमित लाभ था

→ engineering manager सिर्फ career development स्तर की ज़िम्मेदारी लेता था, वह interpersonal skills जैसी चीज़ें सीखने में मदद नहीं कर पाता था

→ किसी टीम के सभी engineers के लिए एक ही मैनेजर नहीं था। mini-CEO जैसी भूमिका निभाने वाले product manager के बराबर mini-CTO जैसी भूमिका निभाने वाला कोई नहीं था। यानी technical team को support देने की ज़िम्मेदारी लेने वाला या priorities पर negotiate करने वाला कोई नहीं था। अगर technical team के भीतर मतभेद होते, तो product manager को सभी engineers से बातचीत करनी पड़ती। अगर वहाँ बात न बने, तो कम-से-कम 3 backend/web/mobile engineering managers से negotiate करना पड़ता, या विभाग के engineering leader तक escalation करना पड़ता था.

[ Spotify की गलतियों से सीख ]

→ product-design-technology टीमों में आम तौर पर engineers की संख्या ज़्यादा होती है, इसलिए पूरे engineering समूह को संभालने वाला एक मैनेजर होना चाहिए, ताकि टीम के भीतर मतभेद होने पर escalation का रास्ता हो

→ product managers के पास technology पर चर्चा करने के लिए एक बराबरी का peer होना चाहिए, जैसे CEO और CTO का रिश्ता होता है.

2. टीम की autonomy पर निर्भरता

जब कंपनी छोटी होती है, तो हर टीम अलग-अलग दायरे का काम करती है और अक्सर lead लेने वाली टीम बदलती रहती है.

जब कंपनी बड़ी होती है, तो अलग-अलग टीमों की दोहराई जाने वाली क्षमताओं को efficiency के लिए मिलाकर नई टीमें बनाई जाती हैं.

जैसे-जैसे टीमों की संख्या बढ़ती है, lead बदलने की ज़रूरत कम होती है और टीमें उन समस्याओं पर लंबी अवधि की सोच विकसित कर पाती हैं जिन्हें उन्हें हल करना है.

→ Spotify ने टीमों के बीच collaboration के लिए कोई common process परिभाषित नहीं किया। हर team अपने-अपने तरीके से शामिल होती थी, इसलिए पूरे संगठन की productivity गिरती गई.

→ "Spotify model" उस समय व्यवस्थित किया गया था जब कंपनी बहुत छोटी थी। इसके बाद उसका updated रूप आना चाहिए था, लेकिन ऐसा नहीं हुआ। autonomy तक तो बात पहुँची, लेकिन inter-team collaboration वाला हिस्सा पूरा नहीं हुआ.

[ Spotify की गलतियों से सीख ]

→ autonomy के लिए alignment ज़रूरी है। कंपनी की priorities management द्वारा तय की जानी चाहिए। autonomy का मतलब यह नहीं कि टीमें जो चाहें वही करें.

→ टीमों के बीच collaboration process हर हाल में ज़रूरी है। autonomy का मतलब यह नहीं कि हर team को हर समस्या अकेले हल करने के लिए छोड़ दिया जाए.

→ सफलता का मूल्यांकन कैसे होगा, यह भी management को तय करना चाहिए, तभी टीमों के बीच collaboration priorities तय करते समय समन्वय हो सकता है.

→ autonomy जवाबदेही माँगती है। Product Management को product value के लिए जवाबदेह होना चाहिए। हर team पर जोड़ा जा रहा हिस्सा 'complete' करने की ज़िम्मेदारी होनी चाहिए। mature टीमों को अपने business value, risk, learning और अगले कदम के लिए सर्वोत्तम move दिखाकर अपनी स्वतंत्रता को सही ठहराना चाहिए.

"अगर मुझे Spotify में सिर्फ एक चीज़ ठीक करनी होती, तो मैं कहता कि autonomy पर इतना ज़ोर नहीं देना चाहिए था." - Spotify के पूर्व Agile Coach Joakim Sunden

3. collaboration को एक मान ली गई क्षमता समझ लिया गया

Spotify ने हर team को अपनी working method नियंत्रित करने की छूट दी, लेकिन बहुत-से लोगों के पास agile की बुनियादी समझ ही नहीं थी.

इस कारण हर team को output बेहतर बनाने के लिए process improvement दोहराते हुए सही संयोजन खोजने में मेहनत करनी पड़ी.

process की समस्याओं, समाधान के तरीकों, या performance evaluation के लिए कोई common language नहीं थी। वास्तव में यह agile भी नहीं था, बस "Not-Waterfall" था.

Spotify के पास 'Agile coaches' थे जो हर team को process improvement सिखाते और सुझाव देते थे। इरादा अच्छा था, लेकिन सभी टीमों की मदद करने के लिए coaches पर्याप्त नहीं थे.

हर coach के पास किसी team को इतना समय देने की गुंजाइश नहीं थी कि वह project पूरा करने और परिणामों का मूल्यांकन करने तक साथ दे सके। इसलिए वे किसी चीज़ के लिए जवाबदेह नहीं थे.

[ Spotify की गलतियों से सीख ]

→ collaboration एक skill है, जिसके लिए knowledge और practice दोनों चाहिए। managers को यह मानकर नहीं चलना चाहिए कि लोग पहले से agile practices समझते हैं.

→ जब कंपनी काफ़ी बड़ी हो जाए, तो हर team को अपने भीतर planning करने और टीमों के बीच collaboration संभव बनाने के लिए support organization चाहिए। Program Management को planning process की ज़िम्मेदारी लेनी चाहिए। dedicated Program Managers को यह सुनिश्चित करना चाहिए कि Product Manager और Engineering Manager अपनी-अपनी क्षमताओं में काम करते हुए भी team सहयोग के साथ चलें.

4. मिथक बदलना कठिन होता है

Agile Scrum ने burndown/sprint जैसे शब्द इसलिए दिए क्योंकि नए concepts को पेश करते समय नामों की ज़रूरत थी.

Spotify ने Missions, Tribe, Squads, Chapter Lead जैसे नए शब्द पेश किए, और इससे यह "भ्रम पैदा हुआ कि कुछ खास शब्द चुनने से ही कोई खास चीज़ बन जाती है".

इन अनावश्यक पर्यायों को हटा दें, तो Spotify model असल में बस "Cross-Functional Team" का एक समूह था, जिसमें autonomy बहुत ज़्यादा और management structure कमज़ोर था.

अगर Spotify ने इस मॉडल के विचारों को उनके मूल नामों से ही पुकारा होता, तो मॉडल के विफल होने पर लोग इसे सांस्कृतिक पहचान बदलने के रूप में नहीं, बल्कि बेहतर internal process खोजने की कोशिश के रूप में देखते.

[ Spotify की गलतियों से सीख ]

→ ज़्यादातर business सिर्फ कुछ सीमित innovation क्षेत्रों को ही टिकाऊ रूप से संभाल सकते हैं। internal process में innovation शायद ही कभी किसी company को बाज़ार में अलग पहचान दिलाती है। इतिहास का अध्ययन करके business innovation के बेहतर क्षेत्र चुन सकते हैं.

→ समझ को optimize कीजिए। संगठन की productivity बनाए रखने के लिए यह आकलन करना चाहिए कि लोगों को जो भी नई चीज़ें सीखनी हैं, उनकी वास्तविक value क्या है.

*** इसकी जगह यह कीजिए। (हालाँकि कोई शॉर्टकट नहीं है.)

अगर आप Spotify model तक इसलिए पहुँचे हैं क्योंकि आप अपनी team संरचना बनाना चाहते हैं, तो यहीं मत रुकिए, और खोजिए.

Spotify से भी लंबे समय तक परखे गए अन्य कंपनियों के मॉडल पर बहुत अधिक सामग्री उपलब्ध है.

2012 का Spotify बड़े संगठन में छोटी टीमों की गति और फुर्ती बनाए रखने का तरीका नहीं खोज पाया था.

उन्होंने इस शुरुआती मॉडल से आगे बढ़कर बेहतर जवाब खोजने के लिए बाहर देखा, और आपको भी ऐसा ही करना चाहिए.

काम करने के अन्य तरीकों पर लेखक की सिफारिशें

• क्या आपके product-development-design संगठन में 200 से अधिक लोग हैं? जब मैं Fitbit में था, तब "Scaled Agile Framework" हमारे लिए अच्छी तरह काम करता था.

• 200 से कम लोगों के लिए मैं "Shape Up By Basecamp" की सिफारिश करता हूँ। मेरा अगला startup इसी ढाँचे पर होगा.

• "Essential Scrum" और "Team Topologies" किताबें पढ़िए.

[sonim1]

अच्छे लेख के लिए धन्यवाद।

हमारी कंपनी ने भी लगभग 2 साल पहले Spotify के squad टीम मॉडल को अपनाया था, लेकिन लेख में बताए गए नुकसान की वजह से कई हिस्सों में मजबूरन सुधार करने पड़े।

इस साल की शुरुआत से हम Basecamp के Shape Up को फॉलो कर रहे हैं, और नतीजे में हम बेहतर product quality दे पा रहे हैं।

[godrm]

बिलकुल। सफलता के उदाहरणों जितने ही विफलता के उदाहरण भी महत्वपूर्ण होते हैं।

[xguru]

जब यह "Scaling Agile" श्वेतपत्र पहली बार सार्वजनिक हुआ था, तब मैंने इसे देखकर हैरान होकर साझा किया था और ब्लॉग में भी लिखा था.. यह सचमुच चौंकाने वाला लेख है T_T

लेखक की सिफारिशों में से एक "Basecamp ka Shape Up" को GeekNews पर पहले भी परिचित कराया गया था। छोटे संगठनों में मैं भी इसकी सिफारिश करता हूँ.

Shape Up - छोटे संगठन बेहतरीन तरीके से कैसे काम करें [PDF] https://hi.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