Scrum को स्केल करना: आपके संगठन में Scrum को स्केल करने के विभिन्न दृष्टिकोण

Scrum को स्केल करना Scrum सिद्धांतों और प्रथाओं को बड़े, अधिक जटिल प्रोजेक्ट्स या संगठनात्मक संरचनाओं पर लागू करने की प्रक्रिया को संदर्भित करता है।

मूल रूप से एकल प्रोजेक्ट्स पर काम करने वाली छोटी, क्रॉस-फंक्शनल टीमों के लिए डिज़ाइन किया गया, Scrum की स्केलेबिलिटी का बड़ी पहलों में परीक्षण और प्रमाण किया गया है।

त्वरित उत्तर: स्केलिंग फ्रेमवर्क एक नज़र में

फ्रेमवर्क	टीम की संख्या	जटिलता	सर्वश्रेष्ठ उपयोग
Scrum of Scrums	2-5 टीमें	कम	सरल मल्टी-टीम समन्वय
Nexus	3-9 टीमें	मध्यम	एक Backlog के साथ प्रोडक्ट-केंद्रित स्केलिंग
LeSS	2-8 टीमें (Basic) / 8+ (Huge)	मध्यम	सरलता-केंद्रित एंटरप्राइज स्केलिंग
SAFe	कोई भी आकार	उच्च	पूर्ण गवर्नेंस वाले बड़े एंटरप्राइज़
Scrum@Scale	कोई भी आकार	मध्यम	पूर्ण संगठनात्मक Agile परिवर्तन
DAD	कोई भी आकार	मध्यम-उच्च	लचीला टूलबॉक्स दृष्टिकोण
Spotify Model	कोई भी आकार	कम-मध्यम	संस्कृति-संचालित स्वायत्तता

Scrum कब स्केल करें

हर संगठन को Scrum स्केल नहीं करना होता। इन संकेतों पर स्केलिंग पर विचार करें:

स्केलिंग के मजबूत संकेत:

• एक अकेला Scrum Team Sprint के भीतर अकेले Product Increment नहीं दे सकता
• कई टीमें एक ही प्रोडक्ट पर काम कर रही हैं और बार-बार इंटीग्रेशन संघर्ष होते हैं
• टीमों के बीच निर्भरताएं देरी पैदा कर रही हैं
• Product Backlog इतना बड़ा हो गया है कि एक टीम उसे प्रभावी ढंग से प्रबंधित नहीं कर सकती

अभी स्केल न करने के संकेत:

• आपकी अकेली Scrum Team अभी भी बन रही है या अच्छा प्रदर्शन नहीं कर रही
• टीमें अभी भी हर Sprint में लगातार Done Increment नहीं दे रहीं
• बुनियादी Scrum प्रथाएं अभी तक स्थापित नहीं हैं

Scrum को स्केल करने की चुनौतियां

Scrum को स्केल करना विभिन्न चुनौतियां प्रस्तुत कर सकता है:

1. समन्वय और संचार: जैसे-जैसे टीमों और व्यक्तियों की संख्या बढ़ती है, संचार और समन्वय अधिक जटिल हो जाता है। निर्भरताएं तेज़ी से बढ़ती हैं।
2. प्रक्रियाओं में स्थिरता: प्रभावी स्केलिंग के लिए कई टीमों में Scrum प्रथाओं में स्थिरता सुनिश्चित करना आवश्यक है।
3. काम का एकीकरण: कई टीमों के काम को एकीकृत करना और एक समेकित Product Increment सुनिश्चित करना चुनौतीपूर्ण हो सकता है।
4. साझा Product Backlog प्रबंधन: कई टीमों की सेवा करने वाले एकल Product Backlog के लिए अनुशासित Refinement और प्राथमिकता प्रथाओं की आवश्यकता होती है।
5. बड़े पैमाने पर चपलता बनाए रखना: गवर्नेंस, अनुपालन और समन्वय ओवरहेड उस गति को कम कर सकते हैं जो Scrum को मूल्यवान बनाती थी।

Scrum को स्केल करने के दृष्टिकोण

Scrum को स्केल करने के कई प्रसिद्ध दृष्टिकोण हैं:

Scrum of Scrums

Scrum of Scrums एक ही प्रोडक्ट पर काम करने वाली कई Scrum टीमों के बीच सहयोग और संचार को प्रबंधित करने के लिए Scrum में उपयोग की जाने वाली एक समन्वय तकनीक है।

Scrum of Scrums में प्रमुख प्रथाएं:

• दैनिक मीटिंग्स: Scrum of Scrums मीटिंग्स आमतौर पर व्यक्तिगत Scrum टीम के Daily Scrum के बाद दैनिक आयोजित की जाती हैं। प्रत्येक टीम इस मीटिंग में एक प्रतिनिधि भेजती है।
• बाधा समाधान: टीमें उन बाधाओं पर चर्चा करती हैं जो उनकी अंतर-निर्भरताओं को प्रभावित करती हैं।
• जानकारी साझा करना: मीटिंग महत्वपूर्ण जानकारी, अपडेट और प्रगति साझा करने के लिए एक मंच के रूप में कार्य करती है।
• Backlog संरेखण: टीमें सुनिश्चित करती हैं कि उनके व्यक्तिगत Backlog समग्र Product Backlog के साथ संरेखित हों।

LeSS (Large-Scale Scrum)

LeSS (opens in a new tab) एक फ्रेमवर्क है जो एक ही प्रोडक्ट पर सहयोग करने वाली कई टीमों के लिए Scrum सिद्धांतों का विस्तार करता है। LeSS जानबूझकर नई भूमिकाएं, आर्टीफैक्ट या जटिलता जोड़ने से बचता है।

LeSS सिद्धांत:

• अनुभवजन्य प्रक्रिया नियंत्रण
• पारदर्शिता
• कम से अधिक
• संपूर्ण उत्पाद फोकस
• ग्राहक-केंद्रित
• पूर्णता की ओर निरंतर सुधार
• सिस्टम थिंकिंग
• Lean थिंकिंग
• क्यूइंग थ्योरी

LeSS की फ्रेमवर्क संरचना:

• LeSS दो कॉन्फ़िगरेशन प्रदान करता है: बेसिक LeSS, दो से आठ टीमों (10-50 व्यक्तियों) के लिए, और LeSS Huge, आठ से अधिक टीमों (50-6000+ व्यक्तियों) के लिए।
• एक Product Owner: एक एकल Product Owner सभी टीमों के लिए एक Product Backlog प्रबंधित करता है।
• एक Sprint: सभी टीमें एक ही लंबाई के समकालिक Sprint चलाती हैं।

SAFe (Scaled Agile Framework)

SAFe (opens in a new tab) बड़े पैमाने पर Agile प्रथाओं को लागू करने के लिए एक व्यापक फ्रेमवर्क है। SAFe ज्ञान के तीन प्रमुख निकायों पर स्थापित है: Agile सॉफ्टवेयर डेवलपमेंट, Lean प्रोडक्ट डेवलपमेंट, और सिस्टम थिंकिंग।

SAFe मूल मूल्य:

• संरेखण
• अंतर्निहित गुणवत्ता
• पारदर्शिता
• प्रोग्राम निष्पादन
• नेतृत्व

SAFe Framework के लाभ:

• त्वरित टाइम-टू-मार्केट: SAFe ग्राहक आवश्यकताओं के प्रति तेजी से प्रतिक्रिया देने की क्षमता को बढ़ाता है।
• बेहतर गुणवत्ता: अंतर्निहित गुणवत्ता एक मूल SAFe मूल्य है।
• पोर्टफोलियो संरेखण: SAFe पोर्टफोलियो रणनीति को टीम निष्पादन से जोड़ता है।

Nexus

Nexus (opens in a new tab) एक फ्रेमवर्क है जिसे विशेष रूप से Scrum.org (opens in a new tab) द्वारा Scrum को स्केल करने के लिए डिज़ाइन किया गया है। Nexus Integration Team निर्भरताओं को प्रबंधित करने और एक एकीकृत Product Increment सुनिश्चित करने के लिए जिम्मेदार है।

Nexus एक एकल प्रोडक्ट डिलीवर करने के लिए सहयोगात्मक रूप से काम करने वाली 3 से 9 Scrum टीमों के एक समूह से बना है।

Nexus की संरचना:

• Nexus Integration Team (NIT): Product Owner, एक Scrum Master और Scrum Teams के चुनिंदा सदस्यों से बना एक नया टीम।
• Nexus Sprint Backlog: सभी टीमों में Sprint के लिए चुने गए Product Backlog items की एक दृश्य, निर्भरताओं को उजागर करते हुए।
• एकीकृत Increment: सभी Scrum Teams के संयुक्त आउटपुट जो हर Sprint में Definition of Done को पूरा करना चाहिए।

Nexus Framework का लक्ष्य:

Nexus का लक्ष्य एक एकल प्रोडक्ट पर काम करने वाली Scrum टीमों के एक समूह द्वारा प्रदान किए गए मूल्य को अधिकतम करना है।

Spotify Model

Spotify Model (opens in a new tab) Scrum को स्केल करने का एक लोकप्रिय दृष्टिकोण है।

Spotify Model की प्रमुख विशेषताएं:

• Squads: एक स्पष्ट मिशन और एक विशिष्ट प्रोडक्ट क्षेत्र के स्वामित्व के साथ छोटी, स्व-संगठित टीमें।
• Tribes: Squads को "Tribes" में समूहित किया जाता है।
• Chapters: विभिन्न Squads में समान कौशल वाले व्यक्तियों से बने होते हैं।
• Guilds: अनौपचारिक अभ्यास समुदाय।
• स्वायत्तता: Squads को निर्णय लेने में उच्च स्तर की स्वायत्तता।

Disciplined Agile Delivery (DAD)

DAD (opens in a new tab) एक प्रक्रिया निर्णय फ्रेमवर्क है जो Agile और Lean सिद्धांतों की नींव पर बनाता है।

DAD के प्रमुख सिद्धांत:

• अपना Wow चुनें: DAD प्रोजेक्ट या संगठन की अनूठी आवश्यकताओं के आधार पर सही Agile और Lean प्रथाओं को चुनने के महत्व पर जोर देता है।
• जिसमें आप अच्छे हैं उसमें उत्कृष्ट बनें: संगठनों की ताकत का लाभ उठाएं।
• संदर्भ मायने रखता है: प्रत्येक स्थिति अद्वितीय है।
• एंटरप्राइज जागरूकता: एंटरप्राइज स्तर पर Agile प्रथाओं को स्केल करने के लिए मार्गदर्शन।

Scrum@Scale (S@S) के साथ Scrum में स्केलिंग

जबकि Scrum को व्यक्तिगत टीमों पर लागू किया जा सकता है, Scrum@Scale कई टीमों और इकोसिस्टम में Agile प्रथाओं को स्केल करके पूरी संगठनात्मक संस्कृति को बदलने के लिए डिज़ाइन किया गया है।

S@S की मूल अवधारणाएं:

• छोटी टीमें: टीमों में आमतौर पर तीन से नौ सदस्य होते हैं।
• संगठन भर में स्केलिंग।
• न्यूनतम व्यवहार्य नौकरशाही।
• दो चक्र: Scrum Master चक्र और Product Owner चक्र।

Scrum@Scale में भूमिकाएं:

Scrum@Scale में, Product Owner और Scrum Master की भूमिकाएं समान जिम्मेदारियों के साथ बनी रहती हैं। फ्रेमवर्क Chief Product Owner (CPO) और Scrum of Scrums Master (SoSM) जैसी नई भूमिकाएं पेश करता है।

स्केलिंग परिपक्वता मॉडल

चरण 1: समन्वित टीमें (महीने 1-6)

विशेषताएं:

• कई स्वतंत्र Scrum टीमें मौजूद हैं लेकिन अलग-अलग काम करती हैं
• टीम स्तर पर बुनियादी Scrum का अभ्यास

फोकस क्षेत्र:

• Scrum of Scrums मीटिंग्स स्थापित करें
• साझा Definition of Done बनाएं
• क्रॉस-टीम Backlog Refinement शुरू करें

चरण 2: एकीकृत डिलीवरी (महीने 7-18)

विशेषताएं:

• टीमें लगातार या कम से कम हर Sprint में काम एकीकृत करती हैं
• साझा Product Backlog सक्रिय रूप से प्रबंधित

फोकस क्षेत्र:

• स्वचालित परीक्षण और CI/CD प्रथाओं को मजबूत करना
• Nexus Integration Team या समकक्ष को औपचारिक रूप देना

चरण 3: संरेखित संगठन (महीने 19-36)

विशेषताएं:

• रणनीति Sprint Goals से जुड़ती है
• व्यावसायिक Stakeholder Sprint Reviews में सक्रिय रूप से शामिल

चरण 4: अनुकूली एंटरप्राइज़ (महीना 37+)

विशेषताएं:

• संगठन अपने स्केलिंग दृष्टिकोण को निरंतर अनुकूलित करता है
• Agile सोच व्यावसायिक रणनीति में एम्बेड की गई

उद्योग-विशिष्ट स्केलिंग उदाहरण

SaaS और Cloud सेवाएं

• प्लेटफॉर्म टीम बुनियादी ढांचे के Product Backlog items के मालिक हैं
• Nexus Integration Team में Site Reliability Engineers शामिल हैं
• Feature flags कई टीमों को बिना एक-दूसरे को ब्लॉक किए code इंटीग्रेट करने देते हैं
• Definition of Done में स्वचालित performance regression परीक्षण शामिल हैं

स्वास्थ्य सेवा प्रौद्योगिकी

• HIPAA और HL7 FHIR अनुपालन साझा Definition of Done में शामिल
• Nexus Sprint Reviews में नैदानिक Stakeholders की सीधी प्रतिक्रिया

वित्तीय सेवाएं

• Nexus Integration Team में जोखिम और अनुपालन प्रतिनिधि
• PCI-DSS और SOX आवश्यकताएं प्रोग्राम-स्तरीय मानदंड के रूप में

ई-कॉमर्स

• त्योहारी सीजन (दीवाली, आदि) की योजना LeSS Huge Area स्तर पर
• Checkout से संबंधित सभी stories के लिए Definition of Done में performance परीक्षण

सामान्य स्केलिंग एंटी-पैटर्न

एंटी-पैटर्न 1: सिंगल-टीम Scrum की महारत से पहले स्केलिंग

समस्या: संगठन SAFe या LeSS को तब अपनाते हैं जब व्यक्तिगत टीमें अभी भी बुनियादी Scrum प्रथाओं से संघर्ष कर रही होती हैं।

समाधान: स्केलिंग परत जोड़ने से पहले सुनिश्चित करें कि प्रत्येक टीम लगातार एक Done Increment दे सके।

एंटी-पैटर्न 2: Spotify Model को शाब्दिक रूप से कॉपी करना

समस्या: नेता पूरे संगठन को रातोरात Squads और Tribes में पुनर्गठित कर देते हैं।

समाधान: Spotify की सफलता के पीछे के सिद्धांतों पर ध्यान केंद्रित करें - स्वायत्त टीमें, उच्च संरेखण, स्पष्ट मिशन।

एंटी-पैटर्न 3: SAFe प्रोजेक्ट प्रबंधन थिएटर के रूप में

समस्या: संगठन SAFe के ceremonies को लागू करते हैं लेकिन वास्तव में निर्णय कैसे लिए जाते हैं यह नहीं बदलते।

समाधान: PI Planning वास्तव में सहयोगी होनी चाहिए।

एंटी-पैटर्न 4: केवल नाम के लिए एक Backlog

समस्या: कागज पर एक "एकल Product Backlog" मौजूद है, लेकिन प्रत्येक टीम अपने निजी Backlog से काम करती है।

समाधान: नियमित क्रॉस-टीम Product Backlog Refinement sessions आयोजित करें।

एंटी-पैटर्न 5: Integration काम की अनदेखी करना

समस्या: टीमें feature काम की योजना बनाती हैं लेकिन Sprint Backlog से integration tasks छोड़ देती हैं।

समाधान: Integration tasks को स्पष्ट Sprint Backlog items बनाएं।

एंटी-पैटर्न 6: नए Silos के बहाने के रूप में Scaling Frameworks

समस्या: टीमें LeSS या Nexus को अपनाती हैं लेकिन पहले की तरह काम करती रहती हैं।

समाधान: क्रॉस-टीम events वास्तव में सहयोगी होने चाहिए।

एंटी-पैटर्न 7: स्केलिंग के मानवीय पहलू को नज़रअंदाज करना

समस्या: स्केलिंग को तकनीकी या प्रक्रिया समस्या के रूप में माना जाता है।

समाधान: प्रक्रिया परिवर्तनों के साथ Change Management में निवेश करें।

एंटी-पैटर्न 8: Framework चुनाव पर कभी पुनर्विचार न करना

समस्या: कोई संगठन SAFe को अपनाता है और इसे स्थायी बुनियादी ढांचे के रूप में देखता है।

समाधान: अपने framework चुनाव को एक प्रयोग के रूप में मानें।

अपना ज्ञान जांचें

निष्कर्ष

बड़े पैमाने पर प्रोडक्ट डेवलपमेंट की चुनौतियों को नेविगेट करने का लक्ष्य रखने वाले संगठनों के लिए Scrum को स्केल करना आवश्यक है।

मुख्य निष्कर्ष:

• ठोस सिंगल-टीम Scrum प्रथाओं को स्थापित करने के बाद ही स्केल करें
• अपने संगठन के आकार, संस्कृति और गवर्नेंस आवश्यकताओं के आधार पर एक framework चुनें
• स्केलिंग के मानवीय पहलू में निवेश करें
• Framework चुनाव को एक प्रयोग के रूप में मानें
• प्रक्रिया अनुपालन नहीं बल्कि परिणाम मापें

अक्सर पूछे जाने वाले प्रश्न (FAQs)