1.4 काम करने के तरीके

अवलोकन और प्रेरणा

“काम करने के तरीके” यह वर्णन करते हैं कि आपकी टीम वास्तव में दिन-प्रतिदिन कैसे समन्वय करती है, योजना बनाती है, संवाद करती है, और डिलीवर करती है। काम को कैसे तोड़ा जाता है? कौन किससे और कब बात करता है? प्रगति को कैसे ट्रैक किया जाता है, और निर्णय तथा ज्ञान कैसे प्रवाहित होते हैं?

अधिकांश संगठन एक नामित पद्धति अपनाते हैं, Scrum, Kanban, कोई स्केलिंग फ़्रेमवर्क, और मान लेते हैं कि समारोह (ceremonies) नीचे के मूल्य के बराबर हैं। वे नहीं हैं। जिन पद्धतियों ने सॉफ़्टवेयर डिलीवरी को बदल दिया, वे भारी-भरकम, हैंड-ऑफ़-चालित प्रक्रियाओं के विरुद्ध प्रतिक्रियाएँ थीं। उनका लक्ष्य तेज़ फ़ीडबैक, छोटे बैच, और सशक्त टीमें थीं। केवल अनुष्ठान अपनाना, स्टैंडअप, स्प्रिंट, स्टोरी पॉइंट, बिना सिद्धांतों के, आपको प्रक्रिया की लागतें देता है बिना लाभों के: cargo-cult एजाइल।

बड़ी टीमों के लिए, यही वह जगह है जहाँ अच्छे इरादे सफल या विफल होते हैं। एक हज़ार इंजीनियर सभी एक ही कमरे में नहीं हो सकते, एक ही मीटिंग में शामिल नहीं हो सकते, या एक ही अकथित संदर्भ साझा नहीं कर सकते। जितना बड़ा आप होते हैं, उतना ही अधिक आपको मीटिंग और गलियारे की बातचीत के बजाय लिखित संचार, असिंक्रोनस सहयोग, और हल्के समन्वय पर निर्भर रहना पड़ता है। स्केल भौतिकी बदल देता है। जो प्रथाएँ आठ सह-स्थित लोगों के लिए खूबसूरती से काम करती हैं, वे अस्सी वितरित लोगों के लिए ढह सकती हैं। और स्केलिंग फ़्रेमवर्क जो इसे ठीक करने का वादा करते हैं, अक्सर उन्हीं हैंड-ऑफ़ और केंद्रीकरण को फिर से लाते हैं जिन्हें agile हटाने के लिए बना था।

एंटरप्राइज़ और सरकार इन सभी दबावों को पूरी ताक़त से महसूस करते हैं। वे कई समय क्षेत्रों में फैले हैं, स्थायी स्टाफ़ को ठेकेदारों और विक्रेताओं के साथ मिलाते हैं, और अक्सर अनिवार्य स्टेज गेट और रिपोर्टिंग रखते हैं। यहाँ, एक दस्तावेज़-प्रथम, असिंक्रोनस, परिणाम-केंद्रित काम करने का तरीका एक सुविधा नहीं है। यह वह एकमात्र चीज़ है जो स्केल करती है। नीचे दी गई अनुशंसाएँ फ़्रेमवर्क को पूरी तरह आयात करने के बजाय सिद्धांतों को संदर्भ में अनुकूलित करने को प्राथमिकता देती हैं, और उन लिखित, असिंक्रोनस, पारदर्शी प्रथाओं को प्राथमिकता देती हैं जो बड़े, वितरित, मिश्रित कार्यबलों को वास्तव में सहयोग करने देती हैं।

मुख्य सिद्धांत

अनुष्ठान नहीं, सिद्धांत अपनाएँ; कॉपी करने से पहले समझें कि कोई प्रथा क्यों मौजूद है।
छोटे बैच और तेज़ फ़ीडबैक बड़ी योजनाओं और लंबे चक्रों से बेहतर हैं।
जहाँ फ़िट बैठे, कठोर टाइम-बॉक्सिंग की तुलना में फ़्लो (प्रगतिरत कार्य सीमित करना) को प्राथमिकता दें।
बातचीत और योजना सक्षम करने के लिए अनुमान लगाएँ, झूठी सटीकता बनाने के लिए नहीं।
असिंक्रोनस, लिखित संचार को डिफ़ॉल्ट बनाएँ; सिंक्रोनस समय उसी के लिए सुरक्षित रखें जिसे वास्तव में इसकी आवश्यकता है।
काम और निर्णयों को दृश्यमान और दस्तावेज़ीकृत बनाएँ ताकि कोई भी बिना मीटिंग के पकड़ बना सके।
प्रदर्शित की गई गतिविधि या उपयोग की गई क्षमता के बजाय, दिए गए परिणामों के लिए अनुकूलित करें।

अनुशंसाएँ

Agile, Scrum, Kanban, और Lean को संदर्भ के अनुसार अनुकूलित करें

इन्हें एक धर्म नहीं, एक टूलकिट के रूप में मानें। Scrum के समय-बद्ध स्प्रिंट उन टीमों के अनुकूल हैं जिनके पास डिस्कवरी काम है जो नियमित योजना और समीक्षा गति से लाभान्वित होता है। Kanban का निरंतर फ़्लो और स्पष्ट प्रगतिरत-कार्य सीमाएँ उन टीमों के अनुकूल हैं जिनके पास अप्रत्याशित, इंटरप्ट-चालित काम है जैसे प्लेटफ़ॉर्म और संचालन। Lean का बर्बादी ख़त्म करने और लीड टाइम छोटा करने पर ध्यान दोनों को आधार देता है। सोच-समझकर चुनें। जहाँ मदद करे वहाँ मिलाएँ; कई टीमें ”Scrumban” चलाती हैं। उन प्रथाओं को रखें जो मूल्य बनाती हैं, और उन समारोहों को छोड़ें जो खाली अनुष्ठान बन गए हैं। किसी भी प्रथा के लिए परीक्षण सरल है। क्या यह फ़ीडबैक छोटा करती है, बैच आकार घटाती है, या स्पष्टता बढ़ाती है? यदि नहीं, तो इस पर सवाल उठाएँ।

सावधानी से स्केल करें, कार्गो कल्ट से नहीं

स्केलिंग फ़्रेमवर्क, SAFe (Scaled Agile Framework), LeSS (Large-Scale Scrum), लोकप्रिय “स्पॉटिफ़ाई मॉडल”, कई टीमों का समन्वय करने का वादा करते हैं। इन्हें संशयवादी दृष्टि से देखें। SAFe संरचना लाता है और अक्सर बड़े एंटरप्राइज़ और सरकार द्वारा इसकी व्यापकता और प्रशिक्षण पारिस्थितिकी तंत्र के लिए चुना जाता है, लेकिन यह भारी योजना, पदानुक्रम, और हैंड-ऑफ़ को फिर से ला सकता है जो एजिलिटी को कमज़ोर करते हैं। LeSS लीन सिद्धांतों के अधिक निकट रहता है, लेकिन वास्तविक संगठनात्मक परिवर्तन की मांग करता है। स्पॉटिफ़ाई “मॉडल” एक कंपनी की विकसित होती संस्कृति की एक झलक थी, कभी एक टेम्पलेट नहीं, और स्वयं स्पॉटिफ़ाई ने इसे उस तरह नहीं चलाया जैसा लोग कल्पना करते हैं। पिछले अध्याय की टीम टोपोलॉजी के माध्यम से समन्वय की आवश्यकता घटाकर स्केल करने को प्राथमिकता दें, बजाय इसके कि एक खंडित संरचना पर एक समन्वय फ़्रेमवर्क बोल्ट किया जाए।

ईमानदारी से और हल्के ढंग से अनुमान लगाएँ

स्टोरी पॉइंट और वेलोसिटी आपकी टीम को अपने निकट-अवधि के काम की योजना बनाने और सापेक्ष जटिलता के बारे में बात करने में मदद करते हैं। वे एक उत्पादकता मीट्रिक, एक क्रॉस-टीम मुद्रा, या एक वादा नहीं हैं। वेलोसिटी को कभी लक्ष्य न बनाएँ: इसे पॉइंट मुद्रास्फीति के माध्यम से गेम किया जाएगा। लंबी-अवधि के पूर्वानुमान के लिए, थ्रूपुट गिनने और ऐतिहासिक साइकिल-टाइम डेटा उपयोग करने को प्राथमिकता दें, जो अक्सर अनुमानों को जोड़ने से अधिक सटीक होता है। कई परिपक्व टीमें काम को समान रूप से छोटे टुकड़ों में काटकर और बस उन्हें गिनकर अनुमान ओवरहेड को कम करती हैं। जो भी विधि हो, याद रखें कि अनुमान अनिश्चितता के तहत पूर्वानुमान हैं, प्रतिबद्धताएँ नहीं। उन्हें सीमाओं के रूप में संप्रेषित करें।

असिंक्रोनस, दस्तावेज़-प्रथम संचार को डिफ़ॉल्ट बनाएँ

बड़े, वितरित संगठनों में, सिंक्रोनस मीटिंग स्केल नहीं करतीं, और वे अन्य समय क्षेत्रों के लोगों को बाहर कर देती हैं। लेखन को डिफ़ॉल्ट बनाएँ: डिज़ाइन दस्तावेज़, decision records, लिखित स्थिति अपडेट, और पूर्ण टिकट जो बिना लाइव बातचीत के कार्य करने के लिए पर्याप्त संदर्भ रखते हैं। जिन मीटिंगों से बच नहीं सकते उन्हें रिकॉर्ड और संक्षेप करें। एक दस्तावेज़-प्रथम संस्कृति किसी अन्य समय क्षेत्र में किसी को पूरी तरह योगदान करने देती है, नए शामिल होने वालों और ठेकेदारों को पढ़कर ऑनबोर्ड होने देती है, और एक टिकाऊ रिकॉर्ड छोड़ती है। असली सहयोग, संबंध-निर्माण, और अस्पष्टता को जल्दी दूर करने के लिए सिंक्रोनस समय बचाएँ। ध्यान के बड़े ब्लॉक को मीटिंग विखंडन से बचाएँ।

समय क्षेत्रों, ठेकेदारों, और विक्रेताओं में अच्छी तरह काम करें

वितरित और मिश्रित कार्यबल स्केल पर सामान्य हैं। ”follow-the-sun” के लिए डिज़ाइन करें, जहाँ हैंडऑफ़ लिखित और पूर्ण हों, मौखिक नहीं। जितने ज़रूरी सिंक्रोनस संपर्क के लिए कुछ ओवरलैपिंग कोर घंटे सेट करें, और असुविधाजनक मीटिंग समय का दर्द निष्पक्ष रूप से साझा करें बजाय इसके कि हमेशा उसी क्षेत्र पर बोझ डाला जाए। ठेकेदारों और विक्रेताओं के लिए, लिखित संदर्भ, स्पष्ट इंटरफ़ेस, और साझा टूलिंग में अतिरिक्त निवेश करें, क्योंकि उनके पास वह अकथित ज्ञान नहीं है जो आपका स्थायी स्टाफ़ जमा करता है। विक्रेताओं को एक अलग, अपारदर्शी चैनल के माध्यम से प्रबंधित करने के बजाय उन्हीं दृश्यमान बोर्डों और दस्तावेज़ीकरण में लाएँ। जहाँ आप कर सकते हैं, अनुबंधों को घंटों के बजाय परिणामों के इर्द-गिर्द संरचित करें।

ट्रेड-ऑफ़: पक्ष और विपक्ष

दृष्टिकोण	पक्ष	विपक्ष
Agile (हितधारक बातचीत)	उच्च सहयोग और सबसे तेज़ मूल्य	विश्वास और लचीलेपन की आवश्यकता
Scrum (समय-बद्ध स्प्रिंट)	नियमित गति, अनुमानित लय, अंतर्निहित प्रतिबिंब	समारोह ओवरहेड; इंटरप्ट-चालित काम के लिए खराब फ़िट
Kanban (निरंतर फ़्लो, WIP सीमाएँ)	लचीला, अड़चनें उजागर करता है, ऑप्स के लिए अच्छा	कम लय; WIP सीमित करने के लिए अनुशासन चाहिए
SAFe / भारी स्केलिंग फ़्रेमवर्क	संरचना, प्रशिक्षण, बड़े संगठनों और सरकार से परिचित	पदानुक्रम और हैंड-ऑफ़ फिर से लाता है; एजिलिटी को दबा सकता है
LeSS / हल्की स्केलिंग	लीन सिद्धांतों के निकट रहता है	गहरे संगठनात्मक परिवर्तन की मांग करता है
असिंक्रोनस / दस्तावेज़-प्रथम	समय क्षेत्रों में स्केल करता है; टिकाऊ; समावेशी	अस्पष्ट विषयों के लिए धीमा; लेखन अनुशासन की आवश्यकता

व्यापक ट्रेड-ऑफ़ है समन्वय बनाम स्वायत्तता, और संरचना बनाम अनुकूलनशीलता। अधिक फ़्रेमवर्क और अधिक सिंक्रोनस समन्वय गति, ओवरहेड, और टीम सशक्तिकरण की कीमत पर अनुमानशीलता और संरेखण खरीदते हैं। कम फ़्रेमवर्क कई टीमों में संभावित गलत-संरेखण की कीमत पर गति और स्वामित्व खरीदता है। अधिकांश बड़े संगठनों के लिए, सबसे अच्छा उत्तर एक न्यूनतम साझा गति और मज़बूत लिखित प्रथाएँ हैं। यह समन्वय बोझ को उसके स्रोत पर घटाता है बजाय इसके कि इसे भारी प्रक्रिया से प्रबंधित किया जाए।

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

यदि नेतृत्व वह अनुमानशीलता चाहता है जिसका एक स्केलिंग फ़्रेमवर्क वादा करता है, तो आप उसे एजिलिटी हटाने के लिए बने हैंड-ऑफ़ को फिर से लाए बिना कैसे देंगे? बड़े एंटरप्राइज़ और सरकारी कार्यक्रम अक्सर SAFe-शैली की बिग-रूम योजना और स्टेज-गेट रिपोर्टिंग अनिवार्य करते हैं क्योंकि निगरानी निकाय पूर्वानुमान और समन्वय की मांग करते हैं जो वे देख सकें। प्रतिस्पर्धी विचार वास्तविक हैं: नेतृत्व को कई टीमों में अनुमानशीलता और संरेखण चाहिए, और भारी फ़्रेमवर्क इसे गति, ओवरहेड, और उन्हीं हैंड-ऑफ़ की कीमत पर खरीदते हैं जो डिलीवरी को धीमा करते हैं। चर्चा में प्रमाण लाएँ, जैसे कार्य सप्ताह का कितना हिस्सा योजना इवेंट और क्रॉस-टीम निर्भरता समन्वय में गायब हो जाता है, और क्या वे इवेंट निर्भरताओं को हटाते हैं या केवल उन्हें उजागर करते हैं। मज़बूत कदम है टीम टोपोलॉजी के माध्यम से समन्वय की आवश्यकता घटाकर स्केल करना, फिर योजना मैराथन के बजाय लाइव बोर्ड और लिखित इंटरफ़ेस से रिपोर्टिंग संतुष्ट करना। तय करें कि कौन सा समन्वय वास्तविक है और कौन सा समारोह है, और नेतृत्व को फ़्रेमवर्क के ओवरहेड के बजाय थ्रूपुट और साइकिल-टाइम डेटा से उन्हें चाहिए वह पूर्वानुमान दें।
वेलोसिटी को क्रॉस-टीम उत्पादकता मीट्रिक बनने से रोकने के लिए आप वास्तव में क्या करेंगे? स्टोरी पॉइंट एक अकेली टीम को अपने निकट-अवधि के काम की योजना बनाने में मदद करते हैं, और जिस क्षण उनकी तुलना टीमों में की जाती है या उन्हें लक्ष्य के रूप में सेट किया जाता है, वे बेकार हो जाते हैं, क्योंकि पॉइंट मुद्रास्फीति तर्कसंगत प्रतिक्रिया है। एक बड़े संगठन में, वेलोसिटी को एक डैशबोर्ड में रोल करने की खिंचाव जिसकी कार्यकारी तुलना करें, मज़बूत चलती है, और यह चुपचाप उन अनुमानों को भ्रष्ट करती है जिन पर टीमें निर्भर हैं। बहाव के प्रमाण लाएँ: क्या पॉइंट समय के साथ बढ़ रहे हैं, क्या टीमें अनुमान बढ़ा-चढ़ाकर बता रही हैं, क्या किसी को वेलोसिटी से रैंक किया जा रहा है? टीम से बाहर जाने वाले किसी भी पूर्वानुमान के लिए थ्रूपुट गिनने और ऐतिहासिक साइकिल-टाइम डेटा उपयोग करने को प्राथमिकता दें, और वादों के बजाय अनुमानों को अनिश्चितता के तहत सीमाओं के रूप में संप्रेषित करें। उत्तर को एक स्पष्ट समझौता उत्पन्न करना चाहिए कि वेलोसिटी कभी टीम से बाहर नहीं जाती, और क्रॉस-टीम पूर्वानुमान इसके बजाय फ़्लो मीट्रिक्स का उपयोग करता है।
“लिखा हुआ” के लिए आपकी ठोस बार क्या है, और किन निर्णयों को वास्तव में अभी भी सिंक्रोनस बातचीत की आवश्यकता है? एक दस्तावेज़-प्रथम डिफ़ॉल्ट वह चीज़ है जो समय क्षेत्रों, ठेकेदारों, और विक्रेताओं में स्केल करती है, और इसकी लागत वास्तविक लेखन अनुशासन है जो हर किसी के पास अभी नहीं है। बार के बारे में विशिष्ट बनें: क्या एक टिकट बिना लाइव कॉल के कार्य करने के लिए पर्याप्त संदर्भ रखता है, क्या निर्णय एक टिकाऊ रिकॉर्ड में उतरते हैं, क्या जिन मीटिंगों से आप बच नहीं सकते उन्हें रिकॉर्ड और संक्षेप किया जाता है? उन एंटरप्राइज़ और सरकारी कार्यक्रमों के लिए जो स्थायी स्टाफ़ को उन ठेकेदारों के साथ मिलाते हैं जिनके पास अकथित ज्ञान नहीं है, लिखित संदर्भ वह चीज़ है जो एक मिश्रित, वितरित कार्यबल को पूरी तरह योगदान करने देती है। ट्रेड-ऑफ़ यह है कि अस्पष्ट या विवादास्पद विषय अक्सर सिंक्रोनस रूप से हल करना तेज़ होता है, इसलिए उन्हें स्पष्ट रूप से नाम दें और दुर्लभ सिंक्रोनस समय उनके लिए सुरक्षित रखें। तय करें कि लेखन आदत बनाने की लागत और असुविधाजनक मीटिंग समय किसे उठानी है, और उस लागत को निष्पक्ष रूप से साझा करें बजाय इसके कि हमेशा उसी क्षेत्र पर बोझ डाला जाए।
हमारे वर्तमान समारोहों में से कौन से बचेंगे यदि हम हर एक को विशुद्ध रूप से इस बात पर आँकें कि क्या यह फ़ीडबैक छोटा करता है, बैच आकार घटाता है, या स्पष्टता बढ़ाता है? समारोह चुपचाप जमा होते जाते हैं: यहाँ एक स्टैंडअप, वहाँ एक रिफ़ाइनमेंट सेशन, एक समीक्षा और एक रेट्रो और एक योजना इवेंट, जब तक एक बड़ी टीम अपने सप्ताह का अधिक हिस्सा आवर्ती मीटिंगों में बिताने नहीं लगती, उस काम में नहीं जिसकी सेवा करने के लिए वे मीटिंग हैं। प्रतिस्पर्धी विचार वास्तविक हैं, क्योंकि एक अनुष्ठान जो एक व्यक्ति को शुद्ध ओवरहेड लगता है, वही एकमात्र जगह हो सकती है जहाँ एक वितरित टीम साझा संदर्भ बनाती है या एक अवरोध उजागर करती है। चर्चा में प्रमाण लाएँ: प्रति व्यक्ति प्रति सप्ताह कुल आवर्ती मीटिंग घंटे, हर समारोह में उपस्थिति और सहभागिता, और हर एक वास्तव में कौन सा निर्णय या संकेत उत्पन्न करता है जो एक लिखित अपडेट से नहीं आ सकता था। एक एंटरप्राइज़ या सरकारी कार्यक्रम के लिए जहाँ हर टीम वही थोपी गई गति चलाती है, चक्रवृद्धि लागत बहुत बड़ी है, इसलिए एक स्पष्ट परीक्षण पर सहमत हों जिसे हर समारोह को अपना स्लॉट रखने के लिए पास करना चाहिए, और उन्हें काटने या मिलाने के लिए तैयार रहें जो केवल आदत से बने रहते हैं।
जब काम रुक जाता है, तो क्या हम जानते हैं कि यह वास्तव में कहाँ प्रतीक्षा कर रहा है, और क्या हम फ़्लो प्रबंधित कर रहे हैं या केवल स्टाफ़िंग? अधिकांश ज्ञान कार्य में एक कार्य अपने जीवन का कहीं अधिक हिस्सा कतारों, हैंड-ऑफ़, और समीक्षा में प्रतीक्षा करने में बिताता है बजाय सक्रिय रूप से काम किए जाने के, फिर भी टीमें सहज रूप से धीमी डिलीवरी का जवाब लोगों को जोड़कर या उच्च उपयोग के लिए दबाव डालकर देती हैं, जो कतारों को छोटा करने के बजाय लंबा करता है। तनाव यह है कि प्रगतिरत कार्य सीमित करना क्षमता को निष्क्रिय छोड़ने जैसा महसूस होता है, और निष्क्रिय दिखने वाले लोग प्रबंधकों और निगरानी निकायों को असहज करते हैं। सच्चाई उजागर करने वाले प्रमाण लाएँ: साइकिल-टाइम वितरण, कुल लीड टाइम में सक्रिय समय का अनुपात, आपके बोर्ड पर आइटम कहाँ अवरुद्ध बैठे हैं, और जब आप उन्हें लागू करते हैं तो प्रगतिरत-कार्य सीमाएँ (एक समय में कितने आइटम गति में हैं इस पर एक कैप) थ्रूपुट को कैसे बदलती हैं। स्टाफ़ उपयोग पर मापे जाने वाले एक बड़े या सरकारी संगठन के लिए, यह लक्ष्य को सबको व्यस्त रखने से पूर्ण काम को प्रवाहित रखने में फिर से परिभाषित करता है, और वह बदलाव अक्सर डिलीवरी गति पर सबसे बड़ा एकल उत्तोलक है।
हमारा काम करने का तरीका उन लोगों को कैसे समाहित करेगा जो हमारे कोर समय क्षेत्र में बैठे स्थायी स्टाफ़ नहीं हैं, ठेकेदार, विक्रेता, और मुख्यालय से कई घंटे ऑफ़सेट क्षेत्र? स्केल पर एक मिश्रित, वितरित कार्यबल सामान्य है, और एक सह-स्थित कोर टीम के लिए ट्यून की गई प्रथाएँ चुपचाप बाकी सबको बाहर कर देती हैं: एक निजी चैनल के माध्यम से प्रबंधित विक्रेता, अकथित संदर्भ के बिना ठेकेदार, वह क्षेत्र जिसका कार्यदिवस कभी निर्णय मीटिंग से ओवरलैप नहीं करता। विचार एक-दूसरे के विरुद्ध खिंचते हैं, क्योंकि तंग लिखित इंटरफ़ेस और पूर्ण लिखित हैंड-ऑफ़ वास्तविक अनुशासन की कीमत रखते हैं और उस तेज़ अनौपचारिक समन्वय को धीमा करते हैं जिसका एक सह-स्थित समूह आनंद लेता है। ऐसे प्रमाण लाएँ जैसे उन मीटिंगों से नियमित रूप से कौन अनुपस्थित है जहाँ निर्णय लिए जाते हैं, ऑफ़सेट क्षेत्र कितनी बार हैंड-ऑफ़ की प्रतीक्षा में अवरुद्ध हैं, और क्या विक्रेता स्टाफ़ के समान दृश्यमान बोर्डों पर काम करते हैं या एक अलग अपारदर्शी ट्रैक में। उन एंटरप्राइज़ और सरकारी कार्यक्रमों के लिए जो कई समय क्षेत्रों में अनिवार्य रिपोर्टिंग के तहत स्थायी स्टाफ़, ठेकेदारों, और विक्रेताओं को मिलाते हैं, लिखित, पारदर्शी, follow-the-sun प्रथा को उस आधाररेखा के रूप में मानें जो पूरे कार्यबल को योगदान करने देती है, और असुविधाजनक घंटों का बोझ साझा करें बजाय इसके कि इसे हमेशा उसी क्षेत्र पर थोपा जाए।

क्षेत्र लेंस

स्टार्टअप। कुछ ही लोगों और थोड़े रनवे के साथ, समारोह कैटलॉग छोड़ें और सबसे हल्के संभव फ़्लो पर चलें: एक साझा बोर्ड, एक छोटा लिखित दैनिक अपडेट, और एक दस्तावेज़ में कैद निर्णय ताकि कोई भी किसी साथी के जागने की प्रतीक्षा में अवरुद्ध न हो। पहले दिन से लेखन को डिफ़ॉल्ट बनाएँ, क्योंकि असिंक्रोनस आदत पाँच लोगों पर बनाना पचास पर रेट्रोफ़िट करने से कहीं सस्ता है। ऐसा स्केलिंग फ़्रेमवर्क न अपनाएँ जिसकी आपको वर्षों तक आवश्यकता नहीं होगी; आपका लाभ यह है कि आपको समन्वय करने के लिए लगभग कुछ भी नहीं है, इसलिए उसे सुरक्षित रखें।

छोटा व्यवसाय। स्टाफ़ पर बिना किसी एजाइल कोच या डिलीवरी मैनेजर और तंग बजट के, खरीदे गए फ़्रेमवर्क की तुलना में तैयार प्रथा को प्राथमिकता दें जो प्रशिक्षण और प्रमाणन लागतें रखते हैं जिन्हें आप न्यायोचित नहीं ठहरा सकते। एक ऐसी पद्धति चुनें जो आपके काम में फ़िट बैठे, इंटरप्ट-चालित सेवा काम के लिए Kanban या प्रोजेक्ट काम के लिए एक हल्की Scrum गति, और उस खिंचाव का विरोध करें जब एक साधारण बोर्ड और स्पष्ट टिकट काम कर सकते हों तो एक भारी टूल खरीदने के। अपना दुर्लभ समन्वय प्रयास चीज़ों को लिखने पर खर्च करें ताकि एक छोटी टीम एक व्यक्ति की स्मृति की बंधक न बने।

एंटरप्राइज़। कई टीमों में समस्या समन्वय लागत और संगति है: एक न्यूनतम साझा गति, “लिखा हुआ” का एक सामान्य परिभाषा, और फ़्लो मीट्रिक्स जो वेलोसिटी को क्रॉस-टीम लक्ष्य बनाए बिना ऊपर रोल होते हैं। एक फ़्रेमवर्क बोल्ट करने के बजाय टीम टोपोलॉजी के माध्यम से समन्वय की आवश्यकता घटाकर स्केल करें जो हैंड-ऑफ़ फिर से लाता है, और काम करने के तरीके को उस चीज़ के रूप में गवर्न करें जिसे आप प्रमाण से ट्यून करते हैं, एक बार का रोलआउट नहीं। इंटरफ़ेस और रिपोर्टिंग को मानकीकृत करें ताकि निगरानी योजना मैराथन के बजाय लाइव बोर्डों से संतुष्ट हो।

सरकार। प्रोक्योरमेंट नियम, अनिवार्य स्टेज गेट, और सार्वजनिक जवाबदेही हर विकल्प को आकार देते हैं, और स्थायी स्टाफ़, ठेकेदारों, और विक्रेताओं के मिश्रित कार्यबल आवश्यक प्रगति रिपोर्टिंग के तहत कई समय क्षेत्रों में फैले होते हैं। एक दस्तावेज़-प्रथम, पारदर्शी काम करने के तरीके को प्राथमिकता दें जहाँ काम का हर टुकड़ा स्टाफ़ और विक्रेताओं दोनों को दिखने वाले बोर्ड पर पूर्ण लिखित संदर्भ रखता है, ताकि स्थिति रिपोर्ट अलग मीटिंगों के बजाय सीधे रिकॉर्ड से आएँ। विक्रेता अनुबंधों को अपारदर्शी घंटे-आधारित बिलिंग के बजाय परिणामों और साझा दृश्यता के इर्द-गिर्द संरचित करें, और लिखित, ऑडिट योग्य ट्रेल को एक ओवरहेड के बजाय एक अनुपालन संपत्ति के रूप में मानें।

उदाहरण

स्टार्टअप। एक वितरित आठ-व्यक्ति स्टार्टअप पूरे Scrum समारोह कैटलॉग को छोड़ देता है और एक साझा Kanban बोर्ड और Slack में एक छोटे लिखित दैनिक अपडेट पर चलता है। क्योंकि दोनों संस्थापक अलग-अलग समय क्षेत्रों में बैठते हैं, वे पहले दिन से लेखन को डिफ़ॉल्ट बनाते हैं: हर निर्णय एक दस्तावेज़ में उतरता है, ताकि कोई भी दूसरे के जागने की प्रतीक्षा में अवरुद्ध न हो। जब वे बाद में तीसरे समय क्षेत्र में नियुक्ति करते हैं, तो ऑनबोर्डिंग ज़्यादातर बस पढ़ना है, और असिंक्रोनस आदत बिना किसी बदलाव के स्केल करती है। जो प्रथा उन्होंने कभी नहीं अपनाई, सिंक्रोनस स्थिति मीटिंग, वही एकमात्र है जो वे कभी नहीं चूकते।

एंटरप्राइज़। एक बहुराष्ट्रीय बैंक ने सैकड़ों टीमों में एक स्केलिंग फ़्रेमवर्क रोल आउट किया, त्रैमासिक बिग-रूम योजना के साथ पूर्ण। कागज़ पर संरेखण सुधरा, लेकिन डिलीवरी धीमी हो गई। टीमों ने योजना इवेंट और क्रॉस-टीम निर्भरता समन्वय में दिन बिताए जिन्हें फ़्रेमवर्क ने उजागर किया लेकिन हटाया नहीं। बैंक ने रास्ता सुधारा। इसने केवल वही हल्का क्रॉस-टीम संरेखण रखा जिसकी उसे वास्तव में आवश्यकता थी, टीमों को उनके वैल्यू स्ट्रीम को एंड टू एंड स्वामित्व देने के लिए पुनर्गठित किया, और अधिकांश समन्वय को लिखित इंटरफ़ेस और असिंक्रोनस अपडेट में स्थानांतरित किया। डिलीवरी लीड टाइम गिरा, और थकाने वाले योजना मैराथन सिकुड़कर केंद्रित, कभी-कभार सिंक बन गए।

सरकार। नागरिक सेवाएँ देने वाली एक सरकारी एजेंसी एक क्षेत्र में स्थायी स्टाफ़ और दो अन्य क्षेत्रों में ठेकेदार टीमों के साथ काम करती थी, कई समय क्षेत्रों में फैली, अनिवार्य प्रगति रिपोर्टिंग के तहत। इसने एक दस्तावेज़-प्रथम, Kanban-आधारित काम करने का तरीका अपनाया। काम का हर टुकड़ा स्टाफ़ और विक्रेताओं दोनों को दिखने वाले एक साझा बोर्ड पर पूर्ण लिखित संदर्भ रखता था। क्षेत्रों के बीच हैंडऑफ़ लिखित और पूर्ण थे। आवश्यक स्थिति रिपोर्ट अलग मीटिंगों के बजाय सीधे बोर्ड से आती थीं। इसने एक वितरित, मिश्रित कार्यबल को लगातार सहयोग करने दिया, एक उपोत्पाद के रूप में निगरानी रिपोर्टिंग संतुष्ट की, और शेड्यूल करना कठिन क्रॉस-टाइमज़ोन मीटिंगों पर एजेंसी की निर्भरता कम की।

व्यावसायिक मामला: प्रेरणाएँ, ROI, और TCO

आर्थिक तर्क फ़्लो दक्षता पर टिका है। अधिकांश ज्ञान कार्य में, काम की एक इकाई सक्रिय रूप से काम किए जाने में जो समय बिताती है, वह उसके कुल लीड टाइम का एक छोटा अंश है। बाकी प्रतीक्षा है: कतारों में, मीटिंगों में, हैंड-ऑफ़ में, समय-क्षेत्र अंतराल में। काम करने के तरीके जो बैच आकार को सिकोड़ते हैं, प्रगतिरत कार्य को सीमित करते हैं, और सिंक्रोनस अड़चनों को लिखित असिंक्रोनस फ़्लो से बदलते हैं, उस प्रतीक्षा पर सीधा हमला करते हैं। परिणाम है लोगों को जोड़े बिना छोटे लीड टाइम और उच्च थ्रूपुट, साथ ही कम दोष, क्योंकि फ़ीडबैक जल्दी आता है जब संदर्भ ताज़ा होता है।

अपनाने की लागत को यथास्थिति की लागत के विरुद्ध तौलें। दस्तावेज़-प्रथम, असिंक्रोनस, और लीन फ़्लो की लागत मुख्य रूप से आदतों में बदलाव और लेखन तथा टूलिंग में कुछ प्रारंभिक निवेश है। उन्हें किसी महंगे लाइसेंस की आवश्यकता नहीं। इसके विपरीत, भारी स्केलिंग फ़्रेमवर्क वास्तविक लागत रखते हैं: प्रशिक्षण, प्रमाणन, समर्पित भूमिकाएँ, और बड़े योजना इवेंट का चल रहा ओवरहेड। केवल वास्तविक समन्वय आवश्यकताएँ ही उसे न्यायोचित ठहराती हैं। कुछ न करने की लागत मीटिंग-संतृप्त कैलेंडर, बाहर किए गए दूरस्थ योगदानकर्ताओं, कार्गो-कल्ट समारोहों के रूप में दिखाई देती है जो परिणाम सुधारे बिना समय खपाते हैं, और धीमी डिलीवरी के रूप में। नेतृत्व के सामने मामला बनाने के लिए, डिलीवरी लीड टाइम, डिप्लॉयमेंट फ़्रीक्वेंसी, और कम-मूल्य वाली मीटिंगों में खोया कार्य सप्ताह का अंश मापें। एक बड़े कार्यबल में फ़्लो में छोटे सुधार बड़े क्षमता लाभ में जुड़ जाते हैं।

एंटी-पैटर्न और नुकसान

कार्गो-कल्ट एजाइल: अंतर्निहित सिद्धांतों के बिना समारोह प्रदर्शित करना।
लक्ष्य के रूप में वेलोसिटी: पॉइंट मुद्रास्फीति को आमंत्रित करती है और मीट्रिक की उपयोगिता नष्ट करती है।
फ़्रेमवर्क पूजा: फ़िट की परवाह किए बिना SAFe या एक “स्पॉटिफ़ाई मॉडल” टेम्पलेट थोपना।
प्रतिबद्धताओं के रूप में अनुमान: अनिश्चितता के तहत पूर्वानुमानों को बाध्यकारी वादों के रूप में मानना।
मीटिंग-चालित संस्कृति: सिंक्रोनस कॉल को डिफ़ॉल्ट बनाना जो अन्य समय क्षेत्रों को बाहर करते हैं।
अदस्तावेज़ीकृत निर्णय: लोगों के दिमाग़ों और पिछली बातचीत में फँसा ज्ञान।
विक्रेता ब्लैक बॉक्स: ठेकेदारों को साझा दृश्यता के बजाय अपारदर्शी साइड चैनलों के माध्यम से प्रबंधित करना।
उपयोग जुनून: पूर्ण काम के फ़्लो के बजाय सबकी व्यस्तता अधिकतम करना।

परिपक्वता मॉडल

स्तर 1, आरंभ। प्रक्रिया तदर्थ या कार्गो-कल्ट है; टीमें उनके पीछे के सिद्धांतों के बिना उधार लिए गए समारोह प्रदर्शित करती हैं, या बिना किसी साझा विधि के सुधार करती हैं। संचार मीटिंग-चालित और अदस्तावेज़ीकृत है, निर्णय लोगों के दिमाग़ों में रहते हैं, और अनुमानों को वादों के रूप में माना जाता है। वितरित योगदानकर्ताओं, ठेकेदारों, और ऑफ़सेट समय क्षेत्रों को मौखिक रूप से समन्वित किया जाता है और जब भी सही व्यक्ति सो रहा हो अवरुद्ध छोड़ दिया जाता है।
स्तर 2, विकसित। व्यक्तिगत टीमें Scrum या Kanban जैसी नामित पद्धति अपनाती हैं और इसे कुछ संगति के साथ पालन करती हैं, लेकिन प्रथा टीम से टीम भिन्न होती है और समारोह अक्सर रट-बद्ध होते हैं। कुछ टीमें डिज़ाइन दस्तावेज़ और निर्णय रिकॉर्ड लिखती हैं जबकि अन्य अभी भी मीटिंगों पर निर्भर हैं। अनुमान और समन्वय होते हैं, लेकिन “लिखा हुआ” का अर्थ क्या है इसके लिए किसी साझा बार के बिना, इसलिए संदर्भ अभी भी लीक होता है और क्रॉस-टीम हैंड-ऑफ़ भारी बने रहते हैं।
स्तर 3, मानकीकृत। प्रथाओं को काम में फ़िट बैठने के लिए सोच-समझकर चुना जाता है और एक संगठन-व्यापी अपेक्षा के रूप में दस्तावेज़ीकृत किया जाता है: एक न्यूनतम साझा गति, टिकटों और निर्णय रिकॉर्ड में लिखित संदर्भ के लिए एक परिभाषित बार, डिफ़ॉल्ट के रूप में असिंक्रोनस दस्तावेज़-प्रथम संचार, और नियंत्रण के बजाय बातचीत के लिए उपयोग किया जाने वाला अनुमान। मानक लगातार लागू किया जाता है, इसलिए किसी भी टीम में एक ठेकेदार या नया शामिल होने वाला व्यक्ति पढ़कर ऑनबोर्ड कर सकता है, और विक्रेता स्टाफ़ के समान दृश्यमान बोर्डों पर काम करते हैं।
स्तर 4, प्रबंधित। काम करने के तरीके को माना नहीं बल्कि आधाररेखाओं के विरुद्ध मापा जाता है। टीमें डिलीवरी लीड टाइम, साइकिल-टाइम वितरण, डिप्लॉयमेंट फ़्रीक्वेंसी, थ्रूपुट, और कम-मूल्य वाली मीटिंगों में खोया कार्य सप्ताह का अंश ट्रैक करती हैं, और पॉइंट मुद्रास्फीति के माध्यम से वेलोसिटी को गेम किए जाने पर नज़र रखती हैं। प्रगतिरत-कार्य सीमाएँ प्रमाण पर लागू की जाती हैं, उपयोग के बजाय फ़्लो प्रबंधित किया जाता है, और राय नहीं बल्कि डेटा तय करता है कि कौन से समारोह अपना स्लॉट रखते हैं और कहाँ कतारें लंबी हो रही हैं। नेतृत्व और निगरानी निकायों को रिपोर्टिंग सीधे इन लाइव मीट्रिक्स से आती है।
स्तर 5, ऑर्केस्ट्रेट। संगठन फ़्लो मीट्रिक्स और रेट्रोस्पेक्टिव प्रमाण से अपने काम करने के तरीके को लगातार ट्यून करता है, और समन्वय आवश्यकता को भारी प्रक्रिया से प्रबंधित करने के बजाय टीम टोपोलॉजी के माध्यम से स्रोत पर न्यूनतम किया जाता है। काम करने के तरीके, डिलीवरी मीट्रिक्स, और संगठनात्मक डिज़ाइन एकीकृत हैं और कार्यबल, बाज़ार, और नियामक तस्वीर बदलने पर अनुकूलित होते हैं; कई समय क्षेत्रों में स्टाफ़, ठेकेदारों, और विक्रेताओं की वितरित, मिश्रित टीमें सुचारू रूप से सहयोग करती हैं, और जो प्रथाएँ अपनी लागत कमाना बंद कर देती हैं उन्हें बिना समारोह के सेवानिवृत्त कर दिया जाता है।

चर्चा के लिए विचार

यदि हम अपने समारोहों को विशुद्ध रूप से उनके बनाए मूल्य से आँकें तो हम कौन से रखेंगे?
क्या हम एक फ़्रेमवर्क जोड़कर या समन्वय की आवश्यकता घटाकर स्केल कर रहे हैं?
क्या हमारी वेलोसिटी एक योजना सहायता है या एक लक्ष्य जिसे हम चुपचाप गेम कर रहे हैं?
कौन से निर्णय और स्थिति केवल मीटिंगों और लोगों की यादों में रहते हैं, और उन्हें लिखा जाना चाहिए?
हमारी सिंक्रोनस मीटिंगों की लागत किसका समय क्षेत्र उठाता है, और क्या यह निष्पक्ष है?
क्या हमारे ठेकेदार और विक्रेता हमारे स्टाफ़ के समान दृश्यमान फ़्लो में काम कर रहे हैं?

मुख्य निष्कर्ष

पद्धतियों के पीछे के सिद्धांत अपनाएँ, केवल उनके अनुष्ठान नहीं।
काम में फ़िट बैठने के लिए Agile, Kanban, या एक मिश्रण चुनें; छोटे बैच और तेज़ फ़ीडबैक को प्राथमिकता दें।
स्केलिंग फ़्रेमवर्क को संशयवादी ढंग से देखें; प्रक्रिया जोड़कर नहीं, समन्वय घटाकर स्केल करें।
अनुमानों का उपयोग बातचीत और पूर्वानुमान के लिए करें, कभी उत्पादकता लक्ष्यों या वादों के रूप में नहीं।
असिंक्रोनस, दस्तावेज़-प्रथम संचार को डिफ़ॉल्ट बनाएँ ताकि बड़ी, वितरित, मिश्रित टीमें सहयोग कर सकें।
गतिविधि या उपयोग के लिए नहीं, परिणामों और फ़्लो के लिए अनुकूलित करें।

संदर्भ और आगे पढ़ना

David J. Anderson, “Kanban: Successful Evolutionary Change for Your Technology Business”
Donald Reinertsen, “The Principles of Product Development Flow”
Mary and Tom Poppendieck, “Lean Software Development: An Agile Toolkit”
Craig Larman and Bas Vodde, “Large-Scale Scrum (LeSS)”
Nicole Forsgren, Jez Humble, Gene Kim, “Accelerate” (delivery metrics)
The Agile Manifesto and its twelve principles
Henrik Kniberg, “Scaling Agile @ Spotify” (with the caution that it is a snapshot, not a model)
GitLab’s public Handbook on asynchronous, remote-first working