Scrum बेकार है
यहाँ Scrum और capital-A “Agile” को व्यापक रूप से फूले-फले, ritualized frameworks के रूप में आलोचना की गई है, जो अत्यधिक meetings, cargo-cult metrics, और विकृत incentives पैदा करते हैं, जबकि वास्तविक software delivery में बहुत कम सुधार करते हैं। कई engineers रिपोर्ट करते हैं कि Scrum reactive या ops काम, बड़े संगठनों, और multi-team environments में खराब काम करता है, और तर्क देते हैं कि “bad implementation” पर डाले जाने वाले दोष वास्तव में structural हैं। Kanban, lightweight incremental planning, मजबूत retrospectives, और team-defined processes को अधिक प्रभावी माना जाता है, बशर्ते competent leadership, genuine trust, और process theater के बजाय outcomes पर ध्यान हो।
सिद्धांत में Scrum बनाम वास्तविकता
- कई टिप्पणीकार “पुस्तकीय” Scrum और कंपनियाँ वास्तव में जो करती हैं, उनके बीच अंतर करते हैं।
- आम राय: यह फ्रेमवर्क कागज़ पर हल्का होता है, लेकिन प्रमाणपत्रों, जार्गन, और टूल्स (खासकर JIRA, SAFe) के साथ एक कठोर, ऊपर-से-नीचे चलने वाली नौकरशाही में बदल दिया जाता है।
- कुछ लोग तर्क देते हैं कि यह उलटाव Agile Manifesto के “प्रक्रियाओं और टूल्स के बजाय व्यक्तियों और अंतःक्रियाओं” का उल्लंघन करता है।
मीटिंगों का बोझ और उत्पादकता में गिरावट
- बार-बार रिपोर्ट मिलती है कि इंजीनियरों के पास ceremonies और status meetings के कारण वास्तविक काम के लिए दिन में सिर्फ 3–4 घंटे (या उससे भी कम) बचते हैं।
- Sprints, standups, grooming, PI planning, और “everyone” meetings अक्सर एक-दूसरे के ऊपर चढ़ जाती हैं, खासकर जब लोग कई teams पर होते हैं।
- मीटिंग समय सीमित करने की कोशिशें भी वही चर्चाएँ “ghost” meetings या chat में ले जा सकती हैं।
Story points, estimation, और velocity
- story points को लेकर तीखी निराशा: inflation, politicization, और “points ≠ time” मंत्र के बावजूद उन्हें समय के साथ मिला देना।
- teams अक्सर estimates बढ़ा-चढ़ाकर लगाती हैं या burndown charts के साथ खेलती हैं ताकि वे अच्छे दिखें, जिससे planning विकृत हो जाती है।
- कुछ लोग intra-team planning के लिए points को उपयोगी मानते हैं; अन्य #noestimates या साधारण task counts/t-shirt sizes की वकालत करते हैं।
Scrum कहाँ काम करता है और कहाँ विफल होता है
- इसके लिए बेहतर: छोटी, focused product teams, sprints बेचने वाली consultancies, या structure की जरूरत वाली junior-heavy teams।
- अक्सर विफल: Ops/DevOps, reactive/on-call काम, infrastructure, support, hardware, और वे बड़े संगठन जिनमें priority का लगातार churn होता रहता है।
- Sprints व्यवहार में deadlines बन जाते हैं और atomic work को artificial tickets में बाँटने तथा flags के पीछे अधूरी features छोड़ने के लिए प्रेरित करते हैं।
विकल्प और अनुकूलन
- कई लोग operations और ongoing product work के लिए Kanban को पसंद करते हैं: continuous flow, WIP limits, कम ceremonies।
- अन्य XP, ad-hoc incremental development, या 37signals का Shape Up को Agile की भावना के अधिक करीब मानते हैं।
- कई teams व्यवहार में एक hybrid अपनाती हैं: minimal planning, छोटे increments, कम meetings, continuous delivery।
संस्कृति, management, और retrospectives
- एक मजबूत थीम: खराब culture और कमजोर leadership किसी भी methodology को तकलीफ़देह बना देंगे; Scrum केवल dysfunction को visible बनाता है।
- “cargo cult agile” और अनुभवहीन managers द्वारा process/metrics को हथियार बनाकर वास्तविक ज़िम्मेदारी से बचने की आलोचना।
- कुछ लोगों के लिए retrospectives Scrum की सबसे मूल्यवान practice हैं; जहाँ teams ईमानदारी से प्रक्रिया बदल सकती हैं, वहाँ Scrum बेहतर काम करता है।