اسکرام مسترینگ موقعیتی – هدایت و رهبری یک تیم اجایل

به قلم مایک کوهن

چند سال پیش، در یک بازی گلف پس از اینکه تعدادی توپ گلف را به دریاچه انداختم، دوستی که با او بازی می‌کردم توصیه‌هایی به من کرد. دوستم گلف را بهتر از من بازی نمی‌کند، اما این مسئله باعث نشد که نظرات خود را با من در میان نگذارد. او گفت: «مشکل کار این است که باید توپ را دورتر بزنید». او ممکن بود به من بگوید که مشکل اصلی، تعداد بالای ضربه‌ها برای انداختن توپ به داخل حفره است. البته من نیاز داشتم به مسافت بیشتری در ضربه‌ها دست پیدا کنم. اما چگونه؟

به طور مشابه، ممکن است به شما گفته شود که مدیریت پروژه اجایل – صرف نظر از اینکه توسط یک اسکرام مستر، مربی یا مدیر پروژه اجایل انجام شود – بیشتر از آنکه در مورد مدیریت یک تیم باشد، رهبری و هدایت تیم را شامل می‌شود. با این وجود، توصیه به یک اسکرام مستر برای «رهبری تیم به جای مدیریت آن» چندان راهنمایی مفید و آموزنده‌ای نیست. این توصیه مانند این است که به یک گلف باز بگوییم باید توپ را دورتر بزند. این یک راهنمایی معتبر اما غیر قابل اجرا است.

یک روش بهتر برای درک این مسئله که چگونه اسکرام مستر‌ها می‌توانند به بهترین شکل ممکن تیم‌هایی را رهبری کنند که به دنبال اجایل شدن هستند، این است که از ابتدا نیاز‌های تیم را در رابطه با رهبری مشخص کنیم و سپس به چهار روش مختلف هدایت و رهبری تیم را بر عهده بگیریم.

با نگاهی به مدل رهبری موقعیتی پل هرسی، به این موضوع بیشتر خواهیم پرداخت. مدل هرسی چهار سطح آمادگی را برای تیم‌هایی توصیف می‌کند که به دنبال پیدا کردن روش‌های جدید انجام کار هستند، در شکل ۱ خلاصه‌ای از این مدل ارائه شده است.

به گفته هرسی، رهبران باید رفتار خود را مطابق با سطح آمادگی(readiness) تیم تنظیم(adapt) کنند. به عبارت دیگر، برای یک اسکرام مستر، نحوه هدایت و رهبری یک تیم توانا(Able) و متمایل (willing)، متفاوت از یک تیم ناتوان(unable) و نا‌مطمئن(unwilling) است. از نظر هرسی، رهبران خوب رفتارهای مرتبط با رهبری را با توجه دو بعد تنظیم میکنند: شکل

رفتار تکلیف مدار و رفتار رابطه‌ مدار.

رفتار تکلیف مدار(leader’s task behavior)، حدودی است که بر مبنای آن یک رهبر فعالیت‌های یک تیم را هدایت(directs) می‌کند.

رفتار رابطه مدار(leader’s relationship behavior) حدودی است که با توجه به آن رهبر با استفاده از رابطه خود با تیم، وظیفه رهبری را انجام می‌دهد.

این رفتار‌ها در کنار یکدیگر، چهار سبک رهبری (Leadership styles) متمایز را تشکیل می‌دهند:

• هدایتگری (telling)-(دراین متن در ترجمه از هدایتگری استفاده میشود، شاید گفتاری یا دستوری هم ترجمه شود)
• مربیگری (selling)- (دراین متن در ترجمه از مربی استفاده میشود، شاید توجیهی هم ترجمه شود)
• مشارکتی(Participating)
• تفویضی(Delegating)

بنابراین، سبک رهبری «درست»، سبکی است که به بهترین وجه و از هر نظر مطابق با سطح آمادگی تیم (team’s readiness level) باشد.

این انطباق به صورت گرافیکی در شکل ۲ نشان داده شده است.

رفتار تکلیف محور (Task Behavior) در امتداد محور x و رفتار رابطه محور(Relationship Behavior) او در امتداد محور y ترسیم شده است. این تصویر به چهار ربع تقسیم می‌شود که هر یک نشان دهنده یکی از چهار سطح آمادگی هستند. هر بخش حاوی یک نام توصیفی برای سبک رهبری است که از بیشترین تناسب برای تیم های حاضر در آن ربع برخوردار است.

شکل ۲. چهار سبک رهبری برای چهار سطح آمادگی تیمی

شکل 2

هدایتگر (telling)، مربیگری(selling)، مشارکتی(Participating)،تفویضی(Delegating)

رفتار تکلیف مدار(leader’s task behavior)، رفتار رابطه مدار(leader’s relationship behavior)

به عنوان مثال، تیم R1 که ناتوان(unable) و نا‌مطمئن(insecure) است، به راهنمایی بیشتر از سوی اسکرام مستر خود نیاز دارد. اسکرام مستر این تیم کمتر به ارتباطات دو طرفه two-way communication [یک رفتار با روابط بالا] تکیه دارد و در مقابل طرفدار ارتباط یک طرفه(one-way communication) است.

اسکرام مستر ها همیشه نیازمند مهارت‌های بین فردی قوی هستند، اما یک تیم R1 (ناتوان و نامطمئن) به منظور کسب اعتماد به نفس کافی برای مشارکت سازنده در ارتباطات دو طرفه و ارتقا به عنوان یک تیم R2 به سطح بالایی از راهنمایی‌های کاری(task guidance) نیاز دارد.

در مقابل، تیم‌های R3 و R4 با برخورداری از سطوح بالایی از توانایی‌های خود، به سطح بسیار پایین‌تری از هدایت کارها (direction) از سوی اسکرام مستر خود نیاز دارند.

در ادامه این مقاله، به موارد خاصی می‌پردازیم که یک اسکرام مستر در هنگام رهبری تیم‌های حاضر در هر یک از این بخش ها ملزم به انجام آنها است.

اسکرام مستر با سبک رهبری هدایتگری (telling) برای بخش R1

قبل از اینکه یک تیم ناتوان(unable) و بی‌میل(unwilling) یا نامطمئن[insecure] یا همان تیم R1 واقعاً بتواند به یک تیم اجایل تبدیل شود، اعضای آن ابتدا باید اعتماد به نفس لازم را کسب کنند. به منظور کمک به آنها برای کسب اعتماد به نفس مورد نیاز، یک اسکرام مستر خوب بیشتر از آنکه به دنبال ایجاد روابط حمایتی و ارتباطی باشد و بر این تمرکز دارد که به اعضای تیم بگوید(telling) چه کاری را بهتر است که انجام دهند.[teaching]

اگرچه این روش ممکن است مغایر با تاکید اسکرام بر خودسازماندهی(self-organizing) تیم‌ها باشد، اما واقعیت این است که تیم حاضر در ربع R1 هنوز از آمادگی لازم برای سازماندهی خود(self-organize) به روش بهینه برخوردار نیست. با این حال، اسکرام مستر‌ها و مر‌بیان می‌توانند زمینه را برای توانمند سازی تیم‌های حاضر در این وضعیت (R1) فراهم کنند تا به سرعت به یک تیم R2 (ناتوان اما متمایل یا مطمئن) [unable but willing or confident] تبدیل شوند – تیمی که از آمادگی لازم برای اجایل شدن برخوردار است.

یک تیم در شرایط R1 برای انجام یک پروژه بزرگ یا اهداف جسورانه(aggressive goals) آماده نیست در حالی که برای رسیدن به چنین هدفی باید اعضای آن تیم توانایی لازم برای استفاده حداکثری(utmost) از توانمندی‌های خود(perform) را داشته باشند. در مقابل، این نوع تیم باید کار خود را با پیروزی‌های ساده و کوچکی آغاز کند که منجر به افزایش اعتماد به نفس در آنها ‌شوند.

اسکرام مستر یک تیم R1 باید تصمیماتی برای تیم بگیرد که آن تیم را در مسیر پیروزی قرار دهد

اسکرام مستر یک تیم R1 باید تصمیماتی برای تیم بگیرد که آن تیم را در مسیر پیروزی قرار دهد (بله، منظور من دقیقاً همین است). این تصمیمات معمولاً در رابطه با ایجاد برخی از فرآیندهای اساسی هستند که به تیم کمک می‌کنند تا حدی به موفقیت دست یابد.

ابتدا اصرار شما بر روی Sprint های یک تا دو هفته‌ای باشد. به هر میزان که Sprint کوتاه‌تر باشد بازخورد(feedback) اعضای تیم در مورد نحوه اجرای اسکرام بیشتر خواهد بود. در زمان معرفی اسکرام به یک تیم، استفاده از Sprint های کوتاه مدت می‌تواند به شکل ویژه‌ای مفید باشد. تیمی که به تازگی اجایل شده است باید دائما نحوه عملکرد خود را مورد سنجش قرار دهد. در اکثر موارد انتظار یک ماهه برای مشاهده نتایج یک Sprint بسیار طولانی است.

در ادامه، بر روی مهارت‌های اساسی اجایل مانند تست کردن (TEST) کار کنید. توضیح دهید که مسئله کیفیت برای همه افراد و در تمام کارها بسیار حائز اهمیت است. قانونی ایجاد کنید که بر اساس آن برنامه نویسان باید قبل از check in کردن کد، unit test را اجرایی کند. نیازی نیست که تست‌ها برای این نوع از تیم‌ها خودکار سازی(automated) شوند، اما انجام آنها ضروری است.

در عین حال، به تیم فرآیند مداوم یکپارچه سازی(CI-continuous integration) یا حداقل یک ساخت (نسخه) شبانه (a nightly build) را معرفی کنید(آموزش دهید). در حالت ایده‌آل، این ساخت‌ها باید همراه با مجموعه‌ای ساده از تست‌های خودکار، در سطح واحد(unit test) یا عملکرد(functional test)، ارائه شوند.

انتظار می‌رود که در همان ابتدا تست‌های چندان زیادی وجود نداشته باشد و تست‌های موجود نیز ممکن است اغلب با شکست مواجه شوند. با این حال، در اکثر موارد، بعد از گذشت چندین هفته تعداد تست‌ها و تعداد خروجی های موفق(successful builds) افزایش می‌یابد. چندین هفته دریافت بازخورد‌های مثبت از ساخت‌های موفق متعدد (و کاهش نیاز به تکرار حاصل از آن) می‌تواند تاثیر مطلوبی بر روی روحیه(morale) و اعتماد به نفس(confidence) تیم داشته باشد.

چند سال پیش، یک تیم کلاسیک R1، ناتوان و نامطمئن به من تحویل داده شد. همه اعضای تیم تقریباً برنامه نویس COBOL بودند که کارهای خود را توسط رایانه‌های شخصی انجام می‌دادند. مالک شرکت به تازگی تغییر یافته بود و مدیریت قبلی بارها به اعضای تیم گفته بود که امکان انجام کار توسط فناوری‌های جدیدتر یا جالب‌تر وجود ندارد.

برنامه نویسان بسیار باهوشی در این تیم مشغول به کار بودند اما به دلیل چنین برخوردهایی تمام اعتماد به نفس خود را از دست داده و مهارت‌هایشان منسوخ شده بود. پس از چند ماه ارائه راهنمایی‌های(guidance) بسیار خاص به تیم در مورد انتخاب فناوری‌های مورد استفاده، نحوه انجام کار و غیره، اعتماد به نفس اعضای تیم افزایش یافت. تیمی که زمانی ناکارآمد(once-dysfunctional) بود، ویژگی‌های ربع R2 را کسب کرد.

اسکرام مستر با سبک رهبری توجیهی برای بخش R2

در ربع R2، اسکرام مستر با تیمی با توانایی پایین (low ability) اما متمایل (willing) یا مطمئن(confident) کار می‌کند. در این مرحله از توسعه تیم، هدف اصلی، تقویت و افزایش قابلیت‌های اعضای تیم است. اگرچه برخی از تیم‌ها پس از عبور از ربع اول و سبک رهبری telling به این نقطه می‌رسند، اما بسیاری از تیم‌ها ممکن است به عنوان تیم R2 کار خود را آغاز می‌کنند. تیم‌های حاضر در این ربع از ویژگی‌های لازم برای اجایل شدن(become agile) برخوردار هستند اما هنوز به قابلیت‌های آن دست نیافته‌اند. تیم‌های R2 نیازمند استفاده از سبک رهبری selling هستند –  سبکی که ترکیبی از رفتار تکلیف مدار هدایتگری زیاد و رفتار رابطه‌ مدار حمایتی زیاد را مورد استفاده قرار می‌دهد.

اسکرام مستر در یک تیم R2 به درجاتی از اعتماد و اطمینان(trust and confidence) بین اعضای تیم رو مشاهده میکند. در چنین شرایطی سرمایه گذاری بر روی این روابط موجب افزایش قابلیت‌های اجایلی تیم می‌شود.

در این مرحله به دنبال مشارکت بیشتر اعضای تیم در فرآیند تصمیم گیری باشید. در زمان گرفتن تصمیمات برای تیم، در صورت امکان از اعضای تیم برای شرکت در فرآیند تصمیم‌گیری دعوت کنید.

ربع R2 آغاز فرآیند تبدیل شده به تیمی اجایل است

علاوه بر این، به دنبال کمک به اعضای تیم در جهت بهبود مهارت‌های آنها باشید. تمرکز بر روی فرآیند TEST را ادامه دهید، اما اعضای تیم را برای ایجاد تست‌های خودکار(automated tests) مورد چالش قرار دهید. به منظور آموزش(training) استفاده از ابزارهای مناسب تست خودکار به اعضای تیم، بر روی آموزش افراد سرمایه گذاری کنید – برگشت سرمایه(payback) در بسیاری از ابزارها در زمان کوتاهی انجام می‌شود.

به منظور کمک به گسترش دانش و مهارت‌ها در گروه، برنامه نویسی جفتی(pair programming) را در دستور کار خود قرار دهید. من به ندرت اعضای تیم را ملزم به pair programming می‌کنم اما از آنها می‌خواهم آن را امتحان کنند و تشخیص دهند چه زمانی استفاده از این روش مناسب است.

به منظور رساندن این پیام به اعضای تیم که فکر کردن در مورد کیفیت کد قابل قبول و مطلوب است، به دنبال ایجاد اعتماد رو به رشد در تیم باشید. بسیاری از اعضای تیم برای مدت طولانی و بارها کلمه سریعتر، سریعتر، سریعتر را شنیده‌اند که این مسئله باعث شده در شنیدن این پیام که نوشتن کد با کیفیت بالا موجب افزایش سرعت می‌شود، با مشکل مواجه شوند. به آنها (و هر فرد دیگری که وسوسه می‌شود تنها بر روی سرعت متمرکز شود) یادآوری کنید که اگر در بزرگراه با سرعت۱۲۰ مایل در ساعت حرکت کنید، از شانس بالایی برای جریمه شدن یا تصادف برخوردار خواهید بود. در هر صورت، اگر سریعتر از میانگین سرعت ایمن و با کیفیت ۷۰ مایل در ساعت حرکت کنید h به مقصد خود نخواهید رسید.

در مرحله R2، از مشارکت اعضای تیم در فرآیند تصمیم گیری بهره‌مند شوید

من شخصاً هرگز به یک تیم (به ویژه یک تیم R2) توصیه نمی‌کنم که با سرعت بیشتری حرکت کند. با این حال، در اکثر موارد پیشنهاد من به آنها این است که می‌توانند نوشتن کدهای بهتر و با کیفیت بالاتر را از طریق برنامه نویسی دونفره(pair programming)، آزمایش خودکار(automated testing) و بازآفرینی(refactoring) یاد بگیرند.

در ربع رهبری selling، تاکید شما همچنان بر Sprint کوتاه باشد. تیم‌های R2 همچنان از مزیت امکان ارزیابی پیشرفت خود در بازه های زمانی کوتاه برخوردار باشند. بسیاری از تیم‌هایی که به تازگی اجایل شده‌اند درپذیرش اینکه می‌توان نرم‌افزاری با کیفیت بالا را در هر Sprint ایجاد کرد با مشکل مواجه می شوند. آنها معمولا فاز تست را پس از کدنویسی انجام می دهند( به مشکل میخورند و نمیتونن خروجی در هر اسپرینت رو ایجاد کنند).

به اعضای تیم یادآور شوید که در پروژه های اسکرامی، کدنویسی(coding) و آزمایش(testing) به صورت همزمان انجام می‌شود(concurrently) به طوری که ویژگی قابل انتقال بودن(shippable) در هر iteration ایجاد می‌شود. در ابتدا برای بسیاری از تیم‌ها این مسئله یک چالش بزرگ است که منجر به یک آخر هفته مملو از اضطراب می‌شود به طوریکه در آن همه افراد مجبور به اضافه کاری هستند. تیم‌ها در نهایت راهی پیدا می‌کنند که امکان ارائه نرم‌افزار باکیفیت را در هر Sprint فراهم آورند، اما یادگیری نحوه انجام این کار اغلب نیازمند صرف تعداد انگشت شماری (یا بیشتر) Sprint است. این Sprint ها نیز ممکن است کوتاه باشند بنابراین تسلط در مهارت، در اسرع وقت امری ضروری است.

اسکرام مستر با سبک رهبری Participating برای بخش R3

زمانیکه تیم شروع به بهبود قابلیت‌های خود می‌کند، فرآیند خروج از ربع R2 آغاز می‌شود. تیم‌های R3 قادر به انجام کار به شیوه ای واقعاً اجایل هستند. به این ترتیب، در این ربع، یک اسکرام مستر خوب روش خود را به سبک رهبری participating تغییر می‌دهد و از میزان هدایت کار کم میکند و در عین حال رفتارهای مرتبط با ایجاد رابطه را افزایش می‌دهد.

به جای تصمیم گیری برای تیم بر اساس ورودی آن (مانند ربع R2/ selling)، تیم را تشویق کنید تا وظیفه گرفتن تصمیمات را برعهده بگیرد. این کار را در اسرع وقت انجام دهید – حتی قبل از اینکه تیم به این قابلیت جدید خود پی ببرد. در مواجهه با این افزایش مسئولیت‌ها، تیم‌های ربع R3 معمولاً به طور موقت دچار احساس عدم اطمینان می‌شوند. اما، بر خلاف تیم R1، تیم R3 از مهارت بسیار بالایی برخوردار است و می‌تواند به سرعت به یک تیم R4 تبدیل شود.

برای کمک به تیم در حرکت به سمت تصمیم گیری، به طور کامل از فرآیند تصمیم گیری خارج شوید.(move completely out of the decision-making process)

حضور شما برای تشویق و حمایت از تیم ضروری است اما برای اعضای آن کاملاً روشن کنید که تصمیم گیری با خود آنها است. طبیعی است که تیم ممکن است اشتباهاتی داشته باشد. اما، آیا این مسئله اهمیت دارد؟ اعضای تیم به یادگیری ادامه می‌دهند و سطح عملکرد آنها معمولاً بسیار بالا‌تر از R1 است به طوری که چند اشتباه بهای ناچیزی است که باید آن را بپردازند.

در زمان کار با یک تیم R3، اعضای آن را تشویق کنید تا خود گرفتن تصمیمات را برعهده بگیرند

زمانیکه تیم فرآیند خودسازماندهی(self-organize) را آغاز می‌کند و به توسعه مهارت‌های اجایل خود ادامه می دهد، اسکرام مستر طبیعتاً تمرکز کمتری بر روی عملکرد تیم دارد و بیشتر متمرکز بر عوامل مرتبط با وضعیت کلی خواهد بود. اعضای تیم به طرز دیوانه‌واری بر روی کار انتخاب شده برای iteration فعلی متمرکز خواهند شد – هدف کاری که بیش از یک تا چهار هفته طول نخواهد کشید. البته آنها ممکن است دارای یک  release plan باشند که احتمالاً کار سه یا چهار ماه آینده را پوشش می‌دهد، اما این طرح عمداً(deliberately) فاقد جزئیات کافی است. از آنجایی که آنها روی درخت‌های iteration فعلی(فیچر) متمرکز هستند، اعضای تیم باید به اسکرام مستر خود اعتماد کنند تا جنگل طولانی‌مدت‌تری (vision) را زیر نظر داشته باشند.

در این رابطه کارهایی هستند که اسکرام مستر می‌تواند انجام دهد.

ابتدا به دنبال مواردی باشید که باید در iteration فعلی برای آینده برنامه ریزی شوند.

به عنوان مثال، یک تیم ممکن است از برگزاری جلسه با یک متخصص واقف به امور شرکت در مورد یک فناوری خاص بهره‌مند شود. متأسفانه او در دفتری در فاصله ۲۰۰۰ مایلی کار می‌کند. به منظور رعایت دستورالعمل‌های مربوط به سفرهای کاری، بلیط او باید از دو هفته قبل خریداری شود. یا شاید در چندین Sprint، تیم قصد دارد user story خاصی را پیاده‌سازی کند که نیازمند مقدار مناسبی ورودی از سوی معاون فروش، معاون بازاریابی و مدیر کل بخش است. هماهنگی زمانی با آن سه نفر نیاز به برنامه ریزی قبلی دارد.

در مرحله بعد، اطمینان حاصل کنید که در هر Sprint تمرکز تقریباً بر روی user stories خاص از موضوعات بزرگ‌تری است که برای انتشار(release) انتخاب شده‌اند.

از آنجایی که Scrum امکان ارزیابی مجدد اولویت کار برنامه ریزی شده را در شروع هر Sprint فراهم می‌سازد، ممکن است PO و تیم به تدریج از آنچه که برای یک نقطه عطف یا انتشار(release) بزرگتر در نظر گرفته شده است دور شوند.

اگر این جابجایی عمدی و نتیجه به کار‌گیری تجربیات آموخته شده Sprint های قبلی باشد، می‌تواند امری بسیار عالی باشد. با این حال، اگر حاصل از دست دادن دید جنگل از سوی تیم و PO به علت تمرکز بیش از حد بر روی درختان باشد، به اصلاح مجدد(realign) پروژه کمک میکند.

آخرین اما نه کم اهمیت ترین مورد، اطمینان از کار کردن همیشگی تیم بر روی پروژه‌هایی با بالاترین ارزش ممکن(highest-valued work) است. یکی از راه‌های انجام این کار، پیشنهاد همکاری با PO برای اولویت‌بندی و تنظیم product backlog  با پیشرفت پروژه است.

اسکرام مستر با سبک رهبری Delegating برای بخش R4

بعد از رسیدن تیم به سطح آمادگی R4، سبک رهبری یک اسکرام مستر خوب از participating به Delegating تغییر خواهد کرد. در این مرحله، تیم نیازمند حداقل راهنمایی در زمینه کاری است. در صورت درخواست کمک، راهنمایی‌های لازم را ارائه دهید اما نحوه انجام کار را مشخص نکنید.

(but do not specify how work should be accomplished)

ابتدا، با نمایش نحوه به تعویق انداختن تصمیمات تا زمان ممکن، از واگذاری مسئولیت تصمیم گیری ها برای تیم فراتر بروید. وقتی یک تیم تصمیم گیری را به تعویق می اندازد،تیم گزینه‌های خود را باز نگه می‌دارد و می‌‌تواند از دانش جدید در تصمیم گیری نهایی استفاده کند. ما از توسعه دهندگان می‌خواهیم که این کار را با Design ها و کدهای خود انجام دهند. در یک پروژه Scrum، از آنها می‌خواهیم تنها مقدار کدهای لازم را برای پیاده‌سازی هر ویژگی بنویسند که بر روی آن کار می‌کنند(نه بیشتر و نه کمتر). ما از آنها نمی‌خواهیم که به‌طور فرضی لایه‌هایی از ویژگی‌های غیرضروری را بسازند که ممکن است «روزی» به آ‌نها نیاز داشته باشیم.

به عنوان مثال، فرض کنید یکی از شرکای ما قصد ارسال یک فایل تراکنش هفتگی را دارد که می‌خواهد در سیستم ما بارگذاری کند. ما هنوز نمی‌دانیم که آیا آن یک فایل CSV یا XML خواهد بود یا ویژگی‌های دیگری دارد. به جای نوشتن یک واردکننده که از هر سه ورودی پشتیبانی می‌کند، تصمیم‌گیری را به تعویق می‌اندازیم. این ممکن است به این معنی باشد که ما برای هیچ یک از واردکننده‌ها کد نویسی را انجام نمی دهیم. همچنین ممکن است به این معنی باشد که با این فرض کد نویسی را آغاز می‌کنیم که داده های ورودی از جایی می‌آیند و از آن قسمت دارای مشکل کدنویسی می‌کنیم.

زمان رسیدن تیم به سطح آمادگی R4، سبک رهبری یک اسکرام مستر خوب از participating به Delegating تغییر خواهد کرد

مهم‌ترین مولفه در تصمیم‌گیری، زمان بندی است. در روزهای اولیه معرفی جاوا، مدیریت پروژه‌ای بر عهده من بود که می‌توانست به عنوان یک کلاینت جاوا یا یک کلاینت محلی ویندوز ارائه شود. هر یک از رویکردها مزایا و معایب خود را داشت. ما به تازگی کار بر روی پروژه را آغاز کرده بودیم و «تصمیمگیری پلتفرم UI» در لیست مسائل باز قرار داشت. بنابراین، من از توسعه دهندگان اصلی دعوت کردم به سرعت در این مورد تصمیم گیری کنیم.

البته ما تصمیم اشتباهی گرفتیم. با این حال، حتی اگر پلتفرم دیگری را انتخاب کرده بودیم باز هم می‌گفتم که تصمیم اشتباهی گرفته بودیم. در این مورد، تصمیم درست به تعویق انداختن زمان تصمیم گیری بود. در روزهای اولیه شروع آن پروژه هیچ دلیلی برای گرفتن آن تصمیم وجود نداشت. مطمئناً باید تصمیم گیری انجام می‌شد اما در هفته دوم پروژه انجام این کار چندان درست نبود. بنابراین اجازه دهید تیم خود تصمیم گیری کند اما آنها را راهنمایی و به آنها توصیه کنید تا جایی که امکان دارد گرفتن تصمیمات را به تعویق اندازند.

نکته مهم بعدی، کار کردن بر روی به حداکثر رساندن(maximizing) نرخ توان کلی تیم است. اغلب به نظر می‌رسد پروژه‌ای که به‌طور سنتی مدیریت می‌شود، یک مسابقه‌ مانند مسابقه دو ده هزار متر یا یک مسابقه دوچرخه‌سواری ۵۰ مایلی  با خط پایان مشخص است. از سوی دیگر، Scrum بیشتر مانند مسابقه‌ای است که در آن مسئله مهم این است که مشخص شود در طی ۲۴ ساعت چقدر می‌توانید بدوید.

اغلب هیچ خط پایانی برای پروژه اسکرام وجود ندارد.

There’s often no finish line on a Scrum project.

در مقابل، بعد از اتمام زمان شما دست از فعالیت می‌کشید. در صورت نیاز به ویژگی‌های بیشتر، دوباره کار خود را ادامه می‌دهید. در غیر این صورت، شما کار خود را به صورت کامل انجام داده‌اید. این تمایز منجر به ایجاد تفاوت‌هایی در نحوه برخورد مدیران سنتی و تیم های اسکرام با پروژه های خود می‌شود.

مدیر پروژه سنتی به طور کامل بر روی دستیابی به یک هدف نهایی متمرکز است و مجموعه ای از عملکردها را در یک تاریخ خاص انتشار(releasing) می‌دهد. هیچ چیز فراتر از این هدف وجود ندارد. در ابتدا ممکن است این یک نقطه قوت برای مدیریت پروژه سنتی محسوب شود. با این حال، پاسخ احتمالی مدیر پروژه سنتی را زمانی در نظر بگیرید که یک توسعه‌دهنده یک ماه قبل از ضرب‌الاجل تعیین شده  با این نگرانی به او مراجعه و این مسئله را مطرح می‌کند که با وجود عملکرد صحیح کد در یک بخش، آسیب پذیر است و در چند ماه آینده به منبعی برای بروز مشکلات تبدیل خواهد شد. مدیر پروژه سنتی به احتمال زیاد یک تصمیم کوتاه مدت می‌گیرد و شانس خود را در رابطه با این کد آسیب پذیر امتحان می‌کند.

یک اسکرام مستر باید بیشتر به دنبال به حداکثر رساندن توان عملیاتی تیم باشد

با این وجود، یک اسکرام مستر باید بیشتر به دنبال به حداکثر رساندن توان عملیاتی تیم باشد. در موارد خاص، ممکن است تیم، یک ضرب الاجل یک ماهه را نسبت به refactoring کد آسیب پذیر ترجیح دهد. با این حال، به طور کلی، کار درست حفاظت از توان عملیاتی کلی تیم و سازماندهی مجدد کد(refactor the code) است. وظیفه اسکرام مستر تشویق و هدایت تیم در آن جهت و محافظت از آنها در برابر مخالفت‌های بیرونی است.

این تنها یک مثال از بسیاری از موارد دیگر است. تمایز اصلی در اینجا این است که پروژه سنتی تنها با هدف رسیدن به یک ضرب الاجل و کسب مجموعه‌ای مشخص از ویژگی ها مدیریت می‌شود. در مقابل، پروژه اجایل ممکن است از تعدادی ضرب الاجل‌های مختلف با قابلیت‌های وعده داده شده برخوردار باشد، اما توان عملیاتی پایدار تیم در بلند مدت نیز حائز اهمیت است.

استفاده از اسکرام مسترینگ موقعیتی

رهبری، مجموع تعاملاتی است که اسکرام مستر ها با تیم‌های خود دارند:

آنچه بیان می‌کنند، آنچه که نمی‌گویند، نحوه بیان و چگونگی گوش دادن.

مشخصه یک رهبر خوب تیم اسکرام فریاد زدن و گفتن «لعنت به اژدرها» نیست. همچنین مستلزم کناره گیری از تیم و اطلاع یافتن از به‌روزرسانی‌های روزانه اسکرام نیست. در مقابل، یک رهبر اجایل خوب – یک اسکرام مستر خوب – نیازمند آموختن است، اغلب اوقات در کنار تیم هایی که خودشان یاد می گیرند چگونه اجایل شوند.

افزایش مهارت‌های مورد نیاز برای تبدیل شدن به یک اسکرام مستر و کمک به یک تیم برای اجایل شدن کار چندان دشواری نیست. انجام این کار به داشتن یک چارچوب ذهنی در مورد آمادگی تیم و سبک رهبری مورد نیاز برای یک تیم خاص کمک می‌کند. مدل رهبری موقعیتی، این چارچوب را در اختیار ما قرار می‌دهد. از آنجایی که اعتماد و قابلیت‌های تیم‌ها با کسب موفقیت افزایش می‌یابد باید به روش‌های مختلف آنها را هدایت و راهنمایی کرد.

تیم‌های دارای توانایی محدود و اعتماد به نفس محدود(limited ability and limited confidence) معمولاً نیازمند یک سبک رهبری telling هستند. وقتی تیم‌های R1 را رهبری می‌کنید، معرفی Sprint های کوتاه مدت و آماده کردن تیم برای یک سری بردهای کوچک(small wins)، موجب افزایش اعتماد به نفس آنها می‌شود. روش‌های اساسی مرتبط با اجایل مانند افزایش تمرکز بر تست(testing) و continuous integration را معرفی کنید. با معرفی این روش‌ها، اعتماد تیم به مهارت‌ها و توانایی خود برای کار به شیوه‌ای جدید و اجایل‌تر افزایش پیدا می‌کند.

از آنجایی که اعتماد و توانایی تیم‌ها با کسب موفقیت افزایش می‌یابد، باید هدایت(led) آنها به روش‌های مختلفی انجام شود

یک تیم با توانایی‌های محدود اما متمایل و مطمئن، از سبک رهبری مربیگری بهره می‌برد. هنگام هدایت تیم‌های R2، به جای تمرکز صرف بر روی هدایت وظایف و کارها(just directing tasks)، به رابطه با اعضای تیم نیز توجه داشته باشید. تیمی با این ویژگی‌ها، برای بهبود مهارت‌های خود تنها به زمان، انگیزه و تمرین نیاز دارد.

به منظور فراهم آوردن فرصت‌هایی برای یادگیری، بر نیاز به تحویل(deliver) یک محصول (product) با کیفیت در پایان هر Sprint تاکید کنید. اعضای تیم از طریق کار در iteration های کوتاه و تمرکز بر ایجاد نرم افزار بالقوه قابل انتشار(releasable) در پایان هر iteration، قاعدتاً به دنبال راه هایی برای بهبود مهارت‌های خود خواهند بود.

تیم هایی که توانایی‌های آنها به طور قابل توجهی افزایش یافته است، از آمادگی بیشتری برای پذیرش سبک رهبری participating برخوردار هستند. با این حال، زمانی که وظیفه تصمیم گیری به خود تیم‌ها محول می‌شود، دست پاچه و عصبی می‌شوند و در مورد کافی بودن مهارت‌های تازه کسب شده‌ خود فکر می‌کنند. تیم‌های R3 را در طول این فرآیند انتقال با حمایت از آنها در زمان تصمیم گیری‌ها و تمرکز بر روی افق بلندمدت (۳ تا ۶ ماه) راهنمایی کنید و به تیم فرصت دهید تمام توجه خود را صرف Sprint فعلی کند.

یکی از راه‌های انجام این کار، اطمینان از تمرکز Sprint ها بر روی اهداف ارائه (نسخه)(release) بعدی حتی در صورت اولویت‌بندی مجدد کار هر Sprint در شروع آن است. در مقابل، اطمینان حاصل کنید که شرکت با همکاری با PO، کاری با ارزش را برای تیم انتخاب می‌کند و به این ترتیب مطمئن شوید که product backlog به درستی اولویت بندی می‌شود.

برای یک تیم خاص معرفی و اصلاح تکنیک‌ها در زمان مناسب امری ضروری است

برخی از اسکرام مستر ها از شانس بالای کار کردن با یک تیم R4 برخوردار هستند، تیمی ماهر(skilled) و متمایل(willing) که آماده ارتقا به سطوح بالاتری از مسئولیت است. در این موارد، سبک رهبری delegating را اتخاذ کنید. در پروژه های اسکرام، این امر شامل تمرکز بر به حداکثر رساندن توان عملیاتی در افقی فراتر از حدود یک پروژه است. همچنین به معنای کمک به تیم برای یادگیری زمان به تعویق انداختن تصمیمات است به شکلی که گزینه‌ها تا زمان ممکن در دسترس باشند.

برخلاف توصیه دوستم در بازی گلف که تنها «توپ را دورتر بزنید»، این مقاله به نکاتی می‌پردازد که با تکیه بر آنها یک اسکرام مستر می تواند به یک رهبر تاثیر‌گذار‌تر برای تیم اجایل تبدیل شود. با توجه به اینکه هر یک از تکنیک‌های ذکر شده در اینجا می‌توانند برای یک تیم با هر سطح از آمادگی مورد استفاده قرار گیرند، من آنها را با توجه به ویژگی سطوح آمادگی در جایی توصیف کرده‌ام که از نظر من بیشترین سود را به همراه دارند. معرفی و اصلاح تکنیک‌ها در زمان مناسب برای یک تیم خاص، بهترین روش برای یک اسکرام مستر است که از طریق آن می‌تواند به شاه کلید تیم R4 و سبک رهبری delegating دست یابد.