2.5 फ़्लो दक्षता और वर्क इन प्रोसेस

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

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

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

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

प्रमुख सिद्धांत

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

सिफ़ारिशें

यह मान लेने से पहले कि प्रयास बॉटलनेक है, फ़्लो दक्षता मापें

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

एक स्पष्ट वर्क-इन-प्रोसेस सीमा निर्धारित करें और इसे दृश्यमान रूप से लागू करें

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

एक WIP सीमा को एक प्रणाली बाधा मानें, एक व्यक्तिगत कोटा नहीं

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

यह जाँचें कि काम निष्क्रिय क्यों बैठा है, केवल कितनी देर के लिए नहीं

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

प्रारंभिक सुधार के बाद WIP को वापस रेंगते हुए देखें

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

समझौते: लाभ और हानि

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

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

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

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

2. हमारे पास वास्तव में अभी कितना वर्क इन प्रोसेस है, पूरी टीम में, और क्या गिनने से पहले किसी को वह संख्या पता थी? उच्च WIP अक्सर स्पष्ट रूप से मापे जाने तक अदृश्य होता है, क्योंकि हर व्यक्ति केवल इसके अपने हिस्से को देखता है। वर्तमान में प्रगति में सब कुछ गिनें, जिसमें वह काम भी शामिल है जिसे आज कोई सक्रिय रूप से नहीं छू रहा है।

3. यदि हमने एक WIP सीमा अपनाई, तो एक नए अत्यावश्यक अनुरोध का हम कैसे जवाब देते हैं इसके बारे में क्या बदलने की आवश्यकता होगी? यह प्रश्न वास्तविक संगठनात्मक आदत को उजागर करता है, प्रतिवर्ती रूप से नया काम शुरू करना, जिसे एक WIP सीमा बाधित करने के लिए डिज़ाइन की गई है, और सीमा लागू करने का प्रयास करने से पहले, बाद में नहीं, इस पर चर्चा करना उचित है।

4. जब काम हमारी पाइपलाइन में निष्क्रिय बैठा है, तो विशिष्ट कारण क्या है, और क्या यह हर बार वही कारण है? एक सामान्य भावना कि “चीज़ें इधर-उधर प्रतीक्षा करती हैं” एक विशिष्ट, बार-बार होने वाले कारण से कम उपयोगी है: एक अनुपलब्ध समीक्षक, एक बुक किया गया साझा वातावरण, एक क्रॉस-टीम निर्भरता। वास्तविक हाल के उदाहरणों से वास्तविक पैटर्न को नाम दें।

5. क्या हमने कभी एक WIP सीमा अपनाई और फिर इसे अपवादों के माध्यम से चुपचाप क्षरित होते देखा? यह अत्यंत सामान्य है और ईमानदारी से चर्चा करने लायक़ है: पहले अपवाद का कारण क्या दबाव था, और क्या अपवाद बिना किसी के स्पष्ट रूप से यह तय किए नया सामान्य बन गए।

6. क्या हमारे संदर्भ में एक WIP सीमा को व्यक्तिगत, टीम, या साझा-संसाधन स्तर (जैसे एक समीक्षा क़तार या परीक्षण वातावरण) पर लागू करने की आवश्यकता होगी? अलग-अलग बॉटलनेक अलग-अलग स्तरों पर सीमाओं की माँग करते हैं, और ग़लत स्तर पर एक सीमा लागू करना, व्यक्तिगत कोटा बनाम एक साझा-क़तार सीमा, पूरी तकनीक को ग़लत लागू कर सकता है।

क्षेत्र दृष्टिकोण

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

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

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

सरकार। बहु-वर्षीय कार्यक्रम अक्सर कई वर्कस्ट्रीमों में विशाल अंतर्निहित WIP जमा करते हैं, प्रत्येक व्यक्तिगत रूप से न्यायोचित, कुल में संगठन-व्यापी दृश्यता के बिना। पोर्टफ़ोलियो-स्तरीय WIP दृश्यता को पेश करना, अनौपचारिक रूप से भी, अक्सर सब कुछ समानांतर में चलाने की बजाय काम को अनुक्रमित करने के लिए एकल सबसे प्रेरक तर्क है, क्योंकि उच्च WIP की फ़्लो-दक्षता क़ीमत एक बार मापे जाने पर दृश्यमान रूप से जमा होती है।

उदाहरण

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

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

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

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

इस अनुशासन को अपनाने की कुल लागत अधिकांशतः संगठनात्मक है, तकनीकी नहीं: एक दृश्यमान बोर्ड, एक सहमत WIP सीमा, और सीमा तक पहुँचने पर नया काम शुरू करने से ना कहने का अनुशासन। वह अनुशासन अपनाने से बनाए रखना कठिन है, यही कारण है कि ऊपर की “WIP को वापस रेंगते हुए देखें” सिफ़ारिश प्रारंभिक अपनाने जितनी ही मायने रखती है।

विरोधी-पैटर्न और नुक़सान

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

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

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

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

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

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

• फ़्लो दक्षता, कुल समय में सक्रिय समय का अनुपात, वास्तविक डिलीवरी पाइपलाइनों में आमतौर पर 25% से नीचे होती है; प्रतीक्षा समय, प्रयास नहीं, हावी है।
• वर्क इन प्रोसेस को सीमित करना थ्रूपुट को बढ़ाता है, घटाता नहीं, संदर्भ स्विचिंग को कम करके और क़तारों को छोटा करके।
• एक WIP सीमा को एक प्रणाली बाधा के रूप में लागू करें, कभी एक व्यक्तिगत कोटे के रूप में नहीं।
• एक सामान्य “प्रतीक्षा समय कम करें” निर्देश जारी करने की बजाय काम के निष्क्रिय बैठने के विशिष्ट कारण की जाँच करें।
• WIP सीमाओं के नियमित अपवादों के माध्यम से क्षरित होने के लिए देखें; हर अपवाद को एक जान-बूझकर, दृश्यमान निर्णय मानें।
• विषय 2.4 इस मात्रा को फ़्लो लोड नाम देता है और विषय 2.7 संबंध को लिटिल के नियम के रूप में औपचारिक बनाता है: वर्क इन प्रोसेस आगमन दर गुणा साइकल टाइम के बराबर है, किसी भी स्थिर क़तार के लिए।

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

• The Principles of Product Development Flow, by Donald G. Reinertsen (उत्पाद विकास में क्यूइंग थ्योरी, बैच आकार, और WIP सीमाएँ)।
• Kanban: Successful Evolutionary Change for Your Technology Business, by David J. Anderson (सॉफ़्टवेयर टीमों के लिए WIP सीमाओं और फ़्लो पर आधारभूत पाठ)।
• Actionable Agile Metrics for Predictability, by Daniel S. Vacanti (फ़्लो दक्षता माप और फ़्लो-आधारित पूर्वानुमान)।
• The Goal, by Eliyahu M. Goldratt (बाधाओं का सिद्धांत और स्थानीय व्यस्तता और प्रणाली थ्रूपुट के बीच प्रतिसहज संबंध)।