این مقاله نوشتهی مایک کوهن (Mike Cohn)، یکی از چهرههای شناختهشده در حوزهی مربیگری تیمهای اجایل است. در این یادداشت، او به چهار اشتباه رایج Scrum Masterها میپردازد و با زبانی ساده و حرفهای، راهکارهایی برای اصلاح آنها پیشنهاد میدهد.
در ادامه، ترجمهی کامل این مقاله را به فارسی میخوانید:
اگر به تیم بیش از حد راهنمایی بدهید، ممکن است به شما وابسته شوند و انتظار داشته باشند که شما برای همه چیز تصمیم بگیرید. اما اگر راهنمایی کافی نکنید، رشد تیم متوقف میشود.
اگر خودتان بیشتر مشکلات را حل کنید، ممکن است تیم به این عادت کند که همیشه شما باید مسائل را حل کنید. از طرف دیگر، اگر بعضی از مشکلات را نادیده بگیرید، شاید حتی دیگر آنها را با شما در میان نگذارند.
یک Scrum Master باید تعادلی دقیق را حفظ کند، و بسیار آسان است که در این مسیر دچار اشتباه شود. در این مقاله، چهار اشتباه رایج Scrum Masterها را بررسی میکنم و برای هرکدام راهحلهایی عملی پیشنهاد میدهم.
اشتباه اول: اجازه دادن به انتقال کارهای ناتمام به Sprint بعدی
یکی از بدترین عاداتی که یک تیم Scrum میتواند پیدا کند این است که اجازه دهد بخشی از کار ناتمام باقی بماند و به Sprint بعدی منتقل شود. این اتفاق زمانی میافتد که تیم موفق نمیشود تمام آیتمهای برنامهریزیشدهی Product Backlog را در Sprint جاری تکمیل کند و بدون بررسی آنها را به Sprint بعدی منتقل میکند.
“یک تیم Scrum نباید برخوردی بیتفاوت نسبت به ناتمام ماندن کارها داشته باشد.”
درست است که ناتمام ماندن گاهی طبیعی، و حتی نشانهی برنامهریزی بلندپروازانه است، اما این نباید به یک روال تبدیل شود.
اگر این اتفاق تکرار شود، Sprint معنای خودش را از دست میدهد. دیگر یک چرخهی مشخص از کار نخواهد بود، بلکه به یک بازهی زمانی دلخواه تبدیل میشود. تیم باید در روزهای پایانی Sprint کمی حس فوریت داشته باشد.
اگر انتقال کار به Sprint بعدی در تیم شما به یک عادت تبدیل شده، دو پیشنهاد دارم. اول، در یکی دو Sprint آینده بسیار محافظهکارانه برنامهریزی کنید. تیم را تشویق کنید فقط به اندازهای کار انتخاب کند که کاملاً مطمئن است در همان Sprint میتواند تکمیل کند. اگر زودتر تمام شد، میتوان آیتمهای دیگری به Sprint اضافه کرد.
دوم، این موضوع را به شکل جدی در جلسهی Retrospective مطرح کنید و از تیم بخواهید دربارهی دلیل وقوع آن بحث کند. من نمیگویم که باید آنها را سرزنش کنید یا باعث دلسردیشان شوید. فقط میخواهم آنها به همان اندازهای که من نگرانم، نسبت به این موضوع حساس باشند.
من مثلاً در حال ترک نوشابه هستم. یک هفته است که هیچ نوشابهای نخوردهام. اما امروز، موقع نوشتن این مقاله، دلم خواست و یکی خوردم. احساس گناه نمیکنم، اما مطمئنم که فردا دوباره یکی دیگر نمیخورم. چون نمیخواهم دوباره وارد همان عادت قبلی شوم.
اشتباه دوم: اداره کردن جلسهی Daily Scrum
دومین اشتباه رایجی که از Scrum Masterها میبینم، این است که خودشان جلسهی Daily Scrum را اداره میکنند. درست است که حضور Scrum Master در این جلسه مهم است و باید بهروز باشد، اما این به این معنی نیست که نقش مجری جلسه را به عهده بگیرد و افراد را صدا بزند که صحبت کنند.
جلسه Daily Scrum نیازی به “پلیس راهنمایی” ندارد. اگر Scrum Master جلسه را به این شکل مدیریت کند، مکالمات به سمت او جهت پیدا میکنند. در حالی که این جلسه قرار نیست صرفاً برای اطلاعرسانی به Scrum Master باشد.
“در حالت ایدهآل، اگر یک ناظر خارجی جلسه را نگاه کند، نباید بتواند تشخیص دهد Scrum Master چه کسی است.”
وقتی تیم تازه کارش را شروع کرده، طبیعی است که Scrum Master در جلسات اولیه نقش فعالتری داشته باشد. اما هدف نهایی این است که تیم مالک جلسه باشد. حضور Scrum Master نباید جلسه را تحت کنترل او قرار دهد.
من معمولاً دو یا سه جلسهی اول را هدایت میکنم. بعد فقط جلسه را آغاز میکنم، مثلاً میگویم: “خب، وقت شروعه. چه کسی میخواهد اول صحبت کند؟” بعد از مدتی، حتی همین را هم نمیگویم. فقط ساعتم را نگاه میکنم و اگر لازم باشد، با یک اشاره کوچک مثل سرفهی آرام، جلسه را یادآوری میکنم.
طبیعتاً کاملاً ساکت هم نمیمانم. گاهی ممکن است کسی را تشویق کنم که بیشتر توضیح دهد یا اگر صحبتها خیلی انحراف پیدا کردند، مودبانه یادآوری کنم که: “شاید بهتر باشه بعد از جلسه عمیقتر وارد این موضوع بشیم.”
اشتباه سوم: اجازه دادن به Burnout در تیم
سومین اشتباه این است که Scrum Master اجازه میدهد تیم از توانش بیشتر کار کند و به مرور دچار فرسودگی یا Burnout شود.
من علاقهای به برخی از واژههای رایج در Scrum ندارم، و واژهی Sprint یکی از بدترینهاست. وقتی من در حال دویدن سریع هستم، خیلی زود خسته میشوم و باید مدتی راه بروم تا ریکاوری کنم.
این دقیقاً همان چیزیست که ما نمیخواهیم برای تیم اتفاق بیفتد. در دنیای ایدهآل، یک Sprint باید بدون خستگی به Sprint بعدی متصل شود. تیمها نباید در حالی Sprint جدید را آغاز کنند که هنوز در حال بازیابی از Sprint قبلی هستند.
“تیمها نباید Sprint جدید را در حالی شروع کنند که هنوز از Sprint قبلی در حال ریکاوری هستند.”
مشکل Burnout معمولاً زمانی اتفاق میافتد که تیمها هنگام برنامهریزی Sprint با خوشبینی بیش از حد تعهد میدهند. این خوشبینی ممکن است از میل به موفقیت ناشی شود، اما نتیجهاش خستگی مداوم خواهد بود.
برای جلوگیری از این وضعیت، Scrum Master باید بهدقت توجه کند که آیا تیم دارد بیش از توان واقعیاش در Sprint تعهد میدهد یا نه.
یکی از راههای مؤثر برای پیشگیری، صحبت با Product Owner دربارهی اختصاص دادن زمانی برای کارهای مورد علاقهی خود تیم است. من معمولاً مدلی را معرفی میکنم به نام “6 x 2 + 1”.
این مدل یعنی شش Sprint دو هفتهای، و سپس یک Sprint یک هفتهای. کاری که در آن Sprint یک هفتهای انجام میشود، کاملاً در اختیار خود تیم است.
“کاری که تیم در Sprint یک هفتهای انجام میدهد، کاملاً به انتخاب خودش بستگی دارد.”
بعضی از اعضای تیم ممکن است این زمان را صرف یادگیری یا دیدن آموزشهای ویدیویی کنند. بعضی دیگر ممکن است کدی را refactor کنند که در اولویت نبوده، و یا روی یک ایدهی خلاقانه کار کنند. انتخاب با تیم است.
این مدل حتی برای Product Owner هم مفید است، چون یک هفته بدون “مزاحمت” از سمت تیم خواهد داشت و میتواند تمرکز کند. همین مزیت معمولاً دلیلیست که Product Owner را برای اجرای این مدل قانع میکند.
از دید سازمانی هم این مدل کارکرد دارد. مثلاً اگر سازمان بخواهد قول بدهد که در مدت ۳ ماه مجموعهای از قابلیتها تحویل داده میشود، میتوان آن Sprint آزاد را به Sprint کاری تبدیل کرد. بعد از رسیدن به موعد تحویل، تیم میتواند مجدداً از آن Sprint آزاد استفاده کند.
اشتباه چهارم: فرار از مکالمات دشوار
در اکثر مواقع ScrumMaster باید در گفتوگوهایی شرکت کند که ممکن است سخت یا ناخوشایند باشند؛ از مطرح کردن مشکلات تکرارشونده گرفته تا اصلاح برداشتهای نادرست دربارهی شیوههای Agile. فرار از این مکالمات باعث میشود مشکلات حلنشده باقی بمانند و روحیهی تیم آسیب ببیند.
باید بپذیرید که این گفتوگوها بخشی طبیعی از ساختن یک تیم شفاف و با عملکرد بالا هستند. فکر کنید چه سؤالهایی میخواهید بپرسید، چطور وارد بحث شوید، و سعی کنید چند سناریو را از قبل تمرین کنید—چه با یک همکار ScrumMaster یا حتی با یک ابزار هوش مصنوعی.
به دیدگاههای مختلف فکر کنید و با ذهنی باز وارد گفتوگو شوید. اگر این مکالمهها را فرصتی برای رشد و ساختن اعتماد ببینید، میتوانند نتیجههای فوقالعادهای داشته باشند.
سخن پایانی
یک Scrum Master حرفهای کسی است که بین هدایت و استقلال تعادل ایجاد میکند، حمایت میکند بدون آنکه کنترلگر باشد، جلسهها را تسهیل میکند بدون آنکه بر آنها مسلط شود، و از گفتوگوهای دشوار فرار نمیکند.
