مدیریت همزمان چند پروژه کار آسانی نیست.
اما با مدیریت درست زمان، اولویت‌بندی اصولی و نهادینه کردن ارتباطات میان اعضای تیم، کاملا قابل اجراست.
اگر در حال اجرای چند پروژه به شکل همزمان بودید، چند دقیقه به این موارد فکر کنید و با آرامش و روشی درست جلو بروید.
ممکن است برای اینکه تیم به شفافیت لازم در task ها برسد زمان زیادی تلف شود.
به عنوان مثال چنانچه task ها پیش نیازی داشته باشند و scrum master این پیش نیازها را تهیه نکند، تیم نمی تواند کار خود را شروع کند.
برای این مشکل توصیه می شود که فرهنگی در تیم شکل بگیرد تا برای شروع یک task از استانداردی مشخص پیروی شود.
اگر scrum master کنترل زمان را نداشته باشد،
ممکن است اعضای تیم برای شفافیت task با یکدیگر بحث کنند تا به نتیجه برسند اما این موضوع باعث شود که اعضای دیگر خسته شوند و جلسه کسل کننده شود.
چنانچه یک فرد scrum master چند پروژه مختلف باشد، ممکن است برای راحتی کار جلسات این پروژه ها با هم برگزار بشوند، که اصلا توصیه نمی شود.
این ها مشکلاتی بود که ممکن است بخاطر scrum master بوجود بیاید.
زمانی قول کاری را به دیگران بدهید که حتماً با تیم خود در مورد آن مشورت کرده باشید.
شما هستید تا تیم خوب بنظر برسد نه {خود شما}. هرچند که ممکن است فکر کنید که اگر تیم خوب بنظر برسد، رئیس به این نتیجه خواهد رسید که دیگه به شما نیازی ندارد!!
اسکرام و اصول چابک هیچکدام با دستور العمل نیامدند. پس اعضاء تیم را با اجرای بدون چون چرای کتابها و نظرات دیگران که درباره اسکرام و اجایل نوشته شده است آزار ندهید و از بین نبرید. کافیست که به اصول و ارزش های چابک پایبند باشید.
هر چیزی که از تکراری شدن اوضاع جلوگیری می کند را تست کنید. از آزمایش چیزهای جدید نترسید.
یک نگاه یکپارچه یا تیم ورک را به بصورت فرهنگ تزریق کنید و واژه ما و آنها را از بین اعضاء تیم و ذی نفعان حذف کنید. بگذارید تیمی یکدست و همدل خلق شود تا معجزه آن شما را شگفت زده کند.
یک تعادل بین حجوم مالک محصول (ایجاد استرس،تزریق کار زیاد،آداب بعد و...) به افراد تیم و غرور کاذب اعضاء تیم برقرار کنید. این دو نکته مهم و کلیدی است که می تواند تیم را متلاشی کند. در مورد اول از افراد تیم محافظت کنید و در مورد دوم اعضاء تیم باید بدانند که همیشه نقطه بهبود وجود دارد و آنها آخرش نیستند.
شکستی وجود ندارد.
هر وقت پلن یا هدفی تعیین می شود که انجام نمی شود، این به معنی شکست نیست، بلکه تلاشی است که می شود آن را بهتر کرد.
از افراد تیم تشکر و قدردانی بجا و درست کنیم. (نه تملق)
اعضای تیم را دعوت کنید با کار و فسلفه کار شما بیشتر آشنا بشوند، حتی بخشی از کار شما را انجام بدهند.
شاید در اوایل کار لازم باشد همه جلسات را خودتان برگزار کنید، ولی می توانید کم‌کم از آنها بخواهید این کار را انجام بدهند.
در حدی که انگار به شما نیازی نیست،
لطفا ساکت باشید و گوش کنید.
از ساکت ماندن نترسید، بگذارید جواب از سمت تیم بیاید.
البته در عمل سخت است وقتی می بینید تیم گیر کرده است و نمی داند چه کند.
اما اگر تیم دائم به سخنرانی و پیشنهادات شما عادت داشته باشد، دچار مشکل خواهد شد.
البته به این معنی نیست که شما اصلا پیشنهاد ندهید، اما باید بدانیم که وظیفه اسکرام مستر این است که به تیم کمک کند تا مشکل را خودش حل کند.
این وقفه ها نباید در طول یک اسپرینت اتفاق بیافتد و باعث طولانی شدن اسپرینت بشوند.
در عوض اگر تا حد زیادی ضروری است می بایست اسپرینت توسط تیم کنسل شود.
بعبارت دیگر عامل وقفه باید در Product Backlog قرار بگیرد تا در اسپرینت جدید به آن رسیدگی شود.
مالک محصول می بایست از تمامی اعضای تیم در مورد تعیین راه حل برای مشکلاتی که ممکن است در پروداکت بک لاگ پیش آمد کند مشورت بگیرد و خودش نباید مستقیماً تصمیم گیری کند و لازم است به نظر تیم احترام بگذارد.
تیم توسعه اطلاع جامعی از نیازهای مشتری و اولویت بندی آنها بر اساس ROI ندارد.
پس در نتیجه تیم توسعه نمی تواند آیتم های پروداکت بک لاگ (Product Backlog) را اولویت دهی و سازماندهی کند.
این وظیفه مالک محصول (Product Owner) است که این کار را انجام بدهد.
تنها کاری که تیم می تواند در این قسمت انجام بدهد مشارکت با P.O در اولویت بندی هایی است که از لحاظ تکنیکالی باید جابجا شوند و امکان انجام آنها از لحاظ فنی نیست.
اسکرام به ما کمک می کنه تا از افراد تیم های خوبی بسازیم نه تیم هایی از افراد خوب بسازیم.
اگر محصول با ارزش و موفق است کل تیم در این موفقیت نقش داشته است.
اگر محصول شکست خورده باز کل تیم مقصر است.
ممکن است یکی از اعضای تیم را قهرمان موفقیت ها بدانیدکه این اشتباه است و
تیم تصمیم میگیرد که در طول یک اسپرینت (Sprint) چه کارهایی را می تواند انجام بدهد و در واقع توانش چقدر است.
هیچ کس نمی تواند به تیم فشار وارد کند تا حجم کار بیشتری را انجام بدهد.
در صورت وقوع این اتفاق، اعضای تیم آزرده خاطر خواهند شد و مطمئناً
Product Owner باید در جلسات اسکرام مانند Planning، Review و یا Daily حضور داشته باشد.
مالک محصول میبایست در طول زمان کاری فعال و در دسترس تیم باشد.
نبود Product owner تیم را دچار مشکل خواهد کرد.
بیکار بودن اسکرام مستر اشکالی ندارد،
می تواند فعالیت تیم را نظاره کرده و منتظر باشد تا مانعی اتفاق بیافتد تا ورود کند.
اما اگر Scrum Master بخواهد چون وقت اضافه یا خالی دارد در انجام یک Task مشارکت جدی داشته باشد و یا مسئولیتی از اعضای تیم توسعه را بعهده بگیرد
این باعث می شود تا از وظیفه اصلیش که برطرف کردن موانعی است که بر سر راه تیم ممکنه پیش بیاد و یا هر آنچه که در فعالیت تیم وقفه ایجاد میکنه دور بماند.
