Scrum आपको stress क्यों देता है

• आज की programming, 90s और 2000s की शुरुआत की तुलना में, कहीं ज़्यादा stressful है
• उस समय काम सिर्फ deadlines के आसपास ही पागलपन भरा होता था, और बाकी समय अपेक्षाकृत शांत रहता था
• पिछले कुछ दशकों में stress बढ़ने के कारणों पर विचार किया गया
• इसका कारण competition, market changes, या सख्त deadlines नहीं, बल्कि sprint-आधारित काम करने का तरीका है

1. Sprint रुकते नहीं हैं

• Sprint कभी खत्म न होने वाली लगातार deadlines की तरह होते हैं
• Waterfall तरीका वास्तविक deadlines और events के अनुरूप था
• Sprint कृत्रिम deadlines हैं, जिनमें स्वाभाविक आराम का समय नहीं होता
• Short-term stress स्वास्थ्य के लिए अच्छा हो सकता है, लेकिन long-term stress शरीर के लिए हानिकारक है

2. Sprint स्वैच्छिक नहीं होते

• यह उस स्थिति से अलग है जब कोई टीम अपनी इच्छा से हर 2 हफ्ते में code deploy करती है
• Sprint का हर पहलू नियमों से निर्धारित होता है
• काम के अनुभव में autonomy की महत्वपूर्ण भूमिका होती है
• थोपा गया काम stress और असहजता पैदा करता है

3. Sprint महत्वपूर्ण support activities को नज़रअंदाज़ करते हैं

• Sprint अगले काम की तैयारी के लिए समय नहीं देते
• काम को करने के लिए तैयारी का समय चाहिए होता है
• Sprint तैयारी और execution को अलग करने की कोशिश करते हैं, लेकिन इससे stress बढ़ता है

Scrumfall: असली तस्वीर, और उससे भी बदतर

• ज़्यादातर Scrum implementations, Waterfall और Scrum का मिश्रण हैं
• बड़ी deadlines हमेशा पृष्ठभूमि में मौजूद रहती हैं
• जब बड़ी deadline पास आती है, तो Scrum टूट जाता है और stress बढ़ जाता है

निष्कर्ष

• Sprint में आराम नहीं होता, autonomy की कमी होती है, और तैयारी के लिए समय भी कम होता है
• Developers को अपने काम और process पर नियंत्रण होना चाहिए
• इसके लिए ethical organization बनाना या freelancer बनना जैसे प्रयासों की ज़रूरत हो सकती है

GN⁺ का सार

• यह लेख बताता है कि Scrum तरीका developers को लगातार stress क्यों देता है
• Sprint की लगातार deadlines, autonomy की कमी, और तैयारी के लिए समय की कमी इसके मुख्य कारण हैं
• Developers को अपने काम करने के तरीके पर नियंत्रण मिलना चाहिए
• समान कार्यक्षमता वाला एक अन्य तरीका Kanban है

[ahwjdekf]

SI, पब्लिक सेक्टर वगैरह के प्रोजेक्ट करते समय भी phase 1, 2, 3.. इस तरह बिना रुके लगातार दबाव बनाया जाता है। और हर अलग phase में फिर बहुत बड़े बदलाव हो जाते हैं। ऐसे में सफल डेवलपमेंट के लिए Scrum का मूल उद्देश्य भी कभी हासिल नहीं हो सकता। इस अफरा-तफरी और बेतरतीब माहौल में आखिरकार सिर्फ डेवलपर्स ही पिसते जाते हैं।

[hellopm]

मैं एक मौजूदा PM हूँ।

• जिन Agile/Scrum सेटअप्स में मुझे लगा कि चीज़ें अच्छी तरह काम कर रही थीं, उनमें बड़ा sprint खत्म होने पर retrospective किया जाता था और आराम का समय दिया जाता था। Dev team और planning team, दोनों के पास अगली चीज़ की तैयारी शुरू करने से पहले थोड़ा रुककर सांस लेने का समय होता था।

• और जिन तरीकों में मुझे लगा कि यह लेख की तरह काम नहीं कर रहा था, वहाँ waterfall से ऊपर से आने वाली deadline के नीचे product team के अंदर Scrum तरीका भी साथ में चलाया जा रहा था, जिससे stress और बढ़ गया। क्योंकि deadline खुद बदली नहीं जा सकती थी, इसलिए आराम/retrospective के लिए समय मिले बिना हर हफ्ते दौड़ते रहने जैसा था—मानो यह एक कभी खत्म न होने वाली दौड़ हो।

[hellopm]

• जिन टीमों में Agile और Scrum अच्छी तरह काम करते हैं, वहाँ मीटिंग्स प्रभावी होती हैं, और मीटिंग न होने पर भी planning और development के बीच एकतरफ़ा संबंध नहीं होता; बल्कि आपसी सम्मान, संवाद और psychological safety वाली टीम संस्कृति होती है.
• इसके उलट, जिन टीमों में यह अच्छी तरह काम नहीं करता, वहाँ अक्सर टीम सदस्य निष्क्रिय रहते हैं, दबाव बनाने वाला और दोषारोपण करने वाला लहजा होता है, और संदेहपूर्ण माहौल बार-बार दोहराया जाता है.

[savvykang]

मेरी समझ में waterfall का उद्देश्य यह है कि जितना संभव हो, requirements को शुरुआत में ही पहचान लिया जाए, और क्योंकि design-implementation-test कामों के बीच dependencies होती हैं, इसलिए काम को क्रम से किया जाए। वहीं agile और sprint का उद्देश्य यह है कि जो काम waterfall में पहले से design या implement करने के लिए बहुत बड़ा होता है, उसे छोटे हिस्सों में बाँटकर आज़माया जाए। दोनों के अपने फायदे-नुकसान हैं, और मुझे लगता है कि methodology को कट्टरता से अपनाने के बजाय, स्थिति के मुताबिक ज़रूरी चीज़ें चुनकर इस्तेमाल करना ही काफी हो सकता है। जैसा कि लेख में कहा गया है, आराम का समय भी होना चाहिए, और technical review या prototype बनाने की तैयारी के लिए समय भी होना चाहिए। काम का क्रम कौन तय करता है, उससे ज़्यादा ज़रूरी यह है कि रुकावटों को समझा जाए और वास्तविक काम के flow के अनुसार priorities तय की जाएँ; ऐसा हो तो developers की autonomy है या नहीं, यह भी शायद उतना मायने नहीं रखता।

क्या ऐसा है कि जिन managers के पास development का बिल्कुल अनुभव नहीं है, लेकिन जो development methodology की प्रक्रियाओं को अंधाधुंध लागू करना चाहते हैं, वे विदेशों में बहुत बड़ी संख्या में पैदा हो गए हैं, इसलिए विदेशी blogs पर ऐसे लेख आते हैं? यह कुछ-कुछ हमारे यहाँ उन planners और developers के बीच के टकराव जैसा लगता है, जहाँ planners को ज़मीनी कामकाज की बिल्कुल समझ नहीं होती।

[kwj9211]

व्यावहारिक काम के flow के हिसाब से प्राथमिकता सबसे बेहतर तरीके से तय करने वाला व्यक्ति खुद developer ही होता है। ऐसे में उसकी autonomy छीनकर किसी और से वह काम करवाने का यह approach, उल्टा practical work और team planning के बीच अलगाव पैदा करने की वजह बनता है, ऐसा मेरा मानना है.

अगर management अपने-आप में एक specialized field है, तो भले ही manager के पास development का अनुभव न हो, जब वह ऐसे मोड़ पर पहुंचे जहाँ development resources का management ठीक से नहीं हो रहा हो, तब उस स्थिति का समाधान manager को ही adapt या respond करके निकालना चाहिए, ऐसा मैं सोचता हूँ। लेकिन, इस responsibility को individual contributors पर थोपते हुए मैंने बहुत बार देखा है...

[savvykang]

आख़िरी ज़िम्मेदारी मैनेजर को ही लेनी चाहिए। लेकिन लगता है कि हक़ीक़त ऐसी नहीं है। जैसे कोई CEO जिसे सिर्फ़ मैनेज करना आता हो, लेकिन कंपनी के असली कामकाज की ज़रा भी समझ न हो और वह अक्सर कंपनी को डुबो दे।

[ehdgns104]

सिर्फ पिंग-पोंग खेलने वाले PM बहुत ज़्यादा हैं, sob

[GN⁺]

Hacker News राय

• Rich Hickey के कथन का हवाला देते हुए कहा गया कि प्रोग्रामर समस्या-समाधान ऐसे करते हैं मानो वे छोटी दूरी के धावक हों, जहाँ हर 100 yard पर स्टार्टिंग गन चलाकर एक नया sprint शुरू कर दिया जाता है

• अब software process से नफ़रत होने लगी है। अगर टीम का आकार ठीक रखा जाए और developers को लक्ष्य हासिल करने के लिए अधिकार दिए जाएँ, तो वे management की productivity pipeline के बिना भी अच्छा काम कर सकते हैं। Agile वगैरह managers के अपने वेतन को सही ठहराने के लिए मौजूद हैं

• यह समझना चाहा गया कि "sprint स्वैच्छिक नहीं है" से क्या मतलब है। टीम ही sprint की विशेषताएँ चुनती है, यह यूँ ही random तरीके से assign नहीं होता। यह leadership, team members और non-team stakeholders के बीच collaboration है। यह समझाना चाहिए कि Scrum इतना rigid क्यों है

• Scrum जब पहली बार आया था, तभी से यह बात बेमानी लगी कि developers लगातार sprint करते रहें। Sprint छोटा और तेज़ होता है, और उसके बाद आराम की ज़रूरत होती है। हर काम को sprint बना देना पागलपन है

• अक्सर Scrum व्यवहार में और भी ख़राब "Scrumball" बन जाता है। शुरुआत में remote teams के communication के लिए Scrum का इस्तेमाल किया गया था, लेकिन धीरे-धीरे यह marketing-driven goals और तनावपूर्ण sprint में बदल गया। Developer burnout साफ़ दिखाई देता है

• 2000 के शुरुआती दशक में engineering teams project managers के बिना खुद काम करती थीं। Software आज जितना interconnected नहीं था, और deployment cycle भी लंबी होती थी। अब CI/CD और continuous deployment की वजह से सब कुछ तेज़ी से चलता है। SCRUM तनाव देता है

• ज़्यादातर बातचीत का सार यह होता है: "मेरी नौकरी में Scrum X, Y, Z वजहों से बेकार है" और "वह ideal Scrum नहीं है"

• 40 साल से software development करने के अनुभव के आधार पर कहा गया कि कोई भी method इस्तेमाल करें, काम को बाँटना और लक्ष्य पूरे होने को दिखाना पड़ता है। छोटी टीम में सरल codebase के लिए Kanban काफ़ी हो सकता है, लेकिन बड़ी टीमों या जटिल solutions में reporting ज़रूरी होती है

• Agile, Scrum, Standups वगैरह का इस्तेमाल नहीं किया जाता। हफ़्ते में एक बार meeting करके priorities फिर से तय की जाती हैं, और ticket system से progress track की जाती है। Developers को autonomy के साथ काम करने दिया जाता है। Meetings या TPS reports की तुलना में coding पर ज़्यादा समय लगना चाहिए

• 8 कंपनियों में काम करने के अनुभव से Basecamp का Shape Up approach सबसे सफल लगा। यह पूछना ज़्यादा महत्वपूर्ण है कि "कितने दिन" नहीं बल्कि "कितना समय निवेश करेंगे"। Shape Up 6 हफ़्ते के cycle के बीच cooldown time देता है और लगातार सफल products deliver करता है