विषय 7.1 — चुस्त डिलीवरी प्रथाएं और टीम स्वास्थ्य

एक वाक्य में: एक डिलीवरी टीम वास्तव में हफ़्ते-दर-हफ़्ते कैसे काम करती है — इसकी गति, इसके समारोह, इसके काम करने के समझौते, और सबसे बढ़कर इसका स्वास्थ्य — नरम-कौशल सजावट नहीं है बल्कि वह परिचालन प्रणाली है जो निर्धारित करती है कि क्या सुरक्षित, उपयोग योग्य डिजिटल देखभाल दी और बनाए रखी जाती है।

यह स्वास्थ्य और देखभाल में क्यों महत्वपूर्ण है#

विषय 7.0 — टीम संरचनाएं, भूमिकाएं, और जिम्मेदारियां ने आपकी टीमों के आसपास सीमाएं खींचीं और नाम दिया कि कौन क्या करता है। यह विषय इसके बारे में है कि काम शुरू होने पर उन सीमाओं के अंदर क्या होता है: एक पखवाड़े की लय, वे बैठकें जिनमें लोग वास्तव में भाग लेते हैं, व्यवहार को शासित करने वाले समझौते, और मानव स्थिरता जो टीम को भार के तहत कार्यशील रखती है। संरचना शरीर रचना है; काम करने के तरीके शरीर विज्ञान हैं।

स्वास्थ्य और देखभाल में यह अधिकांश क्षेत्रों की तुलना में अधिक मायने रखता है क्योंकि डिजिटल सेवाओं को बनाने और चलाने वाली टीमें अक्सर उन क्लिनिकल संचालनों का समर्थन करती हैं जो कभी नहीं रुकते। एक टीम जो एक इलेक्ट्रॉनिक रोगी रिकॉर्ड, एक e-प्रिस्क्राइबिंग सिस्टम, या एक बेड-प्रबंधन प्लेटफ़ॉर्म बनाए रखती है देखभाल डिलीवरी के क्रिटिकल पथ पर है। जब वह टीम थकी हुई, मौन, या अनियोजित काम में डूबी हुई है, विफलता मोड एक चूकी हुई मार्केटिंग समयसीमा नहीं है — यह एक देरी वाला निदान, एक दवा त्रुटि, या एक सुरक्षा घटना है जिसे एक आराम की, मनोवैज्ञानिक रूप से सुरक्षित टीम ने पकड़ और फ्लैग किया होता।

मज़बूत साक्ष्य है कि टीम जलवायु क्लिनिकल परिणामों को प्रभावित करती है। रोगी सुरक्षा में अनुसंधान लगातार स्टाफ की जोखिम के बारे में बोलने की क्षमता को नुकसान की रोकथाम से जोड़ता है, और NHS विफलताओं की समीक्षाएं — Mid Staffordshire से आगे — बार-बार ऐसी संस्कृतियां पाती हैं जहां चिंताओं को आवाज़ नहीं दी गई या सुना नहीं गया। आपकी डिलीवरी टीम अपने स्टैंड-अप और रेट्रोस्पेक्टिव कैसे चलाती है वही प्रश्न का एक छोटे-पैमाने का संस्करण है: क्या लोग बिना डर के "यह सुरक्षित नहीं है" कह सकते हैं? आप कैसे काम करते हैं यह एक क्लिनिकल-सुरक्षा और सार्वजनिक-विश्वास मुद्दा है, केवल एक उत्पादकता मुद्दा नहीं।

मुख्य अवधारणाएं#

चुस्त सॉफ़्टवेयर विकास। दृष्टिकोणों का एक परिवार, 2001 Agile Manifesto में संहिताबद्ध, जो थकाऊ अग्रिम योजना पर काम करने वाले सॉफ़्टवेयर, उपयोगकर्ताओं के साथ निकट सहयोग, और परिवर्तन के प्रति प्रतिक्रिया को पसंद करता है। स्वास्थ्य और देखभाल में, चुस्त प्रशासन छोड़ने का लाइसेंस नहीं है — यह क्लिनिकल-सुरक्षा और सूचना-प्रशासन प्रश्नों को अंत में नहीं, जल्दी और अक्सर सतह पर लाने का एक तरीका है। चुस्तता सुरक्षित, मूल्यवान डिलीवरी का एक साधन है, स्वयं में एक अंत नहीं।

पुनरावृत्त और वृद्धिशील विकास। एक सेवा को छोटी वृद्धियों में बनाना, हर एक उपयोग योग्य और हर एक फीडबैक उत्पन्न करती है जो अगले को आकार देती है। यह सभी चुस्त विधियों के नीचे मूल तंत्र है: आप पतली स्लाइस शिप करके और वास्तविक उपयोग देखकर सीखते हैं, बजाय अग्रिम में सब कुछ भविष्यवाणी करने के।

Scrum। सबसे व्यापक रूप से अपनाया गया चुस्त ढांचा, काम को निश्चित-लंबाई के पुनरावृत्तियों में व्यवस्थित करता है जिन्हें स्प्रिंट कहा जाता है (आमतौर पर एक से दो सप्ताह), हर एक शुरुआत में योजना और अंत में एक समीक्षा और रेट्रोस्पेक्टिव से घिरा हुआ, समन्वय के लिए एक दैनिक stand-up meeting के साथ। Scrum का मूल्य इसकी अनुमानित गति और इसका अंतर्निहित निरीक्षण-और-अनुकूलन लूप है; इसका जोखिम अंतर्निहित पारदर्शिता के बिना समारोह के रूप में अपनाया जाना है।

Kanban। एक निरंतर-प्रवाह विधि जो एक बोर्ड पर काम को दृश्यमान बनाती है, हर चरण पर प्रगति में काम (WIP) की मात्रा को सीमित करती है, और समय-सीमित बैचों के बजाय प्रवाह प्रबंधित करती है। Kanban उन टीमों के अनुरूप है जो परिचालन और समर्थन काम करती हैं जहां मांग अप्रत्याशित है — स्वास्थ्य और देखभाल के अधिकांश लाइव-सेवा काम — क्योंकि यह अनियमित आगमनों को कृत्रिम स्प्रिंट सीमाओं में मजबूर नहीं करता। WIP सीमाएं इसका हस्ताक्षर अनुशासन हैं: एक टीम जो एक बार में, कहते हैं, तीन से अधिक आइटमों पर काम न करने पर सहमत होती है उस टीम से चीज़ें तेज़ी से समाप्त करती है जो सब कुछ शुरू करती है और कुछ भी पूरा नहीं करती।

तैयार की परिभाषा और पूर्ण की परिभाषा। दो साझा समझौते जो गुणवत्ता को बाधित करते हैं। एक तैयार की परिभाषा उन शर्तों को बताती है जिन्हें काम के एक टुकड़े को टीम के शुरू करने से पहले पूरा करना चाहिए (स्पष्ट उपयोगकर्ता आवश्यकता, स्वीकृति मानदंड, कोई भी पहचानी गई क्लिनिकल-सुरक्षा या सुगमता विचार)। एक पूर्ण की परिभाषा बताती है कि "पूर्ण" का क्या अर्थ है (परीक्षित, सुलभ, दस्तावेज़ीकृत, सुरक्षा प्रभाव मूल्यांकित, तैनात)। स्वास्थ्य और देखभाल में, पूर्ण की परिभाषा वह जगह है जहां आप गैर-परक्राम्य को हार्ड-वायर करते हैं — DCB0129/DCB0160 क्लिनिकल-जोखिम गतिविधियां, WCAG 2.2 के प्रति सुगमता, सूचना-प्रशासन साइन-ऑफ — ताकि उन्हें समयसीमा दबाव के तहत चुपचाप छोड़ा न जा सके।

टीम काम करने का समझौता (या चार्टर)। एक छोटा, टीम-स्वामित्व वाला दस्तावेज़ जो बताता है कि टीम कैसे काम करना चुनती है: मुख्य घंटे, बैठक मानदंड, निर्णय कैसे लिए जाते हैं, असहमति कैसे संभाली जाती है, ऑन-कॉल कैसे साझा किया जाता है। यह अंतर्निहित धारणाओं को स्पष्ट, संशोधन योग्य समझौतों में बदलता है, जो बहु-विषयक टीमों में विशेष रूप से मूल्यवान है जहां क्लिनिशियन, इंजीनियर, और शोधकर्ता बहुत अलग पेशेवर मानदंडों के साथ आते हैं।

मनोवैज्ञानिक सुरक्षा। साझा विश्वास, Amy Edmondson द्वारा व्यापक रूप से अध्ययन किया गया, कि एक टीम पारस्परिक जोखिम-लेने के लिए सुरक्षित है — कि आप बिना दंडित या अपमानित हुए एक प्रश्न पूछ सकते हैं, एक गलती स्वीकार कर सकते हैं, या एक चिंता उठा सकते हैं। यह Google के प्रसिद्ध Project Aristotle अनुसंधान में प्रभावी टीमों का सबसे मज़बूत सहसंबंध है, और स्वास्थ्य सेवा में यह सीधे त्रुटि रिपोर्टिंग और सीखने से जुड़ा है। बिना इसके एक टीम समस्याओं को तब तक छुपाएगी जब तक वे घटनाएं न बन जाएं।

व्यावसायिक बर्नआउट। World Health Organization द्वारा मान्यता प्राप्त एक सिंड्रोम, पुराने अप्रबंधित कार्यस्थल तनाव से उत्पन्न, थकावट, निंदावाद, और कम प्रभावशीलता द्वारा विशेषता। टिकाऊ गति — चुस्त सिद्धांत कि एक टीम को अपनी लय को अनिश्चित काल तक बनाए रखने में सक्षम होना चाहिए — प्रतिकार है। सुरक्षा-महत्वपूर्ण क्लिनिकल सिस्टमों का समर्थन करने वाली टीमों के लिए, बर्नआउट एक सुरक्षा जोखिम है, क्योंकि 24/7 सेवाओं का समर्थन करने वाले थके हुए लोग त्रुटियां करते हैं।

निरंतर सुधार। साक्ष्य द्वारा सूचित, आप कैसे काम करते हैं में छोटे, नियमित परिवर्तन करने की अनुशासित आदत। टीम-स्तर की रेट्रोस्पेक्टिव इसका एक उदाहरण है; विषय 10.2 — गुणवत्ता सुधार और सुधार विज्ञान व्यापक विज्ञान को कवर करता है, Plan-Do-Study-Act चक्रों सहित, जो क्लिनिकल मार्गों जितना ही आपके काम करने के तरीकों पर लागू होते हैं।

सर्वोत्तम प्रथाएं#

1. फैशन के लिए नहीं, काम की प्रकृति से मिलाने के लिए गति चुनें। समय-सीमित स्प्रिंट (Scrum) का उपयोग करें जहां काम योजना योग्य है और आप एक अनुमानित धड़कन और हितधारक लय से लाभान्वित होते हैं; निरंतर प्रवाह WIP सीमाओं (Kanban) के साथ उपयोग करें जहां मांग अप्रत्याशित है, जैसे लाइव-सेवा समर्थन और परिचालन टीमों में। कई स्वास्थ्य और देखभाल टीमें दोनों करती हैं — एक "Scrumban" हाइब्रिड — स्प्रिंट में खोज और बिल्ड चलाना जबकि लाइव घटनाओं को एक प्रवाह बोर्ड पर संभालना। जानबूझकर निर्णय लें और निर्णय को फिर से देखें, बजाय जो भी आपके पिछले आपूर्तिकर्ता ने उपयोग किया उसे विरासत में लेने के।

2. समारोह उनके उद्देश्य के लिए चलाएं, और जब वे इसकी सेवा करना बंद कर दें तो उन्हें समाप्त करें। एक स्टैंड-अप बाधाओं को सतह पर लाने और दिन को समन्वित करने के लिए मौजूद है, एक प्रबंधक को स्थिति रिपोर्ट करने के लिए नहीं; एक समीक्षा या शो-एंड-टेल काम करने वाले सॉफ़्टवेयर पर वास्तविक उपयोगकर्ताओं और हितधारकों से फीडबैक प्राप्त करने के लिए मौजूद है; एक रेट्रोस्पेक्टिव अगले सप्ताह टीम के काम करने के तरीके को बदलने के लिए मौजूद है। यदि एक बैठक अब अपना उद्देश्य पूरा नहीं करती, इसे छोटा करें, इसे पुनर्संरचित करें, या इसे रोकें। परीक्षण सरल है: क्या उपस्थित लोग वहां होने के लिए भुगतान करेंगे?

3. शो-एंड-टेल को वह क्षण बनाएं जब क्लिनिशियन और उपयोगकर्ता वास्तविक प्रगति देखें। एक पखवाड़ी समीक्षा जो उन क्लिनिशियनों, रोगियों, और परिचालन स्टाफ को काम करने वाला सॉफ़्टवेयर प्रदर्शित करती है जो इसका उपयोग करेंगे फीडबैक लूप को तंग रखती है और उस विश्वास का निर्माण करती है जिस पर अपनाना निर्भर करता है। उन लोगों को आमंत्रित करें जो सेवा के साथ जीएंगे, यथार्थवादी (चयनित नहीं) परिदृश्यों पर प्रदर्शन करें, और जो आप सीखते हैं उसे बैकलॉग परिवर्तनों के रूप में कैप्चर करें। यह गलत चीज़ बनाने के खिलाफ आपका सबसे सस्ता बीमा है।

4. एक तैयार की परिभाषा और एक पूर्ण की परिभाषा लिखें, और गैर-परक्राम्य को पूर्ण में रखें। काम शुरू और समाप्त करने की शर्तों पर सहमत हों, और क्लिनिकल-सुरक्षा गतिविधि, सुगमता, सूचना-प्रशासन साइन-ऑफ, और पर्याप्त परीक्षण को अपनी पूर्ण की परिभाषा में एनकोड करें ताकि वे संरचनात्मक हों, वीरतापूर्ण नहीं। जब एक समयसीमा निचोड़ती है, एक स्पष्ट पूर्ण टीम को असुरक्षित काम शिप करने से इनकार करने की भाषा देता है। यह देखने के लिए कि निरंतर डिलीवरी पाइपलाइन पूर्ण के हिस्सों को कैसे स्वचालित कर सकती हैं विषय 3.6 — DevOps और इंजीनियरिंग उत्कृष्टता देखें।

5. प्रगति में काम को सीमित करें। शुरू करना आसान और संतोषजनक है; समाप्त करना वह है जो मूल्य देता है और जोखिम कम करता है। WIP सीमाओं पर सहमत होना टीम को अधिक खींचने से पहले काम पूरा करने पर झुंड बनाने के लिए मजबूर करता है, जो लीड टाइम को छोटा करता है, बाधाओं को उजागर करता है, और — स्वास्थ्य में महत्वपूर्ण रूप से — एक बार में उड़ान में आधे-पूर्ण, आंशिक रूप से परीक्षित परिवर्तनों की संख्या को कम करता है। स्पष्ट सीमाओं वाला एक दृश्यमान बोर्ड अक्सर एक संघर्षरत टीम द्वारा किया जा सकने वाला सबसे उच्च-लाभ वाला एकल परिवर्तन है।

6. एक साथ एक काम करने का समझौता लिखें और इसे जीवित मानें। टीम को अपना खुद का चार्टर लिखने दें — बैठक मानदंड, मुख्य सहयोग घंटे, निर्णय-निर्माण, ऑन-कॉल निष्पक्षता, अच्छी तरह से असहमत होने का तरीका — और इसे समय-समय पर समीक्षा करें। क्योंकि डिजिटल स्वास्थ्य टीमें बहु-विषयक हैं, विभिन्न डिफ़ॉल्ट के साथ क्लिनिकल और तकनीकी संस्कृतियों में फैली हुई हैं, मानदंडों को स्पष्ट बनाना उस मौन घर्षण को रोकता है जो विश्वास को क्षय करता है। ऊपर से थोपा गया एक चार्टर थिएटर है; एक जिसका टीम मालिक है एक वास्तविक उपकरण है।

7. जानबूझकर टिकाऊ गति की रक्षा करें, और बर्नआउट के अग्रणी संकेतकों को देखें। उस क्षमता की योजना बनाएं जिसे टीम अनिश्चित काल तक बनाए रख सके, एक वीरतापूर्ण चरम नहीं; उस स्थायी क्रंच से रक्षा करें जो ओवरटाइम को सामान्य मानता है। अग्रणी संकेतों की निगरानी करें — बढ़ता अनियोजित काम, सिकुड़ती रेट्रोस्पेक्टिव स्पष्टता, छुट्टी छोड़ते लोग, ऑन-कॉल थकान — और इनके इस्तीफे या घटनाएं बनने से पहले कार्य करें। 24/7 क्लिनिकल सेवाओं को आधार देने वाली टीमों के लिए, ऑन-कॉल निष्पक्ष रूप से साझा करें, वापस समय का सम्मान करें, और केवल खुशहाल पथ के लिए नहीं, लचीलेपन के लिए स्टाफ करें (विषय 3.8 — सेवा प्रबंधन और लाइव संचालन देखें)।

8. मनोवैज्ञानिक सुरक्षा को उद्देश्यपूर्ण रूप से बनाएं। नेता टोन निर्धारित करते हैं: काम को एक सीखने की समस्या के रूप में फ्रेम करें, अपनी खुद की गलतियां स्वीकार करें, बुरी खबर पर दोष के बजाय जिज्ञासा के साथ प्रतिक्रिया दें, और चिंताएं उठाने के लिए लोगों को धन्यवाद दें। दोष-मुक्त घटना-बाद समीक्षाएं चलाएं। एक क्लिनिकल-निकटवर्ती सेटिंग में, "मुझे लगता है कि यह रिलीज़ असुरक्षित है" या "मुझे यह आवश्यकता समझ में नहीं आती" कहने की इच्छा वह तंत्र है जिसके द्वारा नुकसान को रोका जाता है — इसलिए इसे सक्रिय रूप से विकसित किया जाना चाहिए, माना नहीं जाना चाहिए।

9. अदृश्य को दृश्यमान बनाने के लिए हल्के टीम-स्वास्थ्य जांच का उपयोग करें। समय-समय पर एक संरचित स्व-मूल्यांकन चलाएं — Spotify द्वारा लोकप्रिय "स्क्वाड स्वास्थ्य जांच" मॉडल, जहां एक टीम मूल्य देने, सीखने, मज़ा, मिशन स्पष्टता, और समर्थन जैसे आयामों में खुद को हरा/एम्बर/लाल रेट करती है — समय के साथ रुझानों को सतह पर लाने के लिए। मूल्य स्कोर नहीं बल्कि वह बातचीत है जिसे वे शुरू करते हैं और जिस तरह वे एक टीम को इसके एक संकट बनने से पहले एक फिसलन पहचानने देते हैं। इसे तेज़, जहां सहायक हो अनाम, और टीम के स्वामित्व में रखें।

10. रेट्रोस्पेक्टिव चलाएं जो वास्तव में व्यवहार बदलती हैं। एक रेट्रोस्पेक्टिव जो शिकायतों की एक सूची और कोई कार्रवाई नहीं उत्पन्न करती किसी से भी बदतर है, क्योंकि यह टीम को सिखाती है कि बोलना बेकार है। हर एक को कुछ ठोस, स्वामित्व वाले, समय-सीमित प्रयोगों के साथ समाप्त करें; अगले को यह जांच कर शुरू करें कि क्या पिछले हुए। अपने काम करने के तरीकों को सुधारने को अपना खुद का निरंतर-सुधार बैकलॉग मानें, विषय 10.2 में सुधार विज्ञान से जोड़ते हुए।

11. दूरस्थ, हाइब्रिड, और अतुल्यकालिक सहयोग को डिफ़ॉल्ट के रूप में डिज़ाइन करें। स्वास्थ्य और देखभाल डिलीवरी टीमें अक्सर ट्रस्टों, क्षेत्रों, और आपूर्तिकर्ताओं में वितरित होती हैं, इसलिए अच्छे लिखित संचार, अच्छी तरह से चलाए गए वीडियो समारोहों, और अतुल्यकालिक निर्णय रिकॉर्ड को मुख्य क्षमताएं मानें, फ़ॉलबैक नहीं। निर्णयों को दस्तावेज़ीकृत करने के लिए डिफ़ॉल्ट करें जहां अनुपस्थित सहयोगी उन्हें पा सकें, उन बैठकों को न्यूनतम करें जो एक लिखित अपडेट हो सकती थीं, और उन कुछ उच्च-बैंडविड्थ क्षणों (योजना, रेट्रो, घटना प्रतिक्रिया) के बारे में जानबूझकर रहें जो वास्तव में समकालिक होने से लाभान्वित होते हैं।

आपकी टीम के साथ चर्चा करने के लिए प्रश्न#

1. क्या हमारी गति और समारोहों का समूह वास्तव में हमें सुरक्षित रूप से देने में मदद करता है, या क्या हम चुस्त अनुष्ठान कर रहे हैं क्योंकि हमने हमेशा किया है? कई टीमें एक समारोह अनुसूची विरासत में लेती हैं — दैनिक स्टैंड-अप, दो-सप्ताह का स्प्रिंट, स्प्रिंट समीक्षा, रेट्रो — बिना यह पूछे कि क्या यह उनके सामने के काम के अनुरूप है, और परिणाम ऐसी बैठकें हैं जो वास्तविक घंटे खपत करती हैं जबकि घटता मूल्य देती हैं। ईमानदार बहस उद्देश्य के बारे में है: हर समारोह किसके लिए है, और क्या हमारे को देखने वाला एक तटस्थ पर्यवेक्षक निष्कर्ष निकालेगा कि यह इसे हासिल करता है? अप्रत्याशित क्लिनिकल घटनाओं को संभालने वाली एक लाइव-सेवा टीम कठोर स्प्रिंट द्वारा खराब सेवा दी जा सकती है और Kanban प्रवाह द्वारा बेहतर सेवा दी जा सकती है, जबकि एक खोज टीम स्प्रिंट की धड़कन और इसके द्वारा बनाई गई हितधारक लय से लाभान्वित होती है। एक परिचित दिनचर्या के आश्वासन और केवल उन कार्यक्रमों को चलाने के अनुशासन के बीच एक वास्तविक तनाव है जो अपनी जगह अर्जित करते हैं। एक महीने के लिए अपने समारोहों का समय निकालने और प्रति बैठक पूछने पर विचार करें कि इसने क्या निर्णय या समन्वय उत्पन्न किया। एक अच्छा उत्तर समारोहों को मारने या फिर से आकार देने के बारे में भावुकता-रहित है, समन्वय आवश्यकताओं को स्थिति-रिपोर्टिंग आदतों से अलग करता है, और गति के चुनाव को ढांचे के आरेख के बजाय आपके काम की वास्तविक अनुमानशीलता से जोड़ता है।

2. क्या इस टीम में "मुझे लगता है कि यह असुरक्षित है" या "मैंने एक गलती की" कहना वास्तव में सुरक्षित है — और हमें कैसे पता चलेगा? मनोवैज्ञानिक सुरक्षा का दावा करना आसान और रखना कठिन है, और क्लिनिकल सिस्टमों का समर्थन करने वाली एक टीम में इसे गलत करने की कीमत केवल चूकी हुई समयसीमाओं में नहीं बल्कि रोगी नुकसान में मापी जाती है। असुविधाजनक प्रश्न यह नहीं है कि क्या आप मानते हैं कि आपकी टीम सुरक्षित है बल्कि आपके पास क्या साक्ष्य है: आखिरी बार किसी ने एक स्टैंड-अप में एक त्रुटि कब स्वीकार की, एक वरिष्ठ व्यक्ति के डिज़ाइन को चुनौती दी, या एक पूर्वाभास पर एक रिलीज़ रोका, और बाद में उनके साथ क्या हुआ? अपनी घटना समीक्षाओं को देखें — क्या वे वास्तव में दोष-मुक्त हैं, या क्या हर कोई चुपचाप जानता है कि किसे जवाबदेह ठहराया जा रहा है? नेताओं को ईमानदारी से एक व्यापार का सामना करना चाहिए: वे व्यवहार जो निर्णायक नेतृत्व जैसे महसूस होते हैं (तेज़ी से आगे बढ़ना, निश्चितता प्रक्षेपित करना, बुरी खबर पर तीखी प्रतिक्रिया देना) अक्सर ठीक-ठीक वे हैं जो लोगों को चुप रहना सिखाते हैं। विचार करें कि क्या आपकी सबसे शांत टीम सदस्य कभी एक बैठक में असहमत होते हैं, और क्यों वे शायद नहीं करते। एक मज़बूत उत्तर आरामदायक धारणा का विरोध करता है कि "बेशक यहां लोग बोल सकते हैं", ठोस हालिया उदाहरणों की ओर इशारा करता है या उनकी अनुपस्थिति स्वीकार करता है, और समूह की एक निश्चित विशेषता के रूप में सुरक्षा को मानने के बजाय बदलने के लिए विशिष्ट नेता व्यवहारों की पहचान करता है।

3. क्या हम एक ऐसी गति से काम कर रहे हैं जिसे हम एक साल तक बनाए रख सकें — और हम उन संकेतों के बारे में क्या कर रहे हैं कि हम नहीं हैं? टिकाऊ गति चुस्त के संस्थापक सिद्धांतों में से एक है और दबाव में सबसे पहले छोड़ी जाने वाली चीज़ों में से एक, विशेष रूप से उन टीमों के लिए जिनके सिस्टम ऐसी सेवाओं को आधार देते हैं जो बंद नहीं हो सकतीं। तनाव यह है कि वीरता क्षण में दृश्यमान और पुरस्कृत होती है — जो व्यक्ति उत्पादन ठीक करने के लिए सप्ताहांत काम करता है उसे धन्यवाद दिया जाता है — जबकि एक टीम के स्वास्थ्य का धीमा क्षय तब तक अदृश्य है जब तक लोग नहीं छोड़ देते या गलतियां नहीं करते। पूछें कि आपके अग्रणी संकेतक क्या हैं: अनियोजित काम योजनाबद्ध काम को बाहर कर रहा है, न लिया गया वार्षिक अवकाश, ऑन-कॉल नींद को बाधित कर रहा है, रेट्रोस्पेक्टिव शांत हो रहे हैं, निंदावाद भाषा में रेंग रहा है। एक सुरक्षा-महत्वपूर्ण संदर्भ में, एक थकी हुई टीम केवल दुखी नहीं है; इसके उस दोष को चूकने या उस अलर्ट को गलत पढ़ने की संभावना अधिक है जो नुकसान रोकता है, इसलिए यह उतना ही एक क्लिनिकल-जोखिम बातचीत है जितना कल्याण की। विचार करें कि क्या आपकी क्षमता योजना खुशहाल पथ मानती है या घटनाओं, छुट्टी, और सीखने के लिए बजट बनाती है। एक अच्छा उत्तर बर्नआउट को एक व्यक्तिगत कमज़ोरी के बजाय एक सिस्टम गुण मानता है जिसके खिलाफ डिज़ाइन करना है, उन विशिष्ट संकेतों को नाम देता है जिन्हें टीम देखेगी, और अधिक लचीला होने के आग्रह के बजाय एक ठोस परिवर्तन — संसाधन, ऑन-कॉल निष्पक्षता, WIP सीमाएं — के लिए प्रतिबद्ध होता है।

4. जब एक समयसीमा नज़दीक आती है, तो हमारी पूर्ण की परिभाषा वास्तव में हमें क्या छोड़ने से रोकती है — और क्या हमने कभी साबित किया है कि यह टिकती है? हर टीम बता सकती है कि क्लिनिकल सुरक्षा, सुगमता, और सूचना प्रशासन मायने रखते हैं; वास्तविक परीक्षण यह है कि एक कठोर डिलीवरी तारीख और एक चिंतित हितधारक के संपर्क से क्या बचता है। तनाव यह है कि एक पूर्ण की परिभाषा केवल तभी सार्थक है जब यह आपको कुछ खर्च करती है — जब यह टीम को वादा किए गए दिन पर शिप न करने के लिए मजबूर करती है क्योंकि एक DCB0160 खतरा समीक्षा या एक WCAG 2.2 सुगमता जांच पूर्ण नहीं है। यदि आपके पूर्ण ने कभी एक बार भी आपको एक रिलीज़ रोकने के लिए प्रेरित नहीं किया है, तो यह एक नियंत्रण के बजाय सजावट हो सकती है। दबाव बिंदुओं की तलाश करें: "यह पूर्ण नहीं है" कहने का अधिकार किसके पास है, और क्या उन्हें नेतृत्व द्वारा समर्थित किया जाएगा या खारिज किया जाएगा? विचार करें कि क्या गैर-परक्राम्य संरचनात्मक हैं — पाइपलाइन में, स्वीकृति मानदंड में, साइन-ऑफ द्वारों में एनकोडेड — या क्या वे किसी के सबसे बुरे संभावित क्षण में उन्हें याद रखने पर निर्भर करते हैं। एक ईमानदार उत्तर एक विशिष्ट अवसर की ओर इशारा कर सकता है जहां दबाव में पूर्ण का आह्वान किया गया था, या स्पष्ट रूप से स्वीकार करता है कि इसका अभी तक परीक्षण नहीं किया गया है और इसे एक आराम के बजाय बंद करने के लिए एक अंतराल मानता है।

5. क्या इस टीम पर विभिन्न पेशेवर संस्कृतियां — क्लिनिकल, इंजीनियरिंग, अनुसंधान, डिलीवरी — वास्तव में काम करने का एक तरीका साझा करती हैं, या क्या हम चुपचाप असंगत डिफ़ॉल्ट पर चल रहे हैं? बहु-विषयक टीमें स्वास्थ्य और देखभाल में अच्छे कारण से अनिवार्य हैं, लेकिन एक क्लिनिशियन, एक इंजीनियर, एक उपयोगकर्ता शोधकर्ता, और एक डेटा विश्लेषक को एक टीम में लाने का अर्थ है साक्ष्य, जोखिम, गति, और "अच्छा" कैसा दिखता है के बारे में चार सेट पेशेवर प्रवृत्तियां लाना। घर्षण अक्सर अदृश्य होता है: शिप और पुनरावृत्त करने के लिए एक इंजीनियर का पूर्वाग्रह कार्य करने से पहले निश्चित होने के लिए प्रशिक्षित एक क्लिनिशियन को लापरवाही जैसा पढ़ सकता है, जबकि एक क्लिनिशियन की सावधानी प्रतिवर्ती तैनातियों के आदी किसी व्यक्ति को बाधा जैसी पढ़ सकती है। एक काम करने का समझौता जो सामान्य रहता है ("सम्मानजनक रहें, स्टैंड-अप में भाग लें") इन अंतरों को कभी सतह पर नहीं लाता, जबकि एक अच्छा यह नाम देता है कि यह टीम कैसे निर्णय लेती है, विषयों के बीच असहमति को कैसे संभालती है, और क्लिनिकल सावधानी को पुनरावृत्त डिलीवरी के साथ कैसे समेटती है। विचार करें कि क्या आपके मानदंड वास्तव में सह-लिखे गए थे या जो भी अनुशासन सबसे ज़ोर से चिल्लाया उससे आयातित थे। एक मज़बूत उत्तर पेशेवर संस्कृतियों की विविधता को एक असुविधा के बजाय सुरक्षा का एक स्रोत मानता है, उन स्पष्ट समझौतों की ओर इशारा करता है जो उनके बीच अनुवाद करते हैं, और एक हालिया असहमति का वर्णन कर सकता है जिसे टीम के मानदंडों ने अच्छी तरह हल करने में मदद की बजाय ढंकने के।

6. हमें कैसे पता चलता है कि हमारी रेट्रोस्पेक्टिव और स्वास्थ्य जांच कुछ बदल रहे हैं — और जब वे नहीं बदलते तो स्पष्टता का क्या होता है? एक टीम हर पखवाड़े एक निर्दोष रेट्रोस्पेक्टिव और एक त्रैमासिक स्क्वाड स्वास्थ्य जांच चला सकती है और फिर भी कुछ भी नहीं सुधार सकती, क्योंकि जो तंत्र मायने रखता है वह बैठक नहीं बल्कि अनुवर्ती कार्रवाई है। क्षयकारी विफलता मोड सूक्ष्म है: जब कार्रवाइयां उत्पन्न होती हैं और कभी नहीं की जातीं, लोग धीरे-धीरे सीखते हैं कि समस्याएं उठाना बेकार है, इसलिए स्पष्टता क्षय होती है और जोखिम को सतह पर लाने के लिए बनाया गया उपकरण स्वयं शांत हो जाता है — एक विशेष खतरा जहां अनकहा समस्या एक सुरक्षा चिंता है। ईमानदार प्रश्न साक्ष्य-आधारित है: पिछली मुट्ठी भर रेट्रो कार्रवाइयों या स्वास्थ्य-जांच संकेतों में से, कितने एक दृश्यमान परिवर्तन तक ले गए, और उनका स्वामी कौन था? शिकायतों की एक लंबी, संतोषजनक सूची उत्पन्न करने और कुछ स्वामित्व वाले, समय-सीमित प्रयोगों के लिए प्रतिबद्ध होने के बीच एक व्यापार है जिसे टीम वास्तव में पूरा करेगी। विचार करें कि क्या आपका अगला रेट्रो यह जांच कर खुलता है कि क्या पिछले की कार्रवाइयां हुईं, और क्या एम्बर-से-लाल स्वास्थ्य-जांच रुझान कभी उन लोगों तक पहुंचते हैं जिनके पास एक फिक्स को संसाधित करने का अधिकार है। एक अच्छा उत्तर सुधार आदत को आयोजित बैठकों के बजाय पूर्ण किए गए परिवर्तनों से मापता है, घटती स्पष्टता को अपने आप में एक प्रारंभिक चेतावनी मानता है, और काम करने के तरीके सुधार को उसी अनुशासन से जोड़ता है जिसे टीम एक क्लिनिकल मार्ग पर लागू करेगी।

व्यवहार में: एक स्वास्थ्य और देखभाल उदाहरण#

एक सामुदायिक NHS ट्रस्ट एक डिजिटल टीम चलाता है जो अपने इलेक्ट्रॉनिक रोगी रिकॉर्ड (EPR) और एक रोगी-सामना करने वाला नियुक्ति ऐप का समर्थन करती है। टीम बहु-विषयक है — उत्पाद प्रबंधक, डिलीवरी प्रबंधक, इंजीनियर, एक उपयोगकर्ता शोधकर्ता, एक क्लिनिकल सुरक्षा अधिकारी, और एक डेटा विश्लेषक — विषय 7.0 की संरचनाओं के तहत स्थापित। एक साल के लिए उन्होंने पाठ्यपुस्तक Scrum चलाया: दो-सप्ताह के स्प्रिंट, पूर्ण समारोह सेट। लेकिन वे वह टीम भी थे जिसे जब भी EPR गलत व्यवहार करता था पेज किया जाता था, और क्लिनिकल घटनाएं उनके स्प्रिंट प्रतिबद्धताओं को उड़ाती रहीं, उन्हें स्थायी रूप से पीछे महसूस कराते हुए और रेट्रोस्पेक्टिव तेज़ी से नीरस होते गए।

डिलीवरी प्रबंधक ने एक परिवर्तन प्रस्तावित किया। उन्होंने काम को विभाजित किया: नियुक्ति ऐप पर योजनाबद्ध उत्पाद विकास दो-सप्ताह के स्प्रिंट में रहता है जिसमें इसका उपयोग करने वाले बाह्य रोगी क्लिनिशियनों के लिए पखवाड़ी शो-एंड-टेल होते हैं, जबकि लाइव-सेवा EPR समर्थन एक सख्त WIP सीमा और स्पष्ट प्रवाह चरणों वाले Kanban बोर्ड पर चला जाता है। उन्होंने अपनी पूर्ण की परिभाषा फिर से लिखी ताकि EPR को छूने वाले किसी भी परिवर्तन के लिए, "पूर्ण" से पहले एक पूर्ण DCB0160 खतरा समीक्षा और सुगमता जांच की आवश्यकता हो — सुरक्षा को स्मृति पर छोड़ने के बजाय प्रक्रिया में एनकोड करते हुए।

उन्होंने एक त्रैमासिक स्क्वाड स्वास्थ्य जांच भी पेश की। पहले ने "टिकाऊ गति" और "समर्थन" आयामों में एम्बर-से-लाल जाते हुए सतह पर लाया कि ऑन-कॉल उन्हीं दो इंजीनियरों पर गिर रहा था और छुट्टी नहीं ली जा रही थी। टीम ने इस साक्ष्य का उपयोग अपने निदेशक के सामने एक ठोस मामला बनाने के लिए किया: एक व्यापक ऑन-कॉल रोटा और रात के पेज के बाद स्पष्ट पुनर्प्राप्ति समय। छह महीने बाद, रेट्रोस्पेक्टिव कार्रवाइयां दृश्यमान रूप से पूरी हो रही हैं, क्लिनिशियन पखवाड़ी डेमो पर भरोसा करते हैं, और अंतिम दो संभावित सुरक्षा मुद्दे रिलीज़ से पहले उन इंजीनियरों द्वारा फ्लैग किए गए थे जो "रुको" कहने के लिए सुरक्षित महसूस करते थे। यहां कुछ भी विदेशी नहीं था — यह टीम कैसे काम करती है इसका जानबूझकर डिज़ाइन था।

क्षेत्र दृष्टिकोण#

स्टार्टअप#

एक छोटी डिजिटल-स्वास्थ्य स्टार्टअप अक्सर सहज रूप से चुस्त चलाती है — एक कमरे में सब कुछ, अनौपचारिक स्टैंड-अप, तेज़ पुनरावृत्ति — जो गति और सीखने के लिए एक वास्तविक ताकत है। जोखिम यह है कि "हम प्रक्रिया के लिए बहुत छोटे हैं" चुपचाप इसका अर्थ रखता है कि पूर्ण की परिभाषा क्लिनिकल सुरक्षा और सुगमता को तब तक छोड़ती है जब तक एक NHS खरीदार की Digital Technology Assessment Criteria (DTAC) समीक्षा अंतराल को उजागर न कर दे। मनोवैज्ञानिक सुरक्षा आमतौर पर उच्च होती है जब टीम छोटी और संस्थापक-नेतृत्व वाली होती है, लेकिन एक करिश्माई संस्थापक जो बुरी खबर पर बुरी तरह प्रतिक्रिया देता है इसे अदृश्य रूप से नष्ट कर सकता है। जो कदम जल्दी भुगतान करता है वह एक हल्की पूर्ण की परिभाषा लिखना है जो सुरक्षा और सुगमता गैर-परक्राम्य को बेक करती है, और एक वित्तपोषण दौर की बर्न-रेट संस्कृति स्थायी क्रंच को सामान्य बनाने से पहले टिकाऊ गति की रक्षा करना है।

छोटा व्यवसाय#

एक स्थापित छोटा प्रदाता — एक GP प्रैक्टिस, एक सामुदायिक फार्मेसी, एक केयर होम, या एक एकल-साइट क्लिनिक — के पास शायद ही कभी बिल्कुल एक "डिलीवरी टीम" है: काम करने के तरीके जो भी प्रैक्टिस मैनेजर, एक क्लिनिकल लीड, और शायद एक अंशकालिक IT ठेकेदार रोगियों को देखने के साथ-साथ बनाए रख सकते हैं। सुधारने के लिए कोई स्प्रिंट या रेट्रोस्पेक्टिव नहीं हैं, इसलिए व्यावहारिक कदम सबसे सस्ती, सबसे उच्च-लाभ वाली आदतें उधार लेना है — बकाया डिजिटल परिवर्तनों का एक दृश्यमान बोर्ड जिसमें उड़ान में कितने हैं इसकी कठोर सीमा है, और एक छोटा लिखित समझौता कि लाइव जाने से पहले एक परिवर्तन को कौन साइन ऑफ करता है। पूर्ण की परिभाषा को अभी भी एक बड़े ट्रस्ट के समान वैधानिक कर्तव्य उठाने चाहिए — क्लिनिकल सुरक्षा, सुगमता, सूचना प्रशासन — लेकिन स्टाफ पर कोई क्लिनिकल सुरक्षा अधिकारी नहीं होने पर, इसका आमतौर पर अर्थ है एक हल्की चेकलिस्ट और यह जानना कि आश्वासन के लिए किस आपूर्तिकर्ता या ICB संपर्क को कॉल करना है। क्योंकि वही मुट्ठी भर लोग सेवा डिलीवरी और परिवर्तन दोनों उठाते हैं, टिकाऊ गति एक वास्तविक जोखिम है: एक अपग्रेड जो गलत हो जाता है स्टाफ पर पड़ता है जो बस एक ऑन-कॉल रोटा को पेज नहीं कर सकता। यथार्थवादी महत्वाकांक्षा पूर्ण चुस्त समारोह नहीं बल्कि जानबूझकर, लिखित, सुरक्षित-बाय-डिफ़ॉल्ट आदतें हैं जो उस एक व्यक्ति के जाने से बच जाती हैं जो वर्तमान में इसे अपने सिर में रखता है।

बड़ा संगठन#

एक बड़े NHS ट्रस्ट या स्वास्थ्य-तकनीक फर्म के पास कई टीमें हैं और विपरीत समस्या: चुस्त समारोह गुणा होते हैं, "चुस्त" एक अपरिवर्तित आदेश-और-नियंत्रण संस्कृति पर पेंट का एक कोट बन जाता है, और टीमें उस स्वायत्तता के बिना अनुष्ठान करती हैं जो उन्हें सार्थक बनाती है। दर्जनों टीमों में एक एकल ढांचे (अक्सर स्केल किया गया चुस्त) को मानकीकृत करना ऐसी गति लगाने का जोखिम रखता है जो कुछ के लिए फिट बैठती है और दूसरों को अपंग करती है, इसलिए साझा गार्डरेल के भीतर टीमों को Scrum, Kanban, या एक हाइब्रिड चुनने की अनुमति दें। इस पैमाने पर, टीमों में एकत्रित टीम-स्वास्थ्य जांच नेतृत्व को संगठनात्मक जलवायु के बारे में एक वास्तविक संकेत देती हैं — लेकिन केवल तभी जब डेटा टीमों की मदद के लिए उपयोग किया जाता है, कभी उन्हें रैंक या दंडित करने के लिए नहीं। एंटरप्राइज़ का निर्णायक लाभ उन प्लेटफ़ॉर्मों, ऑन-कॉल संरचनाओं, और संरक्षित सुधार समय में निवेश करने की क्षमता है जो टिकाऊ गति को आकांक्षात्मक के बजाय प्राप्य बनाते हैं।

सरकार#

NHS England या एक स्थानीय अधिकारी जैसा एक राष्ट्रीय निकाय वे मानक निर्धारित करता है जिनके खिलाफ अन्य देते हैं — GOV.UK Service Manual और NHS Service Standard दोनों चुस्त, पुनरावृत्त तरीकों से काम करने वाली बहु-विषयक टीमों को अनिवार्य करते हैं — और यह इस बात के लिए जनता के प्रति जवाबदेह है कि काम करने के तरीके पैसे के लिए मूल्य में कैसे अनुवादित होते हैं। अधिकांश डिलीवरी आपूर्तिकर्ताओं को अनुबंधित है, इसलिए सरकार का काम-करने-के-तरीके का लाभ संविदात्मक है: चुस्त भाषा में सजे एक वॉटरफॉल योजना के विरुद्ध दस्तावेज़ों को स्वीकार करने के बजाय नियमित शो-एंड-टेल पर प्रदर्शित काम करने वाले सॉफ़्टवेयर के साथ वास्तविक चुस्त डिलीवरी पर ज़ोर दें। जवाबदेही औपचारिक और ऑडिट योग्य है, जो भारी प्रशासन समारोहों की ओर खींच सकती है जो टीम प्रवाह को थ्रॉटल करते हैं, इसलिए अनुशासन टीम की अपनी गति को दबाए बिना परिणामों और सुरक्षा को सुनिश्चित करना है। सार्वजनिक-विश्वास आयाम यहां सबसे तेज़ है: एक स्पष्ट रूप से स्वस्थ, पारदर्शी डिलीवरी टीम इस बात का हिस्सा है कि कैसे एक सार्वजनिक निकाय संवेदनशील डेटा रखने और महत्वपूर्ण सेवाएं चलाने का विश्वास अर्जित करता है।

सामान्य विफलता मोड#

• ज़ोंबी समारोह। स्टैंड-अप जो एक प्रबंधक के लिए स्थिति थिएटर हैं, बिना वास्तविक उपयोगकर्ताओं के मौजूद समीक्षाएं, रेट्रोस्पेक्टिव जो कभी कुछ नहीं बदलतीं। कार्यक्रम ऑटोपायलट पर चलते हैं, समय खपत करते हैं और टीम को सिखाते हैं कि भागीदारी बेकार है। हर कार्यक्रम को निर्दयता से इसके उद्देश्य से फिर से जोड़कर या इसे रोककर ठीक करें।
• कोई योजना या कोई प्रशासन नहीं के लिए कवर के रूप में चुस्त। "हम चुस्त हैं" क्लिनिकल-सुरक्षा, सुगमता, या सूचना-प्रशासन काम छोड़ने को न्यायोचित ठहराने के लिए उपयोग किया जाता है। चुस्तता को इन्हें पहले सतह पर लाना चाहिए, इन्हें बहाना नहीं बनाना चाहिए; इन्हें पूर्ण की परिभाषा में रखें।
• कार्गो-कल्ट ढांचा अपनाना। नीचे स्वायत्तता, पारदर्शिता, और विश्वास के बिना Scrum या Spotify मॉडल के लेबल कॉपी करना। सिद्धांत उधार लें, अपने संदर्भ के अनुरूप ढालें, और टीमों को गार्डरेल के भीतर अपनी खुद की गति चुनने दें।
• प्रगति में सब कुछ, कुछ भी पूर्ण नहीं। कोई WIP सीमा नहीं, इसलिए टीम बहुत सारी चीज़ें शुरू करती है और कुछ को पूरा करती है, लीड टाइम फूलते हुए और आधे-परीक्षित परिवर्तन जमा होते हुए। काम को दृश्यमान बनाएं और इसे सीमित करें।
• परिचालन मॉडल के रूप में वीरता। कुछ द्वारा किया गया निरंतर ओवरटाइम और ऑन-कॉल, ठीक करने के बजाय मनाया गया। यह आपके सबसे अच्छे लोगों को जलाता है और, सुरक्षा-महत्वपूर्ण सिस्टमों के लिए, क्लिनिकल जोखिम बढ़ाता है। टिकाऊ गति और निष्पक्ष रोटेशन के लिए डिज़ाइन करें।
• अनुवर्ती के बिना रेट्रो। कार्रवाइयां उत्पन्न हुईं और कभी नहीं कीं, इसलिए स्पष्टता क्षय होती है। कुछ स्वामित्व वाले, समय-सीमित प्रयोगों तक सीमित रखें और अगली बार उनकी जांच करें।
• मनोवैज्ञानिक सुरक्षा मान ली गई, बनाई नहीं गई। नेता टीम को सुरक्षित घोषित करते हैं जबकि उनकी अपनी प्रतिक्रियाएं लोगों को चुप रहना सिखाती हैं। इसे विश्वास से नहीं, व्यवहार से मापें।

परिपक्वता मॉडल#

जांच-सूची#

• टीम ने अपनी गति (स्प्रिंट, प्रवाह, या हाइब्रिड) को अपने काम की प्रकृति के अनुरूप सचेत रूप से चुना है, और विकल्प को फिर से देखती है।
• हर समारोह का एक बताया गया उद्देश्य है जिसे सभी समझते हैं, और जो कार्यक्रम अब इसकी सेवा नहीं करते उन्हें बदला या रोका जाता है।
• नियमित शो-एंड-टेल वास्तविक क्लिनिशियनों, रोगियों, या परिचालन उपयोगकर्ताओं को काम करने वाला सॉफ़्टवेयर प्रदर्शित करते हैं।
• एक लिखित तैयार की परिभाषा और पूर्ण की परिभाषा मौजूद हैं, पूर्ण में क्लिनिकल सुरक्षा, सुगमता, और सूचना प्रशासन एनकोडेड।
• प्रगति में काम दृश्यमान बनाया गया है और स्पष्ट रूप से सीमित है।
• टीम ने एक साथ एक काम करने का समझौता/चार्टर लिखा है और इसे समय-समय पर समीक्षा करती है।
• एक हल्की टीम-स्वास्थ्य जांच एक नियमित गति पर चलती है, टीम के स्वामित्व में, और इसके रुझान कार्रवाई को सूचित करते हैं।
• रेट्रोस्पेक्टिव कुछ स्वामित्व वाली, समय-सीमित कार्रवाइयों के साथ समाप्त होती हैं, और अगला रेट्रो जांचता है कि क्या वे हुईं।
• बर्नआउट के अग्रणी संकेतकों की निगरानी की जाती है, ऑन-कॉल निष्पक्ष रूप से साझा किया जाता है, और क्षमता को एक टिकाऊ गति के लिए योजनाबद्ध किया जाता है।
• दूरस्थ/हाइब्रिड/अतुल्यकालिक सहयोग जानबूझकर डिज़ाइन किया गया है: निर्णय वहां दस्तावेज़ीकृत हैं जहां अनुपस्थित सहयोगी उन्हें पा सकें।
• नेता दोष-मुक्त समीक्षाओं और बुरी खबर पर अपनी खुद की दृश्यमान प्रतिक्रिया के माध्यम से सक्रिय रूप से मनोवैज्ञानिक सुरक्षा बनाते हैं।

मुख्य स्रोत#

• Agile Manifesto और इसके बारह सिद्धांत (जिनमें "टिकाऊ विकास … अनिश्चित काल तक एक स्थिर गति बनाए रखें" शामिल है) — agilemanifesto.org
• The Scrum Guide — Ken Schwaber & Jeff Sutherland — scrumguides.org
• Kanban — David J. Anderson — प्रवाह को दृश्यमान बनाना और प्रगति में काम को सीमित करना
• NHS England — NHS Service Standard और NHS Service Manual — बहु-विषयक चुस्त डिलीवरी और शो-एंड-टेल
• GOV.UK Service Manual (Government Digital Service) — चुस्त डिलीवरी, चुस्त समारोह, और टिकाऊ काम करने के तरीके
• Amy C. Edmondson, The Fearless Organization — स्वास्थ्य सेवा में मनोवैज्ञानिक सुरक्षा और टीम सीखना
• Google re:Work — Project Aristotle निष्कर्ष कि क्या टीमों को प्रभावी बनाता है
• Spotify "Squad Health Check" मॉडल — Henrik Kniberg & Kristian Lindwall
• World Health Organization — ICD-11 (QD85) में बर्नआउट वर्गीकरण

संदर्भ#

1. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
2. Iterative and incremental development — Wikipedia — https://en.wikipedia.org/wiki/Iterative_and_incremental_development
3. Scrum (project management) — Wikipedia — https://en.wikipedia.org/wiki/Scrum_(project_management)
4. Kanban (development) — Wikipedia — https://en.wikipedia.org/wiki/Kanban_(development)
5. Stand-up meeting — Wikipedia — https://en.wikipedia.org/wiki/Stand-up_meeting
6. Retrospective — Wikipedia — https://en.wikipedia.org/wiki/Retrospective
7. Psychological safety — Wikipedia — https://en.wikipedia.org/wiki/Psychological_safety
8. Occupational burnout — Wikipedia — https://en.wikipedia.org/wiki/Occupational_burnout
9. Continual improvement process — Wikipedia — https://en.wikipedia.org/wiki/Continual_improvement_process
10. Manifesto for Agile Software Development — Beck et al. — https://agilemanifesto.org
11. The Scrum Guide (2020) — Ken Schwaber & Jeff Sutherland — https://scrumguides.org
12. NHS Service Manual and Service Standard — NHS England — https://service-manual.nhs.uk
13. Service Manual (agile delivery) — Government Digital Service, GOV.UK — https://www.gov.uk/service-manual/agile-delivery
14. The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth — Amy C. Edmondson — https://fearlessorganization.com
15. re:Work — Guide: Understand team effectiveness (Project Aristotle) — Google — https://rework.withgoogle.com/guides/understanding-team-effectiveness/
16. Squad Health Check model — Henrik Kniberg & Kristian Lindwall, Spotify Engineering — https://engineering.atspotify.com/2014/09/squad-health-check-model
17. Burn-out an "occupational phenomenon": International Classification of Diseases (ICD-11) — World Health Organization — https://www.who.int/news/item/28-05-2019-burn-out-an-occupational-phenomenon-international-classification-of-diseases

विषय 3.6 — DevOps और इंजीनियरिंग उत्कृष्टता, विषय 3.8 — सेवा प्रबंधन और लाइव संचालन, विषय 7.0 — टीम संरचनाएं, भूमिकाएं, और जिम्मेदारियां, विषय 7.5 — लोग और संगठनात्मक विकास, और विषय 10.2 — गुणवत्ता सुधार और सुधार विज्ञान भी देखें।