इंजीनियरिंग टीमों के लिए स्प्रिंट रेट्रोस्पेक्टिव टेम्पलेट
अधिकांश रेट्रो कोई बदलाव क्यों नहीं लाते
स्प्रिंट रेट्रोस्पेक्टिव में एक संरचनात्मक समस्या है जिसे टेम्पलेट्स नहीं सुलझाते: टीमें सुधार के विचार तो पैदा करती हैं पर उनकी समीक्षा नहीं करतीं। रेट्रो पाँच एक्शन आइटम पैदा करता है। अगला रेट्रो एक साफ़ स्लेट से खुलता है। वही समस्याएँ फिर सामने आ जाती हैं।
नीचे दिया गया टेम्पलेट समीक्षा को शुरुआत में ही पका देता है ताकि इसे छोड़ा न जा सके। यह एक बदलाव रेट्रो की प्रभावशीलता के लिए किसी भी फॉर्मैट समायोजन से ज्यादा करता है।
एजेंडा (इसे कॉपी-पेस्ट करें)
अवधि: 2-हफ्ते के स्प्रिंट के लिए 60 मिनट; 1-हफ्ते के स्प्रिंट के लिए 45 मिनट
फॉर्मैट: संचालित, एक साझा असिंक बोर्ड के साथ (Miro, FigJam, Notion — आपकी पसंद)
सेक्शन 1 — एक्शन आइटम समीक्षा (10 मिनट)
- पिछले स्प्रिंट के एक्शन आइटम एक-एक करके पढ़ें
- हर एक को मार्क करें: पूरा / प्रगति पर / छोड़ा गया (छोड़ने का संक्षिप्त कारण)
- किसी भी अधूरे आइटम को आगे ले जाएँ; उन पर अभी फिर से बहस न करें
सेक्शन 2 — डेटा स्नैपशॉट (5 मिनट)
- लक्ष्य के मुकाबले स्प्रिंट वेलोसिटी
- अनप्लान्ड काम जो एक दिन से ज्यादा हो गया
- इंसिडेंट्स या ऑन-कॉल घटनाएँ
- आधे-स्प्रिंट में स्कोप बदलाव
- डेटा को स्क्रीन पर रखें, अभी कोई चर्चा नहीं
सेक्शन 3 — क्या अच्छा रहा (10 मिनट)
- टीम मीटिंग से पहले असिंक तरीके से या पहले 3 मिनट में मदें जोड़ती है
- सबसे ऊपर की 2-3 पर चर्चा करें; जिन पर साफ़ सहमति है उन्हें छोड़ दें
- जो कार्रवाई-योग्य नहीं है उस पर समय न बिताएँ
सेक्शन 4 — क्या सुधारना है (15 मिनट)
- वही फॉर्मैट: असिंक इनपुट, सबसे-ज्यादा-संकेत वाली मदों पर चर्चा
- हर मद के लिए: एक-बार की घटना या बार-बार लौटता पैटर्न? केवल पैटर्न ही एक्शन आइटम बनते हैं
- फैसिलिटेटर का काम "यह परेशान करने वाला था" को किसी विशिष्ट और बदलने योग्य चीज़ में बदलना है
सेक्शन 5 — एक्शन आइटम (15 मिनट)
- हर आइटम में होना चाहिए: विवरण, एक जिम्मेदार ("टीम" नहीं), ड्यू डेट
- अधिकतम 2-3 आइटम का लक्ष्य रखें; इससे ज्यादा जवाबदेही को पतला कर देते हैं
- सेक्शन 1 से किसी भी अधूरे आइटम को आगे ले जाएँ
समापन (5 मिनट)
- रेट्रो पर ही एक त्वरित +/-/डेल्टा
- पुष्टि करें कि रीकैप EOD से पहले चला जाता है
लोकप्रिय रेट्रो फॉर्मैट्स क्या चूक जाते हैं
Start/Stop/Continue और What Went Well/What to Improve/Action Items — दोनों मान्य फॉर्मैट हैं। समस्या फॉर्मैट में नहीं है — बल्कि यह है कि टेम्पलेट्स शायद ही समीक्षा वाले कदम को शुरुआत में एन्कोड करते हैं। वह कदम ही एकमात्र चीज़ है जो एक रेट्रो से अगले तक जवाबदेही की निरंतरता बनाती है। उसके बिना, रेट्रो एक भावना-मशीन है, बदलाव-मशीन नहीं।
टेम्पलेट्स टाइम-बॉक्स अनुशासन को भी संबोधित नहीं करते। "क्या सुधारना है" लगभग हमेशा लंबा खिंचता है क्योंकि यह "क्या अच्छा रहा" से भावनात्मक रूप से ज्यादा जोड़ने वाला होता है। बिना सख्त बॉक्स के, एक 60-मिनट का रेट्रो 90 मिनट की चर्चा और अंत में 5 मिनट के जल्दबाज़ी वाले एक्शन आइटम बन जाता है। एक्शन आइटम ही एकमात्र हिस्सा हैं जो कुछ बदलते हैं।
तीसरा अंतराल: एक्शन आइटम अस्पष्ट निर्देशों के रूप में लिखे जाते हैं। "फ़्रंटएंड-बैकएंड संवाद सुधारें" कोई एक्शन आइटम नहीं है। "सारा अगले सोमवार से शुरू करते हुए फ़्रंटएंड और बैकएंड लीड्स के बीच एक साप्ताहिक 30-मिनट का सिंक शेड्यूल करेगी" — यह है। जिम्मेदार और शुरू करने की तारीख का नाम कमरे में ही लेना होगा — बाद में विशिष्टताएँ नरम पड़ जाती हैं।
इन पैटर्नों की संचित लागत हफ्तों बाद ऐसे संदर्भ के रूप में दिखती है जो कभी कैप्चर नहीं हुआ और ऐसे फैसलों के रूप में जिन पर फिर से बहस होती है। मीटिंग टैक्स कवर करता है कि यह एक तिमाही में संख्यात्मक रूप से कैसा दिखता है।
रेट्रो रीकैप स्टैंडअप नोट्स से लिखने में ज्यादा कठिन क्यों हैं
स्टैंडअप रीकैप छोटे होते हैं। स्प्रिंट प्लानिंग रीकैप संरचित होते हैं। रेट्रोस्पेक्टिव रीकैप कठिन होते हैं क्योंकि सामग्री बिखरी होती है — स्टिकी नोट्स, ऐसी चर्चा जो सेक्शनों के बीच कूदती रहती है, भावना और डेटा का मिश्रण। जो भी रीकैप लिखता है उसे एक ऐसी मीटिंग से एक सुसंगत धागा फिर से गढ़ना पड़ता है जो एक साथ कई दिशाओं में बढ़ी।
Pavleur इसे ठीक इसी बिखराव की वजह से अच्छी तरह संभालता है। यह मीटिंग के दौरान कही गई हर चीज़ और स्क्रीन पर जो कुछ था उसे कैप्चर करता है — साझा बोर्ड, सेक्शन 2 का वेलोसिटी चार्ट, वह इंसिडेंट टिकट जिसका किसी ने सेक्शन 4 में जिक्र किया। मीटिंग के बाद की रिपोर्ट संरचित होती है, जिसमें एक्शन आइटम उससे निकाले जाते हैं जो असल में कमरे में तय हुआ (नाम लिए अनुसार जिम्मेदारों और तारीखों सहित)। कोई पुनर्निर्माण नहीं, कॉल के बाद कोई सफाई नहीं।
सिर्फ-ऑडियो वाले ट्रांसक्रिप्शन टूल्स शब्द तो कैप्चर करते हैं पर दृश्य संदर्भ नहीं। एक रेट्रो में, दृश्य अक्सर सबसे अहम हिस्सा होता है — स्टिकी नोट बोर्ड, वह ग्राफ़ जिसने एक पैटर्न सामने लाया, वह टिकट जिसने एक चर्चा को आधार दिया। वह संदर्भ किसी सिर्फ-ऑडियो वाले रीकैप में मौजूद ही नहीं होता। एक सीधी टूल तुलना के लिए: Pavleur बनाम विकल्प।
आम रेट्रो विफलता के तरीके
वही एक्शन आइटम लगातार तीन रेट्रो में दिखता है। सेक्शन 1 गैर-परक्राम्य है। अगर कोई आइटम बार-बार पूरा नहीं हो रहा, तो या तो उसे एक बताए गए कारण के साथ छोड़ दें या एस्केलेट करें — उसे अनिश्चित काल तक आगे न ले जाएँ।
चर्चा बिना समाधान के भड़ास में बदल जाती है। सेक्शन 4 में फैसिलिटेटर का काम "वह प्रोसेस बेकार है" को एक विशिष्ट, बदलने योग्य चीज़ में अनुवाद करना है। अगर इसे 30 सेकंड में विशिष्ट नहीं बनाया जा सकता, तो यह पार्किंग लॉट में जाता है।
कोई मीटिंग से पहले असिंक तरीके से मदें नहीं जोड़ता। बोर्ड 24 घंटे पहले भेजें। खाली-कैनवास की समस्या तोड़ने के लिए इसमें 2-3 मदें डाल दें। जब सब कुछ लिखा हुआ लेकर आते हैं तो मीटिंग्स बेहतर चलती हैं।