10.7 एजाइल

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

एजाइल सॉफ़्टवेयर (और मूल्य) को इटरेटिव रूप से, इंक्रीमेंटल रूप से, और उन लोगों के साथ नज़दीकी सहयोग में डिलीवर करने की एक मानसिकता है जो इसका उपयोग करेंगे। 2001 के Manifesto for Agile Software Development में संहिताबद्ध, इसे सबसे अच्छी तरह एक प्रक्रिया के रूप में नहीं बल्कि मूल्यों और सिद्धांतों के समुच्चय के रूप में समझा जाता है: व्यक्तियों और परस्पर संवाद, कार्यशील सॉफ़्टवेयर, ग्राहक सहयोग, और परिवर्तन के प्रति प्रतिक्रिया को उन पहले से मौजूद योजना-भारी, अनुबंध-भारी, दस्तावेज़ीकरण-भारी डिफ़ॉल्ट पर प्राथमिकता देना। Scrum, Kanban, और Extreme Programming (XP) जैसे फ़्रेमवर्क उस मानसिकता के कार्यान्वयन (implementations) हैं। ये उपयोगी शुरुआती बिंदु हैं, लेकिन स्वयं मानसिकता नहीं हैं। यह अध्याय अध्याय 1.4 (कार्य करने के तरीके, जो विधियों का व्यापक सर्वेक्षण करता है) का पूरक है, जो विशेष रूप से एजाइल पर गहराई से जाता है।

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

बड़ी टीमों, एंटरप्राइज़, और सरकार के लिए, एजाइल शक्तिशाली भी है और अक्सर विकृत भी कर दिया जाता है। एंटरप्राइज़ सैकड़ों टीमों में इसे अपनाते हैं और अक्सर इसे एक रस्म में बदल देते हैं (“अब हम स्टैंड-अप करते हैं”) बिना यह बदले कि निर्णय कैसे लिए जाते हैं या मूल्य कैसे मापा जाता है। सरकार ने जानबूझकर एजाइल को अपनाया है, क्योंकि इटरेटिव, उपयोगकर्ता-केंद्रित डिलीवरी बड़े सार्वजनिक कार्यक्रमों के जोखिम को प्रदर्शनीय रूप से कम करती है: U.S. Digital Service और इसकी Digital Services Playbook, UK की Government Digital Service और Service Standard, और एजाइल खरीद (प्रोक्योरमेंट) सुधार, ये सभी आंशिक रूप से हाई-प्रोफ़ाइल वाटरफ़ॉल विफलताओं की प्रतिक्रिया में उत्पन्न हुए। यह पुरस्कार वास्तविक है। “केवल नाम के लिए एजाइल” होने की विफलता भी उतनी ही वास्तविक है।

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

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

सिफारिशें

मूल्यों और सिद्धांतों पर आधारित रहें, कर्मकांडों पर नहीं

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

किसी फ़्रेमवर्क को एक शुरुआती बिंदु के रूप में चुनें, धर्म के रूप में नहीं

ऐसा फ़्रेमवर्क चुनें जो काम के अनुकूल हो और उसे ढालें:

• Scrum: टाइमबॉक्स्ड स्प्रिंट, एक प्राथमिकता-क्रमित बैकलॉग, और परिभाषित भूमिकाएँ (प्रोडक्ट ओनर, स्क्रम मास्टर, डेवलपर)। स्पष्ट प्रोडक्ट ओनर के साथ फ़ीचर डिलीवरी के लिए अच्छा; जब काम अत्यधिक इंटरप्ट-ड्रिवेन हो तो कमज़ोर।
• Kanban: स्पष्ट वर्क-इन-प्रोग्रेस सीमाओं और एक पुल सिस्टम के साथ निरंतर प्रवाह। सपोर्ट, ऑपरेशंस, और अप्रत्याशित आगमन के लिए अच्छा (और सीधे फ़्लो तथा क्यूइंग थ्योरी पर आधारित, देखें अध्याय 11.2, 11.3)। WIP को सीमित करने से लीड टाइम कम होता है (Little’s Law)।
• Extreme Programming (XP): इंजीनियरिंग प्रथाएँ जिनमें टेस्ट-ड्रिवेन डेवलपमेंट, पेयर प्रोग्रामिंग, सतत एकीकरण, रीफ़ैक्टरिंग, और छोटे रिलीज़ शामिल हैं। वह तकनीकी रीढ़ जो किसी भी फ़्रेमवर्क को टिकाऊ बनाती है।
• Scrumban और मिश्रण (ब्लेंड): व्यावहारिक संयोजन जिन पर कई परिपक्व टीमें अंततः पहुँचती हैं।

फ़्रेमवर्क केवल एक ढांचा (स्कैफ़ोल्डिंग) हैं। जो मदद करे उसे रखें, जो न करे उसे छोड़ें, और कभी भी “फ़्रेमवर्क ऐसा कहता है” को “सिद्धांत बताते हैं क्यों” पर हावी न होने दें।

तकनीकी उत्कृष्टता पर ज़ोर दें

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

सावधानी से स्केल करें, और डीस्केलिंग को प्राथमिकता दें

स्केलिंग फ़्रेमवर्क, जैसे SAFe (Scaled Agile Framework), LeSS, Nexus, और Scrum@Scale, कई टीमों को साझा लक्ष्यों की दिशा में समन्वित करते हैं। ये मदद कर सकते हैं, लेकिन इनके साथ एक चेतावनी जुड़ी है (अध्याय 1.4 की बात दोहराते हुए): भारी स्केलिंग फ़्रेमवर्क अक्सर उसी कमांड-एंड-कंट्रोल, योजना-भारी ओवरहेड को फिर से लागू कर देते हैं जिसे हटाने के लिए एजाइल बनाया गया था। किसी बड़े फ़्रेमवर्क को अपनाने से पहले, डीस्केलिंग आज़माएँ। स्पष्ट स्वामित्व और न्यूनतम क्रॉस-टीम निर्भरताओं (अध्याय 1.2) वाली स्वतंत्र, स्ट्रीम-अलाइंड टीमों के इर्द-गिर्द संगठित हों, ताकि शुरुआत में ही आपको कम समन्वय तंत्र की आवश्यकता हो। जहाँ समन्वय वास्तव में आवश्यक है, वहाँ सबसे हल्की संरचना जोड़ें जो काम करे, और उसे आउटपुट के बजाय परिणामों (OKR, ऑब्जेक्टिव्स एंड की रिज़ल्ट्स, अध्याय 11.1) से जोड़ें।

एंटरप्राइज़ और सरकार में एजिलिटी को वास्तविक बनाएं

अनुकूली (एडैप्टिव) डिलीवरी और संस्थागत बाध्यताएँ साथ-साथ रह सकती हैं, लेकिन इसके लिए सोच-समझकर डिज़ाइन करना पड़ता है:

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

निरंतर सुधार करें, और इसे गंभीरता से लें

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

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

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

परिभाषित तनाव है अनुकूलनशीलता बनाम अनुमानशीलता, और सबसे आम भ्रांति यह है कि एजाइल का अर्थ है “कोई योजना नहीं”। ऐसा नहीं है। इसका अर्थ है निरंतर योजना बनाना और परिणामों और लय के प्रति प्रतिबद्ध रहना जबकि स्कोप को लचीला रहने देना। दूसरा आम जाल है एजाइल को केवल प्रक्रिया (कर्मकांड) या केवल इंजीनियरिंग (XP) के रूप में मानना। इसे दोनों की ज़रूरत है।

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

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

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

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

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

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

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

सेक्टर लेंस

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

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

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

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

उदाहरण

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

एंटरप्राइज़। एक टेलीकॉम कंपनी का 60-टीमों का ट्रांसफ़ॉर्मेशन शुरुआत में “Scrum करता है” लेकिन कोई सुधार नहीं दिखता। टीमों को अभी भी निश्चित वार्षिक स्कोप मिलता है और वे वेलोसिटी पर रिपोर्ट करती हैं। एक रीसेट सिद्धांतों पर पुनः फ़ोकस करता है: त्रैमासिक OKR फ़ीचर आदेशों की जगह लेते हैं, टीमों को क्रॉस-टीम निर्भरताएँ घटाने के लिए पुनर्गठित किया जाता है (डीस्केलिंग), और XP प्रथाओं (CI, TDD, ट्रंक-बेस्ड डेवलपमेंट) को गैर-परक्राम्य बनाया जाता है। लीड टाइम घटते हैं, दोष कम होते हैं, और, सबसे महत्वपूर्ण रूप से, व्यवसाय स्टोरी पॉइंट्स के बजाय परिणामों को मापना शुरू करता है, जिससे एजाइल डिलीवरी डिस्कवरी पाइपलाइन (अध्याय 11.1) से जुड़ जाती है।

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

व्यवसाय मामला (बिज़नेस केस): प्रेरणाएँ, ROI, और TCO

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

total cost of ownership (कुल स्वामित्व लागत) के मामले में, एजाइल किसी सिस्टम के जीवनकाल में बदलाव की लागत को कम करता है, बशर्ते इंजीनियरिंग अनुशासन वास्तविक हो। इसका प्रमुख जोखिम है नकली एजाइल: सिद्धांत या कारीगरी के बिना कर्मकांड, जो कोई भी लाभ दिए बिना मीटिंग ओवरहेड जोड़ता है, और यह एक ईमानदार वाटरफ़ॉल से भी बदतर हो सकता है। इसलिए बिज़नेस केस सशर्त है। ROI तब अधिक होता है जब आप एजाइल को मानसिकता-प्लस-इंजीनियरिंग के रूप में अपनाते हैं, और तब लगभग शून्य (या नकारात्मक) होता है जब आप इसे रस्म के रूप में अपनाते हैं। नेतृत्व के सामने मामला रखते समय एजाइल को “तेज़ी से आगे बढ़ना” नहीं बल्कि निरंतर जोखिम में कमी और परिणाम मापन के रूप में प्रस्तुत करें, और इस बात पर ज़ोर दें कि निवेश में केवल नई मीटिंगें नहीं बल्कि तकनीकी प्रथाएँ भी शामिल हों।

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

• नकली / कार्गो-कल्ट एजाइल: कर्मकांड निभाए जाते हैं जबकि निर्णय, फंडिंग, और मानसिकता वाटरफ़ॉल ही बनी रहती है।
• प्रोडक्टिविटी के रूप में वेलोसिटी: एक क्षमता अनुमान को लक्ष्य में बदलना, जो इसे भ्रष्ट कर देता है (Goodhart’s Law)।
• डार्क स्क्रम: बिना तकनीकी उत्कृष्टता के अनमेंटेनेबल, दोषों से भरे कोड में स्प्रिंट करना।
• बिना बदलाव के रेट्रोस्पेक्टिव: चिंतन जो कोई पूर्ण किए गए एक्शन उत्पन्न नहीं करता।
• निश्चित स्कोप और तारीख़ और लागत: इसे एजाइल कहना जबकि गुणवत्ता चुपचाप दबाव सोख लेती है।
• अनुपस्थित ग्राहक: कोई वास्तविक उपयोगकर्ता फ़ीडबैक नहीं, इसलिए इटरेशन गलत चीज़ को ऑप्टिमाइज़ करते हैं।
• फ़्रेमवर्क पूजा: “SAFe/Scrum ऐसा कहता है” का सिद्धांतों और टीम के निर्णय पर हावी हो जाना।
• डीस्केलिंग से पहले स्केलिंग: निर्भरताओं को घटाने के बजाय भारी समन्वय फ़्रेमवर्क जोड़ना।

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

• स्तर 1, प्रारंभ (Initiate)। वाटरफ़ॉल या तदर्थ (एड हॉक) डिलीवरी; बिग-बैंग रिलीज़; काम प्रतिक्रियात्मक और योजना-भारी है, बिना किसी इटरेटिव फ़ीडबैक और यह समझने के साझा भाव के बिना कि एजाइल किस तरह मदद कर सकता है।
• स्तर 2, विकास (Develop)। कुछ टीमें एजाइल कर्मकांड (स्टैंड-अप, स्प्रिंट, रेट्रोस्पेक्टिव) अपनाती हैं, लेकिन संगठन भर में प्रथा असंगत है: मानसिकता और इंजीनियरिंग अनुशासन रस्मों से पीछे रह जाते हैं, वेलोसिटी को आउटपुट माना जाता है, और स्कोप अभी भी पहले से तय होता है।
• स्तर 3, मानकीकरण (Standardize)। मूल्य और सिद्धांत वास्तव में संगठन भर में काम का मार्गदर्शन करते हैं, दस्तावेज़ीकृत और हर टीम से अपेक्षित; XP-शैली की तकनीकी उत्कृष्टता (CI, स्वचालित परीक्षण, रीफ़ैक्टरिंग, ट्रंक-बेस्ड डेवलपमेंट) मानक प्रथा है, टीमें स्व-संगठित होती हैं, ग्राहक हर इटरेशन में शामिल होते हैं, और रेट्रोस्पेक्टिव ठोस, पूर्ण किए गए बदलाव उत्पन्न करते हैं।
• स्तर 4, प्रबंधन (Manage)। डिलीवरी को बेसलाइन के विरुद्ध मापा और नियंत्रित किया जाता है: टीमें लीड टाइम, डिप्लॉयमेंट फ़्रीक्वेंसी, चेंज-फ़ेल रेट, और डिफ़ेक्ट एस्केप रेट (DORA-शैली के फ़्लो और स्थिरता मेट्रिक्स) को की रिज़ल्ट्स से जुड़े परिणाम मापदंडों के साथ ट्रैक करती हैं, और प्रत्येक की तुलना एक ज्ञात बेसलाइन से करती हैं। रेट्रोस्पेक्टिव एक्शन को पूर्णता तक ट्रैक किया जाता है, ओवरटाइम और बर्नआउट जैसे स्थायी-गति संकेतों की निगरानी की जाती है, और वेलोसिटी को कभी प्रोडक्टिविटी लक्ष्य के रूप में उपयोग नहीं किया जाता। गो और नो-गो निर्णय राय के बजाय इसी प्रमाण पर टिके होते हैं।
• स्तर 5, ऑर्केस्ट्रेशन (Orchestrate)। अनुकूली डिलीवरी संगठन भर में व्यवसाय और जोखिम योजना के साथ एकीकृत है: परिणाम (OKR) फंडिंग और लय को संचालित करते हैं, कम-निर्भरता वाला टीम डिज़ाइन (डीस्केलिंग) समन्वय ओवरहेड को न्यूनतम करता है, और हाइब्रिड गवर्नेंस डिलीवरी को धीमा किए बिना ओवरसाइट को संतुष्ट करता है। निरंतर सुधार कर्मकांडीय के बजाय सांस्कृतिक है, और संगठन नियमित रूप से अपने पोर्टफ़ोलियो को फिर से स्कोप करता है, फिर से टीम बनाता है, और प्रमाण तथा जोखिम की तस्वीर बदलने के साथ पुनर्संतुलित करता है।

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

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

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

• एजाइल मूल्यों और सिद्धांतों की एक मानसिकता है, कर्मकांडों का समुच्चय नहीं; फ़्रेमवर्क शुरुआती बिंदु हैं, लक्ष्य नहीं।
• कार्यशील सॉफ़्टवेयर बार-बार डिलीवर करें, परिवर्तन का स्वागत करें, और स्व-संगठित टीमों को सशक्त बनाएं।
• तकनीकी उत्कृष्टता (XP प्रथाएँ) गैर-परक्राम्य है। इसके बिना एजिलिटी तेज़ी से क्षय बन जाती है।
• सावधानी से स्केल करें; डीस्केलिंग को प्राथमिकता दें। समन्वय फ़्रेमवर्क जोड़ने से पहले निर्भरताएँ घटाएँ।
• एंटरप्राइज़/सरकार में, अनुकूली डिलीवरी को हाइब्रिड गवर्नेंस और एजाइल खरीद के साथ मिलाएँ, और वास्तविक उपयोगकर्ता पहुँच के लिए लड़ें।
• ROI है निरंतर जोखिम में कमी और जल्दी मिलने वाला मूल्य, लेकिन केवल तभी जब एजाइल वास्तविक हो, रस्म नहीं। देखें अध्याय 1.4, 11.1, 11.2, 10.6, और 11.3।

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

• Kent Beck et al., Manifesto for Agile Software Development और इसके बारह सिद्धांत (agilemanifesto.org, 2001).
• Ken Schwaber और Jeff Sutherland, The Scrum Guide.
• Kent Beck, Extreme Programming Explained: Embrace Change.
• David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business.
• Mike Cohn, User Stories Applied और Succeeding with Agile.
• Jeff Patton, User Story Mapping.
• Stephen Denning, The Age of Agile.
• Matthew Skelton और Manuel Pais, Team Topologies (टीम डिज़ाइन और डीस्केलिंग).
• Nicole Forsgren, Jez Humble, Gene Kim, Accelerate (एजाइल/DevOps प्रथाओं के लिए प्रमाण).
• U.S. Digital Service, Digital Services Playbook; UK Government, Government Service Standard.