6 हफ़्ते के वेबसाइट रीवैम्प (री-डिज़ाइन) के तीसरे हफ़्ते में, लीगल काउंसल ने प्रोजेक्ट मैनेजर को मैसेज करके बताया कि एक नए नियम की वजह से ज़रूरी ‘कुकी कंसेंट फ़्लो’ (cookie consent flow) में बदलाव करना होगा। डिज़ाइन टीम ने वायरफ़्रेम को मंज़ूरी दे दी थी, इंजीनियरिंग टीम ने काम शुरू कर दिया था, और मार्केटिंग टीम ने लॉन्च की घोषणा का समय भी तय कर लिया था। अब टीम एक फ़ैसले पर अटकी हुई है: क्या वे रुककर दोबारा प्लान बनाएं, या काम जारी रखें और बाद में बदलाव को शामिल करें? फ़ैसला लेने में जितनी देरी होती है, दोबारा काम (rework) उतना ही बढ़ता जाता है और भरोसा कम होता जाता है, क्योंकि कोई नहीं बता पाता कि नई लॉन्च डेट का क्या मतलब है। यह कोर्स आपको ऐसे प्रैक्टिकल तरीके सिखाता है जिनसे आप इस उलझन से बाहर निकल सकें। आप सीखेंगे कि शॉर्ट फ़ीडबैक लूप कैसे काम करते हैं, बैकलॉग और स्प्रिंट का इस्तेमाल करके हफ़्ते-दर-हफ़्ते का सही कमिटमेंट कैसे किया जाए, ट्रांसपेरेंट आर्टिफ़ैक्ट्स के ज़रिए स्टेकहोल्डर्स को कैसे साथ रखा जाए, और हर रिक्वेस्ट को संकट में बदले बिना बदलाव को कैसे संभाला जाए।
यह समझने के लिए कि फ़ीडबैक धीमा होने पर क्या गड़बड़ होती है, आप एक आसान प्रोजेक्ट टाइमलाइन पर काम करेंगे, जिसमें बीच में ही कोई ज़रूरत (requirement) बदल जाती है और टीम को उसे अपनाना पड़ता है।
बात यह नहीं है कि प्लान खराब होते हैं। बात यह है कि जब हफ़्तों के काम के बाद नई जानकारी या सीख मिलती है, तो प्लान को अपडेट करना महंगा हो जाता है।
ऐसा प्लान जो यह मानकर चलता है कि ज़रूरतें स्थिर रहेंगी, एक तरह का बड़ा दांव होता है। आप शुरू में ही सारी ज़रूरतें तय करते हैं, पूरे प्रोजेक्ट का अनुमान लगाते हैं, और फिर फाइनल हैंडऑफ़ (काम सौंपने) की दिशा में काम करते हैं। जब तीसरे हफ़्ते में कोई कानूनी ज़रूरत सामने आती है, तो टीम के पास दो खराब विकल्प होते हैं। पहला विकल्प है बदलाव को रोकना और नियमों का पालन न करने वाला काम आगे बढ़ाना, जिससे ऑपरेशनल रिस्क और दबाव में बाद का काम बढ़ जाता है। दूसरा विकल्प है बदलाव को स्वीकार करना और पुराने फैसलों पर फिर से विचार करना, जिससे दोबारा काम (rework) करना पड़ता है क्योंकि UI, ट्रैकिंग, कंटेंट और टेस्ट स्क्रिप्ट पुराने फ़्लो के हिसाब से बनाए गए थे। फेल होने का कारण मेहनत की कमी नहीं है। कारण है जानकारी या सीख मिलने में देरी। प्रोजेक्ट को कुछ असल बात पता तो चलती है, लेकिन तब तक बहुत देर हो चुकी होती है और प्लान में उसे सस्ते में शामिल करना मुश्किल होता है।
आम गलती प्रोजेक्ट के बीच में आए बदलाव को एक बार होने वाला अपवाद (exception) मान लेने से छिपा हुआ दोबारा काम (hidden rework) बढ़ जाता है, और बाद में शेड्यूल में देरी होती है जिसे प्लानिंग की गड़बड़ी के बजाय खराब काम (poor execution) समझा जाता है।
एजाइल (Agile) सीखने की प्रक्रिया को सस्ता बनाकर इसका समाधान करता है। यह छोटे साइकल के ज़रिए ऐसा करता है, जिसमें आप काम के एक छोटे हिस्से की प्लानिंग करते हैं, उसे बनाते हैं, स्टेकहोल्डर्स के साथ रिव्यू करते हैं, और फिर और काम जोड़ने से पहले बदलावों के हिसाब से खुद को ढालते हैं।
एजाइल कोई नियम-किताब नहीं है। यह वैल्यूज़ (मूल्यों) का एक समूह है जो आपको ऐसे व्यवहार की ओर ले जाता है जिससे अचानक आने वाली परेशानियां कम हों। ट्रांसपेरेंसी (पारदर्शिता) का मतलब है कि असली स्थिति सिर्फ़ स्लाइड अपडेट में नहीं, बल्कि बैकलॉग, स्प्रिंट बोर्ड और रिव्यू किए जा सकने वाले इंक्रीमेंट जैसे आर्टिफैक्ट्स में दिखनी चाहिए। कोलेबोरेशन (सहयोग) का मतलब है कि जो लोग फैसले लेते हैं और जो लोग काम करते हैं, वे अक्सर मिलकर काम करें, ताकि फैसले तब लिए जा सकें जब बदलाव करना अभी भी सस्ता हो। अडैप्टेशन (अनुकूलन) का मतलब है कि आप उम्मीद करते हैं कि ज़रूरतें बदलेंगी और आप जवाबदेही खोए बिना दोबारा प्लानिंग करने का एक कंट्रोल्ड तरीका बनाते हैं।
इन वैल्यूज़ को अपने संदर्भ में लागू करने से पहले, यह सोचें कि कौन सा व्यवहार तीसरे हफ़्ते में आए कानूनी बदलाव के कारण होने वाले दोबारा काम (rework) को सबसे ज़्यादा रोक सकता था।
Predictive तरीका (जिसे अक्सर Waterfall कहा जाता है) तब काम आता है जब ज़रूरतें स्थिर हों और गवर्नेंस के लिए शुरुआत में ही एक तय स्कोप बेसलाइन की ज़रूरत हो। Agile तब सही रहता है जब अनिश्चितता ज़्यादा हो, रिलीज़ की फ़्रीक्वेंसी मायने रखती हो, और स्टेकहोल्डर्स तेज़ी से फ़ीडबैक दे सकें। Hybrid इन दोनों का मिश्रण है; उदाहरण के लिए, कंप्लायंस के लिए तय माइलस्टोन और हर माइलस्टोन के अंदर Agile डिलीवरी।
प्रोजेक्ट मैनेजर यह चुनाव अपनी पसंद के आधार पर नहीं, बल्कि सीमाओं (constraints) को ध्यान में रखकर करता है। ज़रूरतों में अनिश्चितता, आप कितनी बार रिलीज़ कर सकते हैं, कंप्लायंस की ज़रूरतें, रिव्यू के लिए स्टेकहोल्डर्स की उपलब्धता और टीम कितनी स्थिर है, इन बातों पर विचार करें। अगर स्टेकहोल्डर्स हर हफ़्ते रिव्यू नहीं कर सकते, तो Agile सेरेमनीज़ बिना किसी फ़ैसले वाली मीटिंग बनकर रह जाती हैं। अगर कंप्लायंस के लिए पहले से ही डिटेल्ड मंज़ूरी की ज़रूरत हो, तो प्योर Agile गवर्नेंस का उल्लंघन कर सकता है, जब तक कि आप उसमें predictive कंट्रोल न जोड़ें।
सही तरीका चुनने के लिए ‘फिट सिग्नल्स’ का इस्तेमाल करें, और फिर देखें कि किस सीमा (constraint) ने उस फ़ैसले को प्रभावित किया।