11.6

View in English

11.6 वैल्यू स्ट्रीम मैपिंग और देरी की लागत

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

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

ये दोनों नज़रिए भाग 11 के बाकी हिस्से के पूरक हैं। अध्याय 11.1 उस डिस्कवरी पाइपलाइन का वर्णन करता है जो तय करती है कि क्या बनाना है, और अध्याय 11.2 उस डिलीवरी पाइपलाइन का वर्णन करता है जो उसे शिप करती है। वैल्यू स्ट्रीम मैपिंग दोनों में फैली हुई है, पहले विचार से मापे गए परिणाम तक के पूरे रास्ते को एक ऐसे सिस्टम के रूप में मानती है जिसे देखा और बेहतर बनाया जाना है। अध्याय 11.3 आपको कतारों का गणित देता है; यह अध्याय आपको यह पता लगाने की प्रथा देता है कि आपके संगठन में वे कतारें वास्तव में कहाँ बनती हैं और उनकी कीमत क्या है। जहाँ 11.4 (OKR) और 11.5 (KPI) आपको बताते हैं कि अच्छा कैसा दिखता है, वहीं देरी की लागत आपको वह क्रम बताती है जिसमें उसे हासिल करना है।

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

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

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

सिफ़ारिशें

विचार से मूल्य तक वैल्यू स्ट्रीम को मैप करें

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

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

प्रक्रिया समय को प्रतीक्षा समय से अलग करें, और फ़्लो दक्षता की गणना करें

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

यह संख्या हर सुधार वार्तालाप को फिर से परिभाषित करती है। जब फ़्लो दक्षता 15 प्रतिशत है, तो काम को खुद 20 प्रतिशत तेज़ बनाने से कुल में केवल तीन अंकों का सुधार होता है, जबकि आधी प्रतीक्षा हटाने से आपकी गति लगभग दोगुनी हो जाती है। टीमें सहजता से तेज़ कोड करने, तेज़ समीक्षा करने, तेज़ टेस्ट करने की कोशिश करती हैं। मैप आपको बताता है कि लाभ लगभग कभी काम करने वाले चरणों में नहीं होता और लगभग हमेशा उनके बीच की प्रतीक्षा में होता है। डिब्बों का नहीं, खाली जगह (व्हाइटस्पेस) का पीछा करें।

हैंडऑफ़ और रीवर्क लूप को नामित करें

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

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

अड़चन (बॉटलनेक) खोजें और बाधाओं के सिद्धांत का सम्मान करें

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

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

अर्थशास्त्र के साथ प्राथमिकता तय करने के लिए देरी की लागत का उपयोग करें

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

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

CD3 और वेटेड शॉर्टेस्ट जॉब फर्स्ट के साथ क्रमबद्ध करें

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

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

हर मद की तात्कालिकता प्रोफ़ाइल पढ़ें

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

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

फ़्लो मेट्रिक्स को DORA और लिटल्स लॉ से जोड़ें

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

ये फ़्लो मेट्रिक्स ऊपर की ओर DORA मेट्रिक्स (DevOps Research and Assessment कार्यक्रम से) से भी जुड़ते हैं: डिप्लॉयमेंट फ्रीक्वेंसी, बदलावों के लिए लीड टाइम, चेंज-फेल्योर रेट, और सेवा बहाल करने का समय। बदलावों के लिए लीड टाइम आपकी वैल्यू स्ट्रीम का एक टुकड़ा है, और मैपिंग आपको दिखाती है कि इसे सुधारने के लिए किन चरणों पर हमला करना है। DORA को परिणाम स्कोरबोर्ड मानें और वैल्यू स्ट्रीम मैप को उस निदान के रूप में मानें जो स्कोर की व्याख्या करता है, दोनों को अध्याय 1.10 के इंजीनियरिंग-प्रभावशीलता दृष्टिकोण से जोड़ते हुए।

कतारों, बैच आकार, और WIP को जानबूझकर प्रबंधित करें

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

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

ट्रेड-ऑफ़: फ़ायदे और नुकसान

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

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

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

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

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

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

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

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

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

क्षेत्रीय परिप्रेक्ष्य

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

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

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

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

उदाहरण

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

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

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

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

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

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

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

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

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

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

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

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

  1. आपकी वर्तमान फ़्लो दक्षता क्या है, और यदि आप काम को तेज़ करने के बजाय आधी प्रतीक्षा हटा दें, तो आप कितने तेज़ होंगे?
  2. अभी आपकी एक सच्ची बाधा कहाँ है, और इसे कभी निष्क्रिय बैठने या ऐसा काम करने से रोकने के लिए क्या करना होगा जो एक सस्ता चरण कर सकता है?
  3. आपकी शीर्ष पाँच बैकलॉग मदों के लिए, एक महीने की देरी हर एक की क्या कीमत चुकाती है, और क्या देरी की लागत को अवधि से विभाजित करके रैंक करने से क्रम बदल जाता है?
  4. आपकी किस प्रमुख पहल की तात्कालिकता प्रोफ़ाइल क्षीण हो रही है, और क्या आपको इसके अधिकांश मूल्य के पहले ही वाष्पित हो जाने के बाद इसे शिप करने का जोखिम है?
  5. यदि आप कल WIP को आधा कर दें, तो लिटल्स लॉ आपके लीड टाइम के लिए क्या पूर्वानुमान लगाएगा, और इसे आज़माने के लिए आपको किस सांस्कृतिक प्रतिरोध को पार करना होगा?
  6. आपका सामान्य बैच (रिलीज़, पुल रिक्वेस्ट, आवश्यकताओं का दस्तावेज़) कितना बड़ा है, और इसे आधा करने से आपकी फ़ीडबैक गति और प्रति-बदलाव जोखिम पर क्या असर पड़ेगा?

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

  • विचार से मूल्य तक के पूरे प्रवाह को मैप करें और फ़्लो दक्षता की गणना करें; चरणों के अंदर के काम में नहीं, बल्कि उनके बीच की प्रतीक्षा में आपका लाभ रहता है।
  • एक अकेली बाधा खोजें और बाधाओं के सिद्धांत का सम्मान करें: किसी भी अन्य चरण को अनुकूलित करने से कुछ नहीं सुधरता और यह केवल अड़चन को तेज़ी से खिलाता है।
  • “सब कुछ प्राथमिकता एक है” को हराने के लिए देरी की लागतों को पैसे में स्पष्ट करें, और यह जानने के लिए हर मद की तात्कालिकता प्रोफ़ाइल पढ़ें कि कीमत कब पड़ती है।
  • कुल आर्थिक देरी को न्यूनतम करने के लिए देरी की लागत को अवधि से विभाजित करके (CD3 या WSJF) क्रमबद्ध करें, छोटे, मूल्यवान काम को कतार में आगे कूदने दें।
  • WIP सीमाओं और छोटे बैचों के साथ कतारों को प्रबंधित करें, अपने फ़्लो मेट्रिक्स को DORA और लिटल्स लॉ से जोड़ें, और वैल्यू स्ट्रीम प्रबंधन को एक सतत प्रथा के रूप में चलाएँ।

संदर्भ और आगे पढ़ने के लिए

  • Donald G. Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development
  • Eliyahu M. Goldratt and Jeff Cox, The Goal: A Process of Ongoing Improvement
  • Mike Rother and John Shook, Learning to See: Value Stream Mapping to Add Value and Eliminate Muda
  • Karen Martin and Mike Osterling, Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation
  • Mik Kersten, Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework
  • Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps
  • Dean Leffingwell, SAFe 5.0 Distilled: Achieving Business Agility with the Scaled Agile Framework