Scrum Developers: टीम आकार, Self-Managing Practices और भूमिकाओं की गाइड (2026)
Scrum Developers: टीम आकार, Self-Managing Practices और भूमिकाओं की गाइड
Developers वे लोग हैं जो Scrum Team में हर Sprint में एक उपयोग योग्य Increment का कोई भी पहलू बनाने के लिए committed होते हैं। यह role सिर्फ software engineers तक सीमित नहीं है - इसमें कोई भी शामिल है जिनके skills प्रोडक्ट में सीधे योगदान करते हैं, जैसे testers, designers, UX researchers, database specialists, technical writers, और operations engineers।
बहुत से practitioners आज भी "Development Team" search करते हैं क्योंकि यही term 2020 के आखिर तक इस्तेमाल होता था। Scrum Guide 2020 update (opens in a new tab) ने "Development Team" को हटाकर "Developers" अपनाया, और इसे Product Owner और Scrum Master के साथ, तीन अलग sub-teams की बजाय accountabilities वाली एक single, unified Scrum Team में समेट दिया। यह गाइड पूरे समय current "Developers" terminology का उपयोग करती है, लेकिन इस rename को detail में समझाती है क्योंकि पुरानी language आज भी job postings, certification study guides, और आम बातचीत में common है।
यह उन सभी के लिए एक comprehensive resource है जिन्हें यह समझना है कि Developers किसके लिए accountable हैं, एक Developers group कितना बड़ा होना चाहिए, self-organizing और self-managing के बीच का अंतर क्या है, cross-functionality असल में क्या demand करती है, और वे गलतियां जो चुपचाप अच्छी नीयत वाली teams को भी कमजोर कर देती हैं।
त्वरित उत्तर: Scrum Developers एक नज़र में
| पहलू | विवरण |
|---|---|
| Official term (Scrum Guide 2020) | "Developers" - 2017 Guide के "Development Team" label को retire कर दिया गया |
| टीम का आकार | Scrum Team कुल मिलाकर 10 या उससे कम लोगों की होती है; Developers आमतौर पर 3-9 होते हैं |
| संरचना | Cross-functional (Increment बनाने के लिए ज़रूरी सभी skills) और self-managing (तय करते हैं कौन क्या करेगा, कब, और कैसे) |
| मुख्य accountabilities | Sprint Backlog plan बनाना, Definition of Done के जरिए quality instill करना, हर दिन Sprint Goal की ओर plan adapt करना, एक-दूसरे को accountable रखना |
| आंतरिक hierarchy | कोई नहीं - कोई sub-teams नहीं, कोई titles नहीं, कोई एक Developer दूसरे का काम direct नहीं करता |
| 2020 का मुख्य अंतर | Self-managing (कौन, क्या, और कैसे) ने पूरी Scrum Team का वर्णन करने वाले term के रूप में self-organizing (सिर्फ कैसे) की जगह ली |
मुख्य अंतर्दृष्टि: "Development Team" से "Developers" का rename cosmetic नहीं था। इसने तीन अलग sub-teams के एक प्रोजेक्ट में report करने के idea को खत्म कर दिया, और इसकी जगह एक ही Scrum Team रख दी जहाँ Developers, Product Owner, और Scrum Master एक ही Product Backlog, एक ही Sprint Goal, और एक ही Definition of Done share करते हैं।
विषय सूची-
- Scrum में Developers क्या हैं?
- Scrum Guide 2020 के अनुसार Developers की Accountabilities
- Self-Managing बनाम Self-Organizing: Nuance को समझना
- Cross-Functionality और T-Shaped Skills
- टीम का आकार और संरचना
- Team Working Agreements स्थापित करना
- तकनीकी Practices जो High-Performing Developers को Support करती हैं
- Developers के लिए Industry-Specific उदाहरण
- Developers Maturity Model
- सामान्य Developers गलतियां
- एक मजबूत Developers Group कैसे बनाएं और Grow करें
- Developers Team की प्रभावशीलता मापना
- Advanced रणनीतियां और Scaling विचार
- Conclusion
- Developers पर प्रश्नोत्तरी
- अक्सर पूछे जाने वाले प्रश्न
- आगे पढ़ें
Scrum में Developers क्या हैं?
Developers Scrum Team बनाने वाली तीन accountabilities में से एक हैं, Product Owner और Scrum Master के साथ। ये वे लोग हैं जो किसी Product Backlog item को प्रोडक्ट के एक working, valuable हिस्से में बदलते हैं।
नाम के बावजूद, "Developers" सिर्फ software engineers तक सीमित नहीं है। Scrum Guide स्पष्ट रूप से कहती है कि Developers में शामिल हो सकते हैं:
- Software engineers और programmers
- Quality assurance और test engineers
- UX/UI designers और researchers
- Database administrators और data engineers
- Technical writers और documentation specialists
- DevOps, infrastructure, और platform engineers
- कोई भी दूसरा specialist जिनका skill Increment बनाने के लिए genuinely ज़रूरी है
💡
Unifying requirement कोई job title नहीं है। सवाल यह है कि क्या किसी व्यक्ति का skill Scrum Team के लिए एक usable Increment बनाने के लिए ज़रूरी है। अगर कोई skill हर Sprint में चाहिए, तो वह व्यक्ति Developers group के अंदर होना चाहिए, ना कि बाहर एक dependency के रूप में।
Development Team से Developers तक: Term क्यों बदला
2017 Scrum Guide (opens in a new tab) ने एक Scrum Team का वर्णन तीन हिस्सों से मिलकर बनी हुई की तरह किया: एक Product Owner, एक Scrum Master, और एक "Development Team"। इस phrasing से एक ऐसी structure implied होती थी जहाँ Development Team एक अलग sub-team थी जो Product Owner से काम receive करती थी - functionally कुछ वैसा ही जैसे किसी traditional structure में एक project manager engineering team को requirements सौंप दे।
2020 Scrum Guide ने "Development Team" को पूरी तरह हटा दिया। इसकी जगह, guide एक Scrum Team define करती है जिसमें तीन accountabilities हैं: Developers, Product Owner, और Scrum Master। यह एक common misreading का deliberate correction था, कोई simple word swap नहीं। Ken Schwaber और Jeff Sutherland इस perception को खत्म करना चाहते थे कि Product Owner या Scrum Master काम करने वाले लोगों से बाहर या ऊपर खड़े हैं।
असल में क्या बदला:
- "Development Team" (Scrum Team के अंदर एक sub-team) "Developers" बन गया (एक single Scrum Team के अंदर तीन accountabilities में से एक)
- Product Owner या Scrum Master द्वारा एक अलग Development Team को "manage" करने का idea explicitly खारिज कर दिया गया
- "Self-organizing" (काम कैसे होता है) की जगह "self-managing" (कौन क्या करता है, कब, और कैसे) ने ले ली - इसे अगले section में detail में cover किया गया है
- टीम की accountabilities को "responsibilities" के एक loose description की बजाय एक छोटी, explicit list के रूप में फिर से लिखा गया
पुराना term क्यों persist करता है: 2021 से पहले publish हुई certification study guides, update से unfamiliar recruiters द्वारा लिखी गई job postings, और अनगिनत blog posts और books आज भी "Development Team" इस्तेमाल करती हैं। एक Scrum context में "development team" के लिए search volume ठीक इसी वजह से high बना हुआ है - यह गाइड historically दोनों terms को synonymous मानती है, जबकि current, correct usage के रूप में "Developers" को default रखती है।
Scrum Guide 2020 के अनुसार Developers की Accountabilities
Scrum Guide चार चीज़ें list करती है जिनके लिए Developers हमेशा accountable होते हैं। ये convenient होने पर अपनाई जाने वाली optional practices नहीं हैं - ये खुद accountability को define करती हैं।
| Accountability | Practice में इसका मतलब |
|---|---|
| Sprint Backlog plan बनाना | Developers Sprint Planning के दौरान Product Backlog items select करते हैं और खुद Sprint Backlog बनाते हैं |
| Definition of Done के जरिए quality instill करना | काम का हर increment finished गिने जाने से पहले टीम की Definition of Done को satisfy करना ज़रूरी है |
| हर दिन Sprint Goal की ओर plan adapt करना | Daily Scrum वह जगह है जहाँ Developers progress inspect करते हैं और अगले 24 घंटों को re-plan करते हैं |
| पेशेवरों के रूप में एक-दूसरे को accountable रखना | कोई बाहरी manager standards enforce नहीं करता - Developers खुद को और एक-दूसरे को अपनी की गई commitments के लिए जिम्मेदार रखते हैं |
Sprint Backlog Plan बनाना
Sprint Planning के दौरान, Developers - न कि Product Owner और न ही Scrum Master - तय करते हैं कि वे realistically कितना Product Backlog काम commit कर सकते हैं और उसे कैसे बनाएंगे। नतीजे में बना Sprint Backlog एक living plan है, कोई fixed contract नहीं; Developers इसे पूरे Sprint में update करते रहते हैं जैसे-जैसे वे और सीखते हैं।
Practice में, इसका मतलब है:
- Developers externally imposed commitment accept करने की बजाय अपनी खुद की capacity forecast करते हैं
- Sprint Backlog Developers द्वारा owned और edited है, और पूरी Scrum Team को visible है
- Task breakdown, technical approach, और sequencing decisions सिर्फ Developers के होते हैं
Definition of Done के जरिए Quality Instill करना
Definition of Done वह objective, shared standard है जो "compile होने वाले code" को एक "genuinely usable Increment" से अलग करती है। Developers सिर्फ Definition of Done को meet ही नहीं करते - वे ही इसे craft और evolve करते हैं, क्योंकि इसे satisfy करने के लिए ज़रूरी technical practices के सबसे करीब वे ही होते हैं।
⚠️
एक ऐसी Definition of Done जिसे बनाने में Developers ने मदद नहीं की, या जिसे deadline pressure में कोई enforce नहीं करता, वह असल Definition of Done नहीं है - वह एक suggestion है। Quality standards जो release date सामने आते ही झुक जाते हैं, यही सबसे common तरीका है जिससे "Done" काम चुपचाप technical debt बन जाता है।
हर दिन Sprint Goal की ओर Plan को Adapt करना
हर दिन, Developers Sprint Goal के against progress inspect करने और उसके अनुसार Sprint Backlog adjust करने के लिए Daily Scrum use करते हैं। यहीं पर self-management सबसे visibly दिखता है: टीम के बाहर कोई भी अगले दिन का काम assign नहीं करता।
एक healthy adaptation pattern कुछ ऐसा दिखता है:
- Actual progress को एक task checklist से नहीं, बल्कि Sprint Goal से compare करें
- Progress को block करने वाली किसी भी चीज़ को पहचानें और एक टीम के रूप में तय करें कि उसे कैसे resolve करना है
- जो सीखा गया उसके आधार पर बचे हुए Sprint Backlog काम को re-sequence करें
- अगर Sprint Goal खुद risk में हो, तो तुरंत Product Owner को flag करें
एक-दूसरे को Accountable रखना
Scrum Team के अंदर कोई manager नहीं है जो missed commitments के लिए consequences assign करे। Developers direct, professional conversation के जरिए एक-दूसरे को accountable रखते हैं - Sprint Retrospective से reinforced, जहाँ टीम explicitly inspect करती है कि वह अपने खुद के working agreements पर कितना खरा उतरी।
💡
Peer accountability, peer pressure या public shaming जैसी नहीं है। यह सबसे अच्छा तब काम करता है जब यह उन working agreements पर बना हो जो टीम ने खुद बनाए हों - नीचे Team Working Agreements स्थापित करना देखें।
Self-Managing बनाम Self-Organizing: Nuance को समझना
यह अंतर 2020 Scrum Guide में हुए सबसे ज़्यादा misunderstood changes में से एक है, और इसे precisely समझाना worth है क्योंकि आज भी बहुत सारी मौजूदा material (और यहाँ तक कि कुछ certification prep) इन दोनों terms को mix कर देती है।
| Concept | Decision का Scope | Scrum Guide Version |
|---|---|---|
| Self-organizing | टीम तय करती है कि वह अपना काम कैसे पूरा करेगी | 2017 Guide का central term |
| Self-managing | टीम तय करती है कि काम कौन करेगा, कब, और कैसे | 2020 Guide में self-organizing की जगह defining term बना |
2017 Guide का self-organizing principle कैसे काम हुआ इसे address करता था, और implicitly कौन क्या करेगा और कभी-कभी क्या बनाना है भी बाहरी direction के अधीन छोड़ देता था। 2020 Guide का self-managing principle broader है: यह explicitly Developers को control देता है कि कौन कौन-सा काम उठाएगा और यह कब होगा, न सिर्फ technical कैसे।
Concretely, self-managing का मतलब है:
- कोई manager या Scrum Master individual Developers को tasks assign नहीं करता
- Developers खुद तय करते हैं कि कौन किस पर काम करेगा, skills, capacity, और interest के आधार पर
- टीम internally तय करती है कि Sprint के दौरान हर काम कब होगा
- Technical approach और implementation details पूरी तरह टीम का decision रहते हैं
⚠️
Self-managing का मतलब unmanaged या leaderless होना नहीं है। इसका मतलब है कि काम का management किसी external role के पास नहीं, बल्कि टीम के अंदर रहता है। Organizations अभी भी boundaries set करती हैं - budget, compliance, Product Owner से product direction - जिनके भीतर Developers self-manage करते हैं। यह concept पूरी Scrum Team में कैसे extend होता है, इसे और गहराई से देखने के लिए Self-Organization और एक Scrum Master कैसे बिना direct किए self-organization को promote करता है देखें।
Cross-Functionality और T-Shaped Skills
Cross-functionality का मतलब है कि Developers group, मिलाकर देखने पर, एक Product Backlog item को usable Increment में बदलने के लिए ज़रूरी हर skill रखता है - बिना टीम के बाहर किसी पर depend किए। इसका मतलब यह नहीं कि हर individual Developer सब कुछ कर सकता है।
T-shaped skills एक cross-functional टीम के अंदर ideal individual profile describe करते हैं:
- "T" का vertical bar एक discipline में deep expertise represent करता है (जैसे, backend engineering, UX research, database performance)
- Horizontal bar adjacent disciplines में working competence represent करता है (जैसे, एक backend engineer जो basic front-end code लिख सके, manual test pass चला सके, या एक design mockup review कर सके)
T-shaped skills शुद्ध specialists से ज़्यादा क्यों matter करते हैं:
- Single points of failure को कम करता है - अगर एक specialist out है, तो काम पूरी तरह नहीं रुकता
- एक ही Sprint के भीतर disciplines के बीच hand-off delays को घटाता है
- जब Sprint Backlog के काम का mix mid-Sprint shift हो, तो flexibility बढ़ाता है
Expertise को dilute किए बिना cross-functionality बनाना:
- Specialists को generalists के साथ जान-बूझकर pair करें, सिर्फ convenient होने पर नहीं
- Recurring task types (code review, deployment, support triage) की ownership पूरी टीम में rotate करें
- Cross-training के लिए explicit समय budget करें, सिर्फ feature delivery के लिए नहीं
- हर skill area का "bus factor" track करें - अगर कोई critical चीज़ सिर्फ एक व्यक्ति कर सकता है, तो इसे resolve करने वाला risk मानें
💡
Cross-functionality एक team-level property है, जिसे यह पूछकर evaluate किया जाता है "क्या यह Developers group बाहरी मदद के बिना एक Done Increment deliver कर सकता है?" - यह कोई individual-level requirement नहीं कि हर Developer एक generalist हो।
टीम का आकार और संरचना
Scrum Guide कुल मिलाकर 10 या उससे कम लोगों की एक Scrum Team size recommend करती है, जो आमतौर पर Product Owner और Scrum Master को अलग count करने के बाद 3 से 9 Developers में translate होती है (Scrum में, वे भी उन 10 का हिस्सा हैं, हालांकि अगर उनके पास skills और capacity हो तो Scrum Master और Product Owner कभी-कभी Developer का काम भी कर सकते हैं)।
| टीम का आकार | विशेषताएं | सुझाव |
|---|---|---|
| 1-2 Developers | न्यूनतम redundancy, individual dependency का high risk | आमतौर पर बहुत छोटी - जहाँ तक संभव हो avoid करें |
| 3-5 Developers | Lean, fast communication, focused products के लिए अच्छा काम करती है | Early-stage products या narrow scopes के लिए solid |
| 6-9 Developers | Communication manageable रहते हुए meaningful throughput के लिए पर्याप्त capacity | ज़्यादातर established product teams के लिए sweet spot |
| 10+ Developers | Output से तेज़ी से बढ़ता communication overhead; coordination एक full-time concern बन जाता है | इसके बजाय multiple Scrum Teams में split करें |
⚠️
छोटा होना आमतौर पर बड़े से ज़्यादा safe है। Scrum Guide की खुद की guidance कहती है कि smaller teams आमतौर पर बेहतर communicate करती हैं और ज़्यादा productive होती हैं। जब कोई Developers group लगभग नौ लोगों से ज़्यादा हो जाता है, तो fix एक बड़ी Sprint Planning meeting नहीं है - यह दो Scrum Teams में split होना है जो एक Product Backlog share करती हैं।
Headcount से आगे की composition guidance:
- किसी specific number को hit करने से ज़्यादा product को genuinely चाहिए वाले skills cover करने को प्राथमिकता दें
- एक narrow product (जैसे, एक single mobile app) को एक broad platform से अलग skill mix चाहिए होता है
- Testing और design skills को external services की तरह treat करने की बजाय टीम के अंदर रखें
- टीम को पूरी तरह एक discipline के specialists से न बनाएं - यह एक ही Sprint के अंदर फिर से functional silos बना देता है
Team Working Agreements स्थापित करना
Working agreements वे explicit, team-authored rules हैं जो self-management और peer accountability को दिन-प्रतिदिन practical बनाते हैं। इनके बिना, "एक-दूसरे को accountable रखना" को hold करने के लिए कोई shared standard नहीं होता।
Working agreements की common categories:
| Category | उदाहरण Agreement |
|---|---|
| Availability | Core collaboration hours जब हर कोई reachable हो, time zones के across भी |
| Code review | कम से कम एक approving review के बिना कोई merge नहीं; reviews 24 घंटों के भीतर turn around हों |
| Communication | Daily Scrum समय पर शुरू होता है चाहे कोई भी present हो; blockers उसी दिन raise होते हैं |
| Definition of Done | Explicit, written, और कम से कम हर quarter में एक बार revisit की गई |
| Conflict handling | Disagreements पहले सीधे उस व्यक्ति के साथ raise होते हैं, तुरंत escalate नहीं होते |
| Meeting discipline | Remote sync meetings के लिए cameras on; agenda पहले से share किया जाता है |
Working agreements कैसे बनाएं जो टिके रहें:
- इन्हें एक workshop में collaboratively draft करें, कभी top-down impose न करें
- Initial list छोटी रखें - पांच या छह agreements जिन्हें टीम actually follow करेगी, पंद्रह से बेहतर हैं जिन्हें ignore कर दिया जाए
- इन्हें कहीं visible जगह post करें (team wiki, board header) ताकि ये एक living reference बनें, भूली हुई document नहीं
- हर कुछ Sprints में एक Sprint Retrospective के दौरान इन्हें explicitly revisit और revise करें
तकनीकी Practices जो High-Performing Developers को Support करती हैं
Self-management और quality accountability तभी काम करती हैं जब Developers के पास Definition of Done तोड़े बिना तेज़ी से move करने का technical foundation हो। ये practices आमतौर पर उस Developers group को अलग करती हैं जो हर दिन adapt कर सकता है उससे जो हर release से डरता है।
- Continuous Integration और Continuous Delivery (CI/CD): Automated build, test, और deployment pipelines जो "हर दिन plan adapt करना" risky की बजाय safe बना देते हैं। Implementation guidance के लिए Continuous Integration देखें।
- Automated testing: Unit, integration, और end-to-end test suites जो टीम को धीमे manual regression passes पर depend करने की बजाय Definition of Done को जल्दी और बार-बार verify करने देते हैं। Agile Testing देखें।
- Pair और mob programming: दो या ज़्यादा Developers एक ही code piece पर एक साथ काम करते हैं, knowledge फैलाते हैं और solo-then-review workflow से पहले defects पकड़ते हैं।
- Code review: एक standing practice, afterthought नहीं - review criteria Definition of Done का हिस्सा होने चाहिए, कोई अलग, optional gate नहीं।
- Trunk-based development या short-lived branches: Merge conflict risk को घटाता है और Sprint भर Increment को release-ready के करीब रखता है, सिर्फ आखिर में नहीं।
- Ongoing work के रूप में refactoring: Small, continuous code-quality improvements जो regular Sprint Backlog items में fold किए जाते हैं, किसी rare "tech debt Sprint" के लिए deferred नहीं किए जाते।
मुख्य अंतर्दृष्टि: जो teams technical practices skip करती हैं, वे actually उन practices की cost avoid नहीं करतीं - वे उसे defer करती हैं। Manual regression testing, कम-frequent deployments, और skipped code review, ये सब बाद में धीमी delivery, ज़्यादा defects, या release से पहले एक unsustainable "hardening Sprint" के रूप में resurface होते हैं।
Developers के लिए Industry-Specific उदाहरण
Developers Definition of Done, technical practices, और quality bar को industry के अनुसार meaningfully कैसे apply करते हैं यह अलग-अलग होता है। ये checklists common contexts के लिए जोड़ने लायक standing practices दिखाती हैं।
SaaS / Cloud Product Teams
✓ Merge से पहले कम से कम एक peer द्वारा code review किया गया ✓ Automated unit और integration tests pass हो रहे हैं (target >75% coverage) ✓ Deployment से पहले CI/CD pipeline green चलता है ✓ Risky या incomplete functionality के लिए feature flags use होते हैं ✓ नई services के लिए uptime और monitoring alerts configure किए गए ✓ Production release से पहले staging पर deploy और smoke-tested
Healthcare Software Teams
✓ Protected Health Information (PHI) को touch करने वाले किसी भी code के लिए dual code review required ✓ HIPAA compliance checklist पूरी और sign-off हुई ✓ सभी PHI access और modification के लिए audit logging implement की गई ✓ At rest और in transit दोनों में PHI के लिए encryption verified ✓ Role-based access control tested, negative test cases सहित ✓ Security vulnerability scan pass हुआ, कोई high या critical findings नहीं
Financial Services Teams
✓ नए code के लिए PCI-DSS और SOC 2 control requirements verified ✓ सभी financial data flows के लिए encryption implemented ✓ Fraud-detection logic known false-positive/false-negative patterns के against tested ✓ Code change के साथ-साथ regulatory documentation updated ✓ Payment-adjacent functionality के लिए independent security review पूरी हुई ✓ Release से पहले rollback procedure tested और documented
E-commerce Teams
✓ Payment processing paths failure और retry scenarios के against tested ✓ Page load और checkout performance benchmarks पूरे हुए ✓ Cart और inventory logic concurrent-user conditions में tested ✓ Seasonal traffic events से पहले peak-load readiness verified ✓ Checkout flow की accessibility validated ✓ Post-deployment analytics और conversion tracking working confirmed
Mobile App Teams
✓ Simulators पर ही नहीं, supported OS versions में real devices पर tested ✓ नए features के लिए battery और performance impact assessed ✓ Offline behavior और poor-connectivity handling verified ✓ Submission से पहले app store guideline compliance checked ✓ जहाँ features को identically behave करना चाहिए वहाँ iOS/Android parity confirmed ✓ नए release के लिए crash reporting और analytics instrumented
Enterprise / DevOps Teams
✓ Infrastructure-as-code changes application code के साथ-साथ reviewed ✓ Security scanning CI/CD pipeline में integrated, baद में manually नहीं run होता ✓ Rollback और disaster-recovery procedures tested, सिर्फ documented नहीं ✓ Configuration drift intended infrastructure state के against checked ✓ Cross-team dependencies merge से पहले communicated, बाद में नहीं ✓ नए infrastructure components को cover करने के लिए monitoring और alerting updated
Government / Public Sector Teams
✓ सभी UI changes के लिए Section 508 / WCAG 2.1 AA accessibility validated ✓ FISMA या equivalent security control requirements checked ✓ नए data flows के लिए public records और data retention obligations reviewed ✓ Definition of Done में procurement और compliance constraints accounted for ✓ Citizen-facing features के लिए plain-language content review पूरी हुई ✓ Public transparency requirements के लिए change sufficiently documented
EdTech Teams
✓ Student data को touch करने वाले किसी भी feature के लिए FERPA और COPPA compliance verified ✓ Sprint के UI changes के लिए accessibility tested, screen-reader support सहित ✓ जहाँ technically feasible हो वहाँ student data anonymized या minimized ✓ सिर्फ technical correctness नहीं, pedagogical impact भी consider किया गया ✓ जहाँ applicable हो वहाँ parental या institutional consent flows tested ✓ Data privacy safeguards Definition of Done में built-in, launch के बाद add नहीं किए गए
Developers Maturity Model
Self-manage करने, cross-functional रहने, और quality sustain करने की Developers की capability progressively बढ़ती है। यह model use करें ताकि यह realistic expectations set हो सकें कि टीम कहाँ है और आगे किसमें invest करना है।
Stage 1: Basic / Forming (Sprints 1-6)
Timeline: एक नई बनी Developers group की पहली 6 Sprints
विशेषताएं:
- Manual testing और ad hoc code review पर heavy reliance
- Definition of Done मौजूद है लेकिन minimal है, और pressure में कभी-कभी skip हो जाती है
- Task assignment में अभी भी external direction के traces दिखते हैं (एक lead काम "बांट" रहा हो)
- Cross-functionality limited है - ज़्यादातर काम उसी specialist के पास जाता है जो उस area का "owner" है
इस stage का focus:
- एक initial Definition of Done लिखें, चाहे छोटी ही हो, और बिना किसी exception के इस पर टिके रहें
- Basic working agreements स्थापित करें (ऊपर देखें)
- हर Sprint में कुछ tasks के subset पर specialists को generalists के साथ pair करना शुरू करें
- Assign किए जाने की बजाय Sprint Planning के दौरान काम को self-select करने की practice करें
Stage 2: Intermediate (Sprints 7-15)
Timeline: Sprint 7 से लगभग 15 तक
विशेषताएं:
- Automated test coverage बढ़ रहा है (आमतौर पर 50-70%)
- एक working CI/CD pipeline मौजूद है, भले ही end to end पूरी तरह automated न हो
- Code review consistent है और एक shared checklist use करता है
- टीम के पास एक written, revisited Definition of Done है
इस stage का focus:
- Automated test coverage बढ़ाएं और manual regression passes पर reliance घटाएं
- Recurring tasks (deployment, on-call, review) की ownership टीम के ज़्यादा हिस्से में rotate करें
- Critical skills के लिए "bus factor" track करना शुरू करें और single points of failure actively घटाएं
- Sprint Retrospective को सिर्फ morale discuss करने के लिए नहीं, working agreements revise करने के लिए explicitly use करें
Stage 3: Advanced / High-Performing (Sprints 16-30)
Timeline: Sprint 16 से लगभग 30 तक
विशेषताएं:
- Comprehensive test automation (आमतौर पर >80% coverage), integration और end-to-end suites सहित
- Fully automated CI/CD, staged, low-risk deployments के साथ
- Genuine cross-functionality - ज़्यादातर Sprint Backlog items एक से ज़्यादा Developer उठा सकते हैं
- टीम बाहरी intervention के बिना ज़्यादातर technical और interpersonal issues resolve करती है
इस stage का focus:
- Standard Definition of Done में performance, security, और accessibility testing जोड़ें
- Organization के भीतर नए Developers या नई teams को mentor करें
- Technical debt को visible, prioritized backlog items के रूप में actively manage करें, deferred work नहीं
- Ambiguous problems लें जिनमें सिर्फ execution नहीं, judgment चाहिए
Stage 4: Expert (Sprint 31+)
Timeline: Sprint 31 से आगे
विशेषताएं:
- टीम बिना prompting के routinely अपनी engineering practices improve करती है
- Technical practices और working agreements को living, versioned artifacts की तरह treat किया जाता है
- Developers group दूसरी teams को reusable tools, patterns, या playbooks contribute करती है
- Peer accountability पूरी तरह internalize हो चुकी है - conflicts और quality lapses directly और जल्दी address होते हैं
इस stage का focus:
- Wider organization को engineering practices और Definition of Done templates contribute करें
- Multiple teams में onboarding और mentoring में active role लें
- समय-समय पर fundamentals पर वापस जाएं - expert teams को भी working agreements re-examine करने से फायदा होता है
- जैसे-जैसे organization बढ़े, Advanced Strategies में दिए गए scaling decisions को support करें
सामान्य Developers गलतियां
गलती 1: टीम के बाहर से Individuals को Sprint Backlog Items Assign करना
Problem: एक manager, team lead, या यहाँ तक कि Product Owner Sprint Planning के दौरान या उससे पहले specific Developers को specific tasks assign कर देता है।
यह Problematic क्यों है: यह self-management को directly violate करता है - कौन क्या करेगा और कब, यह किसी बाहरी role की बजाय Developers तय करते हैं।
Fix: Developers को skill, capacity, और interest के आधार पर Sprint Planning के दौरान खुद काम self-select करने दें।
Prevention: Self-selection को एक explicit, stated working agreement बनाएं, और अगर बाहरी assignment बार-बार हो तो Scrum Master को intervene करने दें।
गलती 2: Self-Managing को No Accountability समझ लेना
Problem: टीम "कोई हमें direct नहीं करता" को "कोई हमारे decisions पर सवाल नहीं उठा सकता" समझ लेती है, और बिना pushback के quality या commitments फिसल जाते हैं।
यह Problematic क्यों है: Self-managing external management की जगह internal accountability लाता है - यह accountability को पूरी तरह हटाता नहीं है।
Fix: Sprint Retrospective में peer accountability को explicitly reinforce करें; missed commitments को एक taboo नहीं, एक standing discussion topic बनाएं।
Prevention: ऐसे working agreements बनाएं जो यह बताएं कि जब कोई commitment miss होती है तो क्या होता है, टीम की खुद की सहमति से।
गलती 3: कागज़ पर "Cross-Functional" होने के बावजूद Silos बनाना
Problem: केवल एक व्यक्ति ही किसी given component को safely touch कर सकता है, भले ही टीम के पास nominally सारे ज़रूरी skills हों।
यह Problematic क्यों है: एक single point of failure cross-functionality के purpose को defeat कर देता है - टीम सिर्फ नाम में cross-functional है।
Fix: जब तक bus factor न improve हो, तब तक किसी skill area के sole owner को relevant tasks पर किसी और के साथ deliberately pair करें।
Prevention: हर critical skill area के लिए bus factor को planning या retrospectives में एक standing item की तरह track करें।
गलती 4: Deadline Pressure में Definition of Done को झुकाना
Problem: Release date hit करने के लिए टीम agreed-upon quality steps (testing, review, documentation) skip कर देती है।
यह Problematic क्यों है: इस तरह incurred quality debt शायद ही कभी वापस पूरी होती है - यह accumulate होती है और हर future Sprint को धीमा करती है।
Fix: Definition of Done को non-negotiable मानें; अगर उसके भीतर Sprint Backlog पूरा नहीं हो सकता, तो quality की बजाय scope घटाएं।
Prevention: Definition of Done को visible रखें और Sprint Review और Retrospective के दौरान adherence को explicitly review करें।
गलती 5: Splitting की बजाय टीम को नौ Developers से आगे बढ़ाना
Problem: Capacity जोड़ने के लिए, दूसरी Scrum Team बनाने की बजाय, एक Developers group 12-15 लोगों तक balloon हो जाती है।
यह Problematic क्यों है: लगभग नौ लोगों से आगे जाने पर coordination overhead output से तेज़ी से बढ़ता है, और Scrum events अपने timeboxes के against strain करने लगते हैं।
Fix: Scaling Scrum जैसी practices के जरिए coordinated, एक Product Backlog share करने वाली दो Scrum Teams में split करें।
Prevention: नौ Developers को एक soft ceiling मानें और टीम के size का दर्द महसूस करने से पहले ही split की planning करें।
गलती 6: Titles और Informal Hierarchy को वापस आने देना
Problem: एक "senior" या "lead" Developer एक informal manager की तरह दूसरों के दिन-प्रतिदिन के tasks direct करना शुरू कर देता है।
यह Problematic क्यों है: Scrum Guide स्पष्ट है कि Developers के भीतर कोई hierarchy नहीं है - इसे फिर से लाना self-management और peer accountability दोनों को कमजोर करता है।
Fix: Technical leadership को task assignment या approval authority की बजाय mentoring और influence की ओर redirect करें।
Prevention: नए Developers और नए leads दोनों के लिए "कोई internal hierarchy नहीं" को एक explicit onboarding topic बनाएं।
गलती 7: Testing और Design को External Services की तरह Treat करना
Problem: Testers या designers Developers group के बाहर बैठते हैं और Sprint में खुद participate करने की बजाय hand-offs के रूप में काम receive करते हैं।
यह Problematic क्यों है: यह हर Sprint के अंदर एक mini-waterfall फिर से बना देता है और "हर Sprint में usable Increment" के commitment को तोड़ता है।
Fix: Testing और design skills को Sprint Planning से ही पूरी तरह Developers group के अंदर लाएं।
Prevention: टीम बनाते या restaff करते समय, convenient organizational reporting lines की बजाय product को चाहिए वाले skills को प्राथमिकता दें।
गलती 8: "तेज़ी से Move" करने के लिए Technical Practices Skip करना
Problem: Short-term deadlines hit करने के लिए टीम automated testing, CI/CD, या code review skip कर देती है।
यह Problematic क्यों है: यह एक छोटा, visible short-term speed gain, defects और धीमी future delivery में एक कहीं बड़ी, hidden long-term cost से trade करता है।
Fix: Technical practices को Definition of Done के हिस्से के रूप में invest करें, optional extras के रूप में नहीं।
Prevention: Skipped practices की cost visible बनाने के लिए समय के साथ defect escape rate और deployment frequency track करें।
गलती 9: कोई Working Agreements न होना, या ऐसे Agreements जिन्हें कोई Follow नहीं करता
Problem: टीम के पास कोई explicit norms नहीं हैं, या ऐसे norms हैं जो एक बार लिखे गए और कभी दोबारा reference नहीं हुए।
यह Problematic क्यों है: Shared, followed norms के बिना, peer accountability के पास किसी को hold करने के लिए कुछ concrete नहीं होता।
Fix: Collaboratively working agreements का एक छोटा, specific set draft करें और नियमित रूप से इन्हें revisit करें (ऊपर देखें)।
Prevention: हर कुछ Sprints में working agreement review को एक standing Sprint Retrospective agenda item बनाएं।
गलती 10: Cost बचाने के लिए टीम को Understaff करना
Problem: एक या दो Developers की टीम से product को चाहिए वाले पूरे skills range cover करने की उम्मीद की जाती है।
यह Problematic क्यों है: न्यूनतम redundancy का मतलब है कि कोई भी absence, illness, या departure तुरंत delivery risk बन जाता है, और genuine cross-functionality असंभव हो जाती है।
Fix: Scrum Guide की recommended range की ओर staff करें, product को genuinely चाहिए वाले specific skills को प्राथमिकता देते हुए।
Prevention: "कम से कम 3 Developers" को viability के लिए एक starting point मानें, किसी aspirational target की तरह नहीं जिसे धीरे-धीरे grow करना है।
एक मजबूत Developers Group कैसे बनाएं और Grow करें
एक मजबूत Developers group बनाना एक deliberate, staged process है, न कि कुछ ऐसा जो लोगों को एक टीम में assign कर देने भर से automatically हो जाए।
Step 1: Product को चाहिए वाले Skills के लिए Staff करें (Weeks 1-2)
- इस specific product के लिए एक usable Increment deliver करने के लिए ज़रूरी skills map करें
- किसी specific headcount को hit करने से ज़्यादा gaps cover करने को प्राथमिकता दें
- Organizational convenience नहीं, product scope के आधार पर 3-9 Developers का लक्ष्य रखें
Step 2: Foundational Agreements स्थापित करें (Sprints 1-3)
- एक initial Definition of Done collaboratively draft करें
- Availability, communication, और code review cover करने वाले basic working agreements बनाएं
- यह explicitly स्पष्ट करें कि task assignment टीम के अंदर होता है, बाहर से नहीं
Step 3: Technical Foundations बनाएं (Sprints 1-10)
- CI/CD को जितनी जल्दी हो सके खड़ा करें, भले ही minimal form में हो
- Automated testing को एक साथ नहीं, incrementally introduce करें
- एक shared checklist के साथ एक consistent code review practice स्थापित करें
Step 4: Cross-Functionality को Deliberately Grow करें (Sprints 5-20)
- Specialists को generalists के साथ rotating basis पर pair करें
- हर skill area के लिए bus factor track करें और concentration risk directly address करें
- Recurring operational tasks (deployment, on-call, review) की ownership rotate करें
Step 5: Accountability और Self-Management को Mature करें (ongoing)
- Working agreements review और refine करने के लिए Sprint Retrospective use करें
- टीम को बिना escalation के conflicts और quality lapses directly resolve करने की ओर coach करें
- जैसे-जैसे टीम mature होती है, day-to-day facilitation में Scrum Master की involvement धीरे-धीरे घटाएं
💡
एक मजबूत Developers group बनाना कोई one-time setup task नहीं है - यह वही inspect-and-adapt cycle है जो Scrum प्रोडक्ट पर apply करता है, सिर्फ इस बार टीम पर खुद apply किया गया।
Developers Team की प्रभावशीलता मापना
एक Developers group की health आंशिक रूप से intangible होती है (trust, collaboration quality), लेकिन कई concrete signals यह बताते हैं कि self-management और cross-functionality practice में actually काम कर रहे हैं, सिर्फ एक team charter में declared नहीं।
| Metric | यह क्या Indicate करता है |
|---|---|
| Definition of Done adherence rate | "Done" काम कितनी बार genuinely हर agreed criterion को meet करता है बनाम pressure में चुपचाप steps skip करता है |
| हर skill area के लिए Bus factor | अगर एक व्यक्ति unavailable हो तो कितने Developers एक critical skill cover कर सकते हैं - real cross-functionality का एक direct read |
| Cycle time और velocity stability | Working agreements और technical practices mature होने के साथ Sprint-to-Sprint swings घटते हैं या नहीं |
| Defect escape rate | क्या quality practices (testing, review, Definition of Done) release से पहले issues पकड़ रही हैं |
| Deployment frequency | टीम कितनी बार safely ship करती है, यह एक proxy है कि CI/CD और automated testing रोज़ाना adaptation को कितना अच्छे से support करते हैं |
| Working agreement adherence | क्या टीम के खुद के stated norms actually follow हो रहे हैं, Sprint Retrospective के दौरान periodically check किया गया |
| Task self-selection rate | Developers कितनी बार Sprint Planning के दौरान खुद काम उठाते हैं बनाम इसे टीम के बाहर किसी से assign होते देखते हैं |
💡
मुख्य अंतर्दृष्टि: Bus factor और task self-selection rate दो ऐसे metrics हैं जो सबसे कम track किए जाते हैं लेकिन सबसे ज़्यादा revealing होते हैं। एक टीम हर velocity target hit कर सकती है जबकि चुपचाप किसी critical skill के लिए एक व्यक्ति पर depend कर रही हो, या जबकि एक team lead अभी भी informally काम assign कर रहा हो - दोनों metrics बिल्कुल वे risks expose करते हैं जिन्हें raw throughput numbers छुपा देते हैं।
किसी single data point पर react करने की बजाय इन metrics को कई Sprints में track करें - उदाहरण के लिए, अपनी Definition of Done को refine कर रही टीम में अक्सर cycle time तेज़, ज़्यादा sustainable pace पर stabilize होने से पहले throughput में एक temporary dip दिखता है।
Advanced रणनीतियां और Scaling विचार
जैसे-जैसे products और organizations बढ़ते हैं, एक single Developers group अंततः अकेले ज़रूरी scope cover नहीं कर सकती। कई strategies Scrum की core accountabilities को छोड़े बिना इसकी structure को extend करती हैं।
जब एक टीम काफी नहीं है:
- जब एक single Developers group otherwise लगभग नौ लोगों से आगे बढ़ जाए, तो एक Product Backlog और एक Product Owner (या एक Product Owner team) share करने वाली multiple Scrum Teams में split करें
- Shared dependencies को एक Scrum of Scrums के जरिए coordinate करें, जहाँ हर टीम के representative Developers cross-team blockers surface करते हैं
- हर individual Developers group की internal self-management को intact रखें - scaling frameworks teams के बीच coordinate करते हैं, उन्हें एक टीम के अंदर decisions को re-centralize नहीं करना चाहिए
Multiple Teams के लिए Framework-Level Options:
- Nexus: Scrum पर सीधे बना एक lightweight framework, जो cross-team dependencies identify और resolve करने और लगभग 3-9 Scrum Teams में एक single, integrated Increment सुनिश्चित करने के लिए accountable एक Nexus Integration Team जोड़ता है।
- LeSS (Large-Scale Scrum): Scrum की structure को multiple teams तक extend करता है जो एक Product Backlog, एक Sprint, और एक Definition of Done share करती हैं, single-team Scrum में पहले से मौजूद चीज़ों से आगे additional roles या ceremonies को deliberately minimize करते हुए।
- Scrum of Scrums: सबसे simple scaling mechanism - हर टीम के representatives नियमित रूप से मिलते हैं ताकि बिना कोई नई framework layer introduce किए dependencies coordinate की जा सकें।
Practical Scaling Guidance:
- एक ही product पर काम करने वाली teams में Definition of Done को consistent रखने को प्राथमिकता दें
- Team dynamics के issues को multiple teams में compound होने से पहले team level पर address करें
- Distributed या globally spread Developers groups के लिए, distributed teams पर dedicated guidance review करें
- Coordination overhead (extra meetings, extra reporting layers) actually ज़रूरत से तेज़ी से न जोड़ें - अधिकतम उपलब्ध structure नहीं, न्यूनतम ज़रूरी structure scale करें
Conclusion
Developers Scrum Team के अंदर वह accountability हैं जो बिना किसी बाहरी direction के कि कौन क्या करेगा या कैसे, हर Sprint में एक Product Backlog को genuinely usable Increment में बदलने के लिए जिम्मेदार हैं। "Development Team" से "Developers" तक का 2020 rename एक deliberate correction था: एक ही Scrum Team है, कोई Product Owner और Scrum Master एक अलग delivery team के ऊपर खड़े नहीं हैं।
आपके अगले तीन actions:
- Check करें कि क्या आपकी Developers group का size 3-9 range में है - अगर यह नौ से आगे बढ़ गया है, तो coordination cost absorb करने की बजाय एक split की planning करें
- Audit करें कि क्या task assignment genuinely टीम के अंदर होता है, या क्या कोई बाहरी role चुपचाप अभी भी काम assign कर रहा है
- अगली Sprint Retrospective में अपनी Definition of Done revisit करें और confirm करें कि टीम deadline pressure में भी इसे actually follow करती है, सिर्फ कागज़ पर नहीं
Cross-functionality, self-management, और peer accountability एक बार achieve करके automatically maintain नहीं होतीं - वे उसी तरह बनती हैं जैसे प्रोडक्ट बनता है: iteratively, Sprint दर Sprint, honest inspection और deliberate adaptation के जरिए।
प्रश्नोत्तरी: Developers
आपका स्कोर: 0/15
प्रश्न: Scrum Guide 2020 ने "Development Team" की जगह कौन-सा term use किया?
अक्सर पूछे जाने वाले प्रश्न (FAQs)
एक Scrum Developers group traditional waterfall development team से कैसे अलग है?
Structure और roles के मामले में एक Scrum Developers group एक Kanban team से कैसे compare होता है?
जब कोई टीम self-managing की ओर transition करती है तो कौन-से psychological और change-management challenges सामने आते हैं?
क्या ideal Developers team size organization के size या maturity के आधार पर बदलती है?
Developers अपनी Scrum accountabilities को dilute किए बिना DevOps practices को कैसे integrate करें?
Developers groups कैसे structure की जाती हैं, इसे सबसे ज़्यादा कौन-से compliance और regulatory considerations affect करते हैं?
Distributed या globally spread Developers groups को effective self-management maintain करने के लिए कौन-सी practices मदद करती हैं?
एक directed, specialist-siloed structure की बजाय self-managing, cross-functional Developers में invest करने का ROI case क्या है?
Organizations self-management को कमजोर किए बिना diverse, equitable Developers groups कैसे बना सकती हैं?
Developers की quality accountability के हिस्से के रूप में कौन-सी cybersecurity responsibilities उनके पास आती हैं?
Developers को day-to-day business-as-usual delivery work के against innovation और experimentation को कैसे balance करना चाहिए?
Developers को अपनी standard practices में कौन-से data privacy considerations build करने चाहिए?
जैसे-जैसे एक Developers group नई बनी टीम से एक high-performing टीम तक mature होती है, self-management का concept कैसे evolve होता है?
SaaS, healthcare, और government जैसी industries में Developers की भूमिका और उनकी Definition of Done कैसे अलग होती है?
एक self-managing Developers group के members के लिए performance management और appraisals कैसे काम करने चाहिए?
आगे पढ़ें
Scrum Masterसमझें कि Scrum Master एक facilitator और coach के रूप में Developers group को कैसे serve करता है, टीम के काम को direct करने की बजाय self-management को promote करते हुए।
Product Ownerजानें कि Product Owner product value को कैसे अधिकतम करता है और Developers को यह direct किए बिना collaborate करता है कि वे अपना काम कैसे organize करें।
Sprint Backlogदेखें कि Developers Sprint Backlog कैसे बनाते और लगातार update करते हैं, वह plan जिसे वे हर Sprint Goal को achieve करने के लिए own करते हैं।
Scrum में Product Incrementउस Increment को explore करें जिसके लिए Developers हर Sprint में accountable हैं, और Definition of Done यह कैसे तय करती है कि यह genuinely usable कब है।
Daily Scrumजानें कि Developers Daily Scrum का उपयोग progress inspect करने और हर दिन Sprint Goal की ओर अपनी Sprint Backlog adapt करने के लिए कैसे करते हैं।
Sprint Retrospectiveजानें कि Developers working agreements refine करने और पेशेवरों के रूप में एक-दूसरे को accountable रखने के लिए Sprint Retrospective का उपयोग कैसे करते हैं।
Scrum में Self-Organizationउन self-organization और self-management principles में गहराई से जाएं जो यह define करते हैं कि Developers कौन क्या करेगा, कब, और कैसे तय करते हैं।
Scrum में Team Dynamicsउन interpersonal और collaboration challenges को address करें जो यह तय करते हैं कि Developers group truly एक self-managing team की तरह function करता है या नहीं।