एक प्रोडक्ट टीम 10 दिन के स्प्रिंट के छठे दिन पर है, और Scrum Master के सामने तीन अलग-अलग और विरोधाभासी स्थितियाँ हैं। Product Owner और काम (स्कोप) शामिल करना चाहता है क्योंकि जल्द ही स्टेकहोल्डर रिव्यू होने वाला है। डेवलपर्स उन टिकटों के बारे में स्पष्टीकरण मांग रहे हैं जो प्लानिंग के समय ठीक लग रहे थे। QA को एक ऐसी स्टोरी में दोबारा काम (rework) करने की ज़रूरत दिखी है जिसे पहले ही ‘पूरा’ (done) मार्क कर दिया गया था। डेली Scrum अब सिर्फ़ स्टेटस मीटिंग बनकर रह गई है, और एक ही रुकावट (ब्लॉकर) की चर्चा तीन दिनों से हो रही है, लेकिन उसका कोई ज़िम्मेदार व्यक्ति (ओनर) तय नहीं है। उलझन इस बात पर है कि काम रोककर दोबारा प्लानिंग की जाए या काम जारी रखा जाए और ‘स्पिलओवर’ (काम का अगले स्प्रिंट में जाना) को स्वीकार किया जाए। इसका नतीजा यह हो रहा है कि काम में बार-बार बदलाव (churn), अधूरा काम और ऐसे अपडेट्स का ढेर लग रहा है जो असली जोखिमों को छिपा देते हैं। आप रुकावटों को कम करने के लिए AI का इस्तेमाल कर सकते हैं, लेकिन तभी जब आप इसे Scrum के खास मौकों से जोड़ें, जानकारी का एक भरोसेमंद और स्पष्ट स्रोत (source of truth) बनाए रखें, और एक आसान वर्किंग एग्रीमेंट के ज़रिए इंसानी जवाबदेही (accountability) को बनाए रखें।
समाधान खोजने से पहले, स्प्रिंट को एक टाइमलाइन की तरह देखें और पता लगाएँ कि गड़बड़ कहाँ से शुरू हुई थी।
ज़्यादातर टीमें काम को ठीक से न कर पाने (execution) को दोष देती हैं, लेकिन असल समस्या पहले ही शुरू हो जाती है—जब रिफ़ाइनमेंट (refinement) को छोड़ दिया जाता है और प्लानिंग में अस्पष्टता (ambiguity) बनी रहती है।
अस्पष्ट टिकट (tickets) से छिपा हुआ काम पैदा होता है। एक यूज़र स्टोरी छोटी लग सकती है, लेकिन उसमें एक्सेप्टेंस क्राइटेरिया (acceptance criteria) गायब होते हैं, डिपेंडेंसीज़ (dependencies) बताई नहीं जातीं, और QA की उम्मीदें सिर्फ़ मान ली जाती हैं। फिर प्लानिंग बहस में बदल जाती है, क्योंकि टीम अलग-अलग मतलब निकाल रही होती है। लंबी सेरेमनी असली समस्या नहीं है। समस्या यह है कि सेरेमनी में वह काम किया जा रहा है जो बैकलॉग (backlog) में पहले ही हो जाना चाहिए था। रुकावटें (blockers) देर से सामने आती हैं क्योंकि किसी ने भी अनुमानों, बाहरी मंज़ूरी या एनवायरनमेंट की ज़रूरतों को लिखा नहीं होता; इसलिए टीम को असलियत का पता स्प्रिंट के बीच में चलता है। स्टेटस अपडेट में बहुत ज़्यादा शोर-शराबा (noise) तब होता है जब कोई एक भी ऐसा आर्टिफैक्ट (artifact) नहीं होता जो काम को रिस्क (risk) में बदल सके। लोग इस कमी को बातचीत या कहानी सुनाकर पूरा करते हैं।
अगर रिफ़ाइनमेंट नहीं किया गया और फिर भी आप स्प्रिंट गोल के लिए कमिट करते हैं, तो अंदाज़ा लगाएँ कि पहली बार ‘बचा जा सकने वाला रीवर्क’ (avoidable rework) कहाँ सामने आएगा। वही समय है जब आपको मदद (leverage) लेने की ज़रूरत है।
AI तब मदद करता है जब वह कम महत्व वाले ड्राफ़्टिंग के काम को कम करता है और ज़रूरी जानकारी (signal) को बेहतर बनाता है, न कि तब जब वह फ़ैसलों की जगह ले लेता है। आपको ऐसे आउटपुट चाहिए जो मौजूदा स्क्रम आर्टिफैक्ट्स जैसे प्रोडक्ट बैकलॉग, स्प्रिंट बैकलॉग और रुकावटों की सूची (impediment list) में काम आ सकें। अलग-अलग मौकों पर इसका अलग तरह से इस्तेमाल करें। रिफ़ाइनमेंट में ड्राफ़्टिंग और रिस्क फ़्लैग्स से फ़ायदा होता है, जो अस्पष्ट अनुरोधों को टेस्ट किए जा सकने वाले एक्सेप्टेंस क्राइटेरिया में बदल देते हैं। प्लानिंग में स्कोप के विकल्पों का सारांश बनाने और क्षमता व डिपेंडेंसीज़ के आधार पर अनुमान लगाने से फ़ायदा होता है। डेली स्क्रम में संक्षिप्त सारांश से फ़ायदा होता है जो बदलावों (deltas) को उजागर करते हैं, न कि पूरी बातचीत का ब्यौरा। एग्ज़ीक्यूशन में रिस्क अलर्ट से फ़ायदा होता है, खासकर तब जब काम के आइटम पुराने हो जाते हैं या अलग-अलग स्टेट्स के बीच घूमते रहते हैं। रिव्यू में पूरी हो चुकी स्टोरीज़ से तैयार साफ़-सुथरे रिलीज़ नोट्स से फ़ायदा होता है। रेट्रो (Retro) में ऑब्ज़र्वेशन से निकले विषयों (themes) को एक साथ ग्रुप करने से फ़ायदा होता है, ताकि टीम कमेंट्स को छांटने के बजाय एक्शन चुनने में समय बिता सके।
हर सेरेमनी को उस AI यूज़ केस से जोड़ें जो स्प्रिंट टाइमलाइन में देखी गई खास रुकावट या परेशानी को दूर कर सके।
AI से मिले आउटपुट को बातचीत को तेज़ करने वाले सुझावों के तौर पर देखें, न कि पक्के वादों या कमिटमेंट के तौर पर।
भरोसा खोने का सबसे तेज़ तरीका है AI को ऐसी चीज़ बनाने देना जो आधिकारिक तो लगे, लेकिन गलत, संवेदनशील या ऑडिट न की जा सकने वाली हो। शुरू में ही तीन गार्डरेल्स तय कर लें। लिखने से पहले रिव्यू (Review-before-write) का मतलब है कि AI के ड्राफ़्ट के बैकlog, स्टेकहोल्डर अपडेट या फ़ैसले के लॉग का हिस्सा बनने से पहले कोई इंसान उसे चेक और एडिट करे। सच्चाई का स्रोत (Source-of-truth) का मतलब है कि AI कभी भी ‘सिस्टम ऑफ़ रिकॉर्ड’ (मुख्य रिकॉर्ड सिस्टम) न बने। सिस्टम ऑफ़ रिकॉर्ड अभी भी आपका टूल और आपके आर्टिफ़ैक्ट्स ही रहेंगे, जैसे बैकlog आइटम का विवरण, स्वीकार्यता के मानदंड (acceptance criteria) और स्प्रिंट का लक्ष्य। इंसानी जवाबदेही (Human accountability) का मतलब है कि AI की मदद से बने हर आउटपुट का एक मालिक हो जो उसके लिए जवाबदेह हो, ठीक वैसे ही जैसे किसी भी दूसरे डिलीवरेबल के लिए होता है।
गार्डरेल की मज़बूती इस आधार पर चुनें कि आप AI को कितना स्वतंत्र रखना चाहते हैं, डेटा कितना संवेदनशील है, और क्या आपको ऑडिट ट्रेल की ज़रूरत है।