एक टीम मैनेजर और एक स्करम टीम में एक डेवलपर होने के नाते


11

मैं 6 लोगों की एक टीम का प्रबंधन कर रहा हूं जो हाल ही में स्क्रेम में स्थानांतरित हुई।

हमारे पास एक स्क्रम मास्टर (टीम में डेवलपर्स में से एक) और एक उत्पाद स्वामी है।

चूंकि मेरे पास काफी खाली समय है (क्योंकि प्रबंधन का बहुत सारा काम जो मैं करता था, वह अब स्क्रैम मास्टर और उत्पाद स्वामी द्वारा किया जाता है), और चूंकि मैं तकनीकी रूप से प्रासंगिक रहना चाहता हूं, इसलिए मैं कुछ तकनीकी विकास कार्य कर रहा हूं।

मैं विकास टीम के एक हिस्से के रूप में कार्य करता हूं, प्रत्येक स्प्रिंट में कुछ कहानियों के लिए प्रतिबद्ध हूं, और टीम के हिस्से के रूप में सभी बैठकों में भाग लेता हूं।

क्या आपको लगता है कि यह एक अच्छा विचार है? क्या यह टीम के "स्व-संगठन" के विपरीत हो सकता है?


स्क्रैम टीम में "मैनेजर" की किस तरह की भूमिका है? स्क्रैम टीम में मैनेजर होने का कोई मतलब नहीं है।
व्यंग्यात्मक

जवाबों:


13

5whys.com पर फुर्तीली दुनिया में टीम के नेतृत्व पर रॉय ओशेरोव के विकासशील विचारों के बारे में पढ़ें

वह तीन प्रमुख चरणों के बारे में बहुत सारी बातें करता है जो एक टीम के माध्यम से जाती है क्योंकि यह जलप्रपात से स्क्रेम तक विकसित होती है।

उत्तरजीविता चरण (जहां मैं देख रही अधिकांश टीमें हैं) - जिसमें टीम के पास सीखने का समय नहीं है - उस सीखने के समय को बनाने के लिए अधिक कमांड और नियंत्रण प्रकार के नेतृत्व की आवश्यकता होती है।

सीखने का चरण - जहां एक टीम के पास सीखने का समय होता है और वह इसका उपयोग कर रहा है - उसे कोच जैसे नेता की आवश्यकता होती है, नियंत्रण के फटने के साथ जब कठिन तरीके से सीखने में बहुत समय लगेगा (कोई स्रोत नियंत्रण नहीं चुनना, उदाहरण के लिए)

सेल्फ ऑर्गेनाइजेशन फेज - जहाँ टीमें अपनी अपनी समस्याओं को हल कर सकती हैं - इसके लिए अधिक सुविधाजनक प्रकार के लीडर की आवश्यकता होती है, जो लोगों को यह नहीं बताता है कि क्या करना है, लेकिन बस अड़चनें और लक्ष्य समाप्त करना है। टीम अपने दम पर वहां पहुंच जाएगी।

जब मैं रॉय के विचारों पर आया, OpenVolcano '10 में , मुझे पूरी तरह से नुकसान हुआ कि मेरी टीम ने सुधार करना क्यों बंद कर दिया। तब मुझे महसूस हुआ कि टीम सर्वाइवल से लेकर लर्निंग तक पार कर चुकी है और मैंने अपनी प्रबंधन शैली बिल्कुल नहीं बदली है। मैंने ऐसा किया और इससे काफी मदद मिली।

इसलिए मैं सुझाव देता हूं कि आप उन तीन चरणों में से किसमें हैं और तदनुसार प्रबंध कर रहे हैं।

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


3

पीडीआर की टिप्पणियां मान्य हैं, और मैं उनसे सहमत हूं। लेकिन मैं उन्हें सभी मामलों के लिए सार्वभौमिक नहीं मानता।

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

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

यह ध्यान देने योग्य है कि आप असमानता के सभी प्रभावों को समाप्त नहीं कर सकते। ऐसे समय होंगे जब आपको अपनी जीभ को काटने और एक उत्साही बहस से वापस पकड़ने की आवश्यकता होगी। ट्रम्प कार्ड को खींचने की आवश्यकता होने पर अन्य लोग होंगे और इंगित करेंगे कि टीम के लिए अंतिम जिम्मेदारी आपके साथ है, इसलिए आप एक डिक्टेट बना रहे हैं।

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

मैं ईमानदारी से इसे पसंद करता हूं जब मेरे तत्काल पर्यवेक्षक खुद को तकनीकी रूप से प्रासंगिक रखते हैं। यह मेरी कठिनाइयों के बारे में उनकी समझ को आसान बनाता है, और मुझे लगता है कि हम एक बेहतर प्रदर्शन करने वाली टीम के साथ समाप्त होते हैं।


+1 यहाँ इसी तरह के अनुभव। संतुलन और आत्म-जागरूकता प्रमुख हैं।
मैट एस

1
हाँ, मेरा तर्क राजनीति या सत्ता के बारे में नहीं था। मैं सिर्फ यह सोचता हूं कि यदि आपके पास विकास करने का समय है (जब तक कि आपके पास 2-3 की टीम नहीं है), तो संभवत: कुछ और है जो आप कर सकते हैं जो पूरी टीम की उत्पादकता बढ़ा सकता है, और टीम लीडर के रूप में आपका काम है। यदि आपके पास उन चीज़ों की सूची नहीं है जो किए जाने की प्रतीक्षा कर रहे हैं तो आप अपनी टीम से पर्याप्त बात नहीं कर रहे हैं; इस तरह समय बिताओ। यह अवसर की लागत के बारे में है, राजनीति के बारे में नहीं।
पीडीआर

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

2

मैं पहले भी इसी तरह के अनुभव से गुजरा था, जिसने 6 डेवलपर्स की टीम को एक स्क्रम टीम में अग्रणी किया। Pdr और GlenH7 ने किन चीजों का जिक्र किया है, इसके अलावा:

  1. क्यूए टीम पर सबसे अच्छा परीक्षक वास्तव में हमारे काम की गुणवत्ता के लिए जवाबदेह रखने में अच्छा था, जिसमें मैंने जो काम किया था, उसमें शामिल थे। जब मैंने छोटी गाड़ी कोड लिखा, तो उसने मुझे इस तरह से बुलाया, जो किसी अन्य डेवलपर के लिए करना मुश्किल होगा।
  2. मैंने आमतौर पर स्प्रिंट डेमो किया, खासकर जब हमारे पास खराब स्प्रिंट थे। जब से मैं सीईओ के लिए प्रदर्शन कर रहा था, यह तब शर्मनाक था जब सामान काम नहीं करता था। यह सुनिश्चित करने के अलावा कि मैं उन विशेषताओं को समझता हूं जो दूसरों ने विकसित की हैं, इसका मतलब यह भी था कि मेरा सामान किसी और की तरह ठोस होना चाहिए।
  3. मैं दूसरों को निर्णय लेने देता हूं। मेरा अनुभव GlenH7 से अलग है, मैंने हमेशा इसे ट्रम्प कार्ड खींचने की गलती पाया। इसके बजाय, मैंने निर्णयों के विभिन्न परिणामों के माध्यम से बात की, और स्पष्ट किया कि जो कभी डेवलपर उस चीज़ पर काम कर रहा था, जिसके परिणाम मुझे लगे कि कुछ करने का "गलत" तरीका था। ऐसा करने के कई कारण हैं, लेकिन सबसे बड़ी बात यह है कि टीम लीड के रूप में, आपके पास सभी निर्णय लेने का समय नहीं है।
  4. सोनार जैसे उत्पाद का उपयोग करना कोड गुणवत्ता जैसी चीजों को अधिक उद्देश्यपूर्ण बना सकता है।

महान टिप्पणियां, विशेष रूप से # 3 पर। ट्रम्प कार्ड खींचना एक दुर्लभ घटना होनी चाहिए।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.