Scrum Mastery

From Good to Great Servant Leadership

Scrum Mastery

توضیحات

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

نظر

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

نظر

امتیاز : 09/10
به دیگران توصیه می‌کنم : بله
دوباره می‌خوانم : بله
ایده برجسته : توانمندسازی تیم به جای کنترل آن، و هدف‌گذاری برای این‌که تیم به جایی برسد که دیگر به اسکرام‌مستر نیاز نداشته باشد، حتی اگر همچنان بخواهد حضورش را داشته باشد
تاثیر در من : درک عمیق‌تری از نقش اسکرام‌مستر و این‌که چطور می‌تواند تیم را به سطوح بالاتر از عملکردی که با اسکرام ممکن است، برساند
نکات مثبت : مثال‌های واقعی و داستان‌های تجربی از تیم‌های مختلف اسکرام، راهنمایی عملی برای تبدیل شدن به یک اسکرام‌مستر عالی، تأکید بر اهمیت احترام، فروتنی و integrity در نقش اسکرام‌مستر
نکات منفی : نیاز به دانش قبلی از اسکرام

مشخصات

نویسنده : Geoff Watts
انتشارات : Addison-Wesley Professional
صفحه مشخصات : goodreads

بخش‌هایی از کتاب

۱. ماهیت قدرت اسکرام‌مستر

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

نتیجه‌ی منطقی این وضعیت این است که تنها منبع «قدرت» اسکرام‌مستر احترام و اعتماد دیگران است، نه پُست سازمانی. اگر تیم و افراد بانفوذ سازمان به اسکرام‌مستر احترام نگذارند، او عملاً در حذف موانع، تسهیل جلسات سخت و طرح سؤال‌های چالشی فلج می‌شود.

۲. احترام به‌عنوان سرمایه‌ی کار اسکرام‌مستر

نویسنده چند ویژگی برای اسکرام‌مسترهای واقعاً محترم لیست می‌کند: آن‌ها رابطه‌های قوی با تیم دارند، خیلی سریع و عمیق با دیگران «رابطه و اعتماد» می‌سازند و همین باعث می‌شود در موقعیت‌های سخت بتوانند فضا را مدیریت و بحث‌های دشوار را تسهیل کنند. این احترام باعث می‌شود وقتی اسکرام‌مستر سؤال‌های ناراحت‌کننده می‌پرسد (سؤال‌هایی که تیم را وادار به خودانتقادی می‌کند)، تیم به‌جای دفاعی شدن، وارد تأمل و گفت‌وگو شود.

یک پیام ضمنی مهم این فصل این است که اگر اسکرام‌مستر صرفاً «دوست‌داشتنی» باشد ولی محترم و قابل‌اعتماد نباشد، در نقش خودش شکست می‌خورد؛ ترجیح، احترام و اعتماد است، نه صرفاً محبوبیت.

۳. انتخاب اسکرام‌مستر توسط تیم

نویسنده یک کارگاه واقعی را توصیف می‌کند: بعد از روشن کردن مسئولیت‌های ScrumMaster، از ۲۵ نفر می‌خواهد روی کارت‌های جداگانه بنویسند چه کسی را برای این نقش مناسب می‌دانند؛ ۲۳ نفر همان یک نفر را انتخاب می‌کنند. این الگو در کارگاه‌های مختلف تکرار شده و نکته‌ی کلیدی‌اش این است که تیم‌ها به‌طور شگفت‌آوری در تشخیص کسی که «می‌تواند بهترینِ ما را بیرون بکشد» هم‌نظر هستند، و انتخاب‌شان معمولاً با انتخاب مدیریت فرق دارد.

از این‌جا نویسنده استدلال می‌کند که چون تیم زیر دست ScrumMaster نیست (برعکس، بیشتر ScrumMaster در خدمت تیم است)، منطقی است اسکرام‌مستر را تیم انتخاب کند و حتی اگر به‌عنوان servant‑leader خوب عمل نمی‌کند، تیم بتواند او را عوض کند. این نگاه، ScrumMaster را به‌معنای واقعی «خدمت‌گزار رهبر» می‌بیند؛ کسی که مشروعیتش از اعتماد تیم می‌آید، نه از انتصاب بالا به پایین.

۴. فروتنی (Humility) به‌عنوان هسته‌ی احترام

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

نویسنده یک تمرین عملی پیشنهاد می‌کند: برای تمرین آگاهانه‌ی فروتنی، کمک خواستن و اعتراف به جاهایی که در دانش یا مهارت‌مان خلأ داریم. این ضد نقش «قهرمان همه‌کاره» است؛ اسکرام‌مستر محترم با پذیرفتن محدودیت‌های خودش، فضایی می‌سازد که دیگران هم بتوانند بدون ترس از قضاوت، ضعف‌ها را مطرح کنند.

۵. Integrity و کاهش عدم‌قطعیت

بخش پایانی این قسمت، احترام را به integrity گره می‌زند: صداقت، ثبات، قابل‌اعتماد بودن و داشتن یک کد اخلاقی قوی. وقتی آدم‌ها بدانند از شما چه انتظاری می‌توانند داشته باشند، معمولاً هم خود شما و هم این پیش‌بینی‌پذیری را قدردانی می‌کنند؛ اسکرام در ذات خود عدم‌قطعیت زیادی را وارد سیستم می‌کند (نیازمندی‌ها، نقش‌ها، سلسله‌مراتب، شغل‌ها) و داشتن کسی که مثل «سنگ استوار وسط طوفان» باشد برای تیم بسیار ارزشمند است.

نویسنده به یک مطالعه‌ی fMRI اشاره می‌کند: در مواجهه با ابهام و عدم‌قطعیت، همان نواحی مغز فعال می‌شوند که با درد فیزیکی فعال می‌شوند؛ یعنی عدم‌قطعیت واقعاً برای مغز دردناک است. بنابراین قطعیت رفتاری اسکرام‌مستر (قول‌های کوچک، عمل کردن به آن‌ها، و عذرخواهی بی‌بهانه وقتی انجام نشد) نه فقط اخلاقی، بلکه از نظر روان‌شناختی هم برای تیم مسکنِ اضطراب است.

تا این‌جا ایده‌ی اصلی فصل «Respected» را پوشش دادیم:
اسکرام‌مستر چون قدرت رسمی ندارد، باید روی احترام، فروتنی، integrity و انتخاب/پشتیبانی تیم تکیه کند، وگرنه عملاً بی‌اثر است.

۱. ایده‌ی مرکزی: توانمندسازی، نه کنترل

نویسنده این بخش را با یک تمایز مهم شروع می‌کند:
یک اسکرام‌مستر خوب برای تیم «غیرقابل‌جایگزین» است؛
یک اسکرام‌مستر عالی به جایی می‌رسد که هم «قابل‌جایگزین» و هم «خواستنی» است.

یعنی هدف نهایی تو این نیست که تیم همیشه به تو وابسته بماند، بلکه برعکس:

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

نویسنده می‌گوید یکی از موثرترین راه‌ها برای کسب احترام این است که عمداً کنترل را به‌دست نگیری، حتی وقتی می‌توانی.

۲. فرمان اول: همیشه اول از تیم بپرس

اولین «فرمان» اسکرام‌مستر این است:

هر سؤالی، هر مشکلی، هرقدر هم سخت؛ پاسخ پیش‌فرض تو باید این باشد:
«اول از تیم می‌پرسم فکر می‌کنن باید چه‌کار کنیم.»

نویسنده تأکید می‌کند که واکنش ناخودآگاه بیشتر آدم‌ها این است که بلافاصله بروند روی مود «حل مسئله»:
«خب جواب چیه؟ من چی‌کار کنم؟» اسکرام‌مستر باید برعکس عمل کند؛ به‌جای این‌که خودش جواب بدهد،

سؤال را برگرداند به تیم،
و از آن‌ها بخواهد هم برای مسائل واقعی و هم سناریوهای انتزاعی فکر کنند و درس دربیاورند.

این فقط برای پیدا کردن جواب نیست، برای ساختن ماهی‌گیری است:

تیم یاد می‌گیرد خودش مسئله را صورت‌بندی کند.
یاد می‌گیرد بین گزینه‌ها انتخاب کند.
و کم‌کم ذهنیت «وابستگی به اسکرام‌مستر» جایش را به «مسئولیت جمعی» می‌دهد.

نویسنده برای تقویت این مهارت مثال Phil Jackson (سرمربی سابق Bulls و Lakers) را می‌آورد که با تکنیک‌های غیرمستقیم (مثلاً دادن کتاب یا ویدئو و درخواست کشف پیام برای رشد تیم) بازیکنان را وادار به تأمل و خودآموزی می‌کرد، نه فقط اجرای دستور.

۳. فرمان دوم: خودت را از نقش بی‌نیاز کن

فرمان دوم، رادیکال‌تر است:

با نیت این وارد نقش شو که وجود اسکرام‌مستر برای این تیم، در نهایت «لازم» نباشد.

تعریف این وضعیت ایده‌آل:

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

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

این همان ایده‌ی اصلی servant‑leadership است: معیار موفقیت تو این نیست که «چند کار را خودت انجام داده‌ای»، بلکه این است که:

آیا «خدمت‌گیرندگان» (تیم) در طول مسیر سالم‌تر، آگاه‌تر، آزادتر، خودمختارتر و تبدیل به servant‑leaderهای جدید شده‌اند یا نه.

۴. معنای عملی «قابل‌جایگزین و خواستنی بودن»

قبل از این‌که وارد داستان Chris و استعاره‌ی Shu‑Ha‑Ri شویم، بد نیست این دو فرمان را کمی زمینی کنیم:

از نگاه نویسنده، اسکرام‌مستر عالی باید عملاً روی این‌ها کار کند:

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

ایده‌ی مهم: اگر تیم بدون تو از هم می‌پاشد، این نشانه‌ی اهمیت تو نیست؛
نشانه‌ی این است که در کارِ توانمندسازی، موفق نبوده‌ای.

۱. موقعیت Chris و Team Hurricane

Chris اسکرام‌مستر تیمی به نام Hurricane است که به پایان اسپرینت بیستم‌شان نزدیک شده‌اند. او به برن‌داون‌ها و خروجی رِتروسپکتیوهای قبلی نگاه می‌کند و یک «احساس گرمای درونی» دارد؛ حس غرور از این‌که این گروه آدم، واقعاً به یک تیم بالغ تبدیل شده‌اند، شاید بهترین تیمِ کل ۱۵ سال کار حرفه‌ای‌اش.

نویسنده عمداً گذشته را یادآوری می‌کند:

اسپرینت‌های اول خیلی سخت بوده است.
اختلاف جدی بین اعضا (مثلاً Benny و Carl که Chris شک داشته بتوانند اصلاً در یک ساختمان کار کنند، چه برسد به یک تیم).
اسپرینت ریویوهایی که سرعت تیم آن‌قدر پایین بوده که Chris می‌ترسیده پروژه را کنسل کنند.
حتی لحظه‌ای که تیم می‌خواسته کلاً Scrum را رها کند و برگردد به Waterfall.

در آن دوران ابتدایی، Chris مجبور بوده برای کوچک‌ترین چیزها انرژی عظیمی بگذارد:

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

۲. نقطه‌ی بلوغ: وقتی دیگر «لازم» نیستی

حالا که بیست اسپرینت گذشته، فضا کاملاً عوض شده است:

فردا Chris می‌رود مرخصی زایمان (میدان جنگ را ترک می‌کند)،
اما تیم هنوز حتی مطمئن نیست آیا لازم است کسی را جای او بیاورند یا نه؛ قرار است این را در رِتروسپکتیو بعدی خودشان بحث کنند.
تیم خودش از قبل تصمیم گرفته که در رِتروسپکتیو بعدی روی چه چیزهایی کار کند؛ یعنی بدون فشار بیرونی، چرخه‌ی بهبود مستمر را مالک شده است.
Product Owner (سافرون) همین حالا کنار تیم است و دارد فیچرهای اخیر را مرور و تأیید می‌کند؛ این یعنی رابطه‌ی نزدیک PO–تیم، بدون این‌که لازم باشد اسکرام‌مستر وسط ایستاده باشد.

Chris با این نشانه‌ها «مطمئن است» تیم بدون او هم خوب پیش خواهد رفت، حتی اگر وسط اسپرینت او را از دست بدهند. نکته‌ی کلیدی:

اگر مهمانی خداحافظی بزرگ نبود، Chris می‌توانست بی‌سر و صدا از شرکت خارج شود و تیم همچنان خوب کار کند.
او کاری را انجام داده که خیلی‌ها ناممکن می‌دانند: آن‌قدر در نقش خود خوب بوده که دیگر حضورِ تمام‌وقتِ خودش لازم نیست.

این همان تحقق عملیِ دو فرمان قبلی است:

سال‌های اول، مدام «از تیم می‌پرسیده» و آن‌ها را درگیر تصمیم‌گیری می‌کرده.
کم‌کم خودش را از کارهای روزمره کنار کشیده و تیم را به خودکفایی رسانده، تا جایی که الآن تیم «مالک فرایند» و «مالک رابطه با PO» است، نه Chris.

۳. انگیزه‌ی عمیق: چرا باید خودت را «اضافی» کنی؟

نویسنده این سؤالِ طبیعی را مطرح می‌کند:

«چرا باید خودم را زائد کنم؟ مگر دیوانه‌ام؟»

پاسخ‌اش دو لایه دارد:

از منظر servant‑leadership:
- معیار موفقیت تو این است که «آیا کسانی که به آن‌ها خدمت می‌کنی، در طول خدمت، سالم‌تر، داناتر، آزادتر و خودمختارتر شده‌اند و خودشان هم به خدمت‌گزارانی برای دیگران تبدیل شده‌اند یا نه».
- این دقیقاً همان معیار Greenleaf است که نقل‌قولش را می‌آورد.
از منظر حرفه‌ای و شغلی:
- اگر بتوانی صادقانه در رزومه بنویسی «یک تیم و سازمان را آن‌قدر چابک و پرفورمنس‌بالا کردم که دیگر به من نیاز نداشت»، احتمالاً در بازار کار، این بهترین نوع تبلیغ برای توست.
- نویسنده به‌صراحت می‌گوید اگر خودت را واقعاً redundant کنی، آن‌قدر تقاضا برایت هست که «بی‌نیاز شدن تیم» کوچک‌ترین نگرانی‌ات نخواهد بود.

پس paradox ظاهری هست: برای این‌که در نقش‌ات «به‌شدت ارزشمند» باشی، باید عملاً وابستگی دیگران به خودت را کم کنی، نه زیاد.

این‌جا نویسنده بلافاصله می‌پرد به استعاره‌ی Shu‑Ha‑Ri و بعد هم Nanny McPhee تا همین منطق «بمان تا وقتی لازم‌اند، برو وقتی دیگر نیاز نیست» را از زاویه‌ی یادگیری نشان بدهد.

۱. Shu‑Ha‑Ri چیست؟ (لایه‌ی یادگیری)

نویسنده از مفهوم ژاپنی Shu‑Ha‑Ri برای توصیف مراحل یادگیری استفاده می‌کند و آن را با فیلم The Karate Kid توضیح می‌دهد.

مرحله Shu (پیروی بی‌چون‌وچرا)

در فیلم، Mr. Miyagi به Daniel واقعاً «کاراته یاد نمی‌دهد»؛
به‌جایش او را مجبور می‌کند ماشین تمیز کند، با حرکت تکراری wax on / wax off. وقتی Daniel می‌پرسد چرا باید این کار را بکند، جواب می‌شنود:

«من می‌گم، تو انجام می‌دی… بدون سؤال.»

این مرحله Shu است:

تمرکز روی تقلید دقیق شکلِ تمرین است، بدون این‌که لزوماً فلسفه‌ی پشت آن را بفهمی.
هدف، ساختن muscle memory است؛ یعنی بدنت و ذهنت، الگوها را ناخودآگاه اجرا کنند.

در لحظه‌ی حمله (اسپویل)، Daniel ناگهان به‌طور خودکار همان حرکت wax on / wax off را برای دفاع استفاده می‌کند و تازه آن‌جاست که معنای تمرین تکراری را می‌فهمد.

مرحله Ha (شکستن شکل، حفظ اصل)

بعد از این epiphany، Daniel وارد مرحله Ha می‌شود:

حالا می‌فهمد چرا این تمرین‌ها مهم بوده‌اند،
شروع می‌کند به سؤال پرسیدن درباره‌ی مکانیک‌ها و پیدا کردن راه‌های جدید برای تجسم همان اصول. در Ha، معلم شروع می‌کند به تشویق دانشجو برای این‌که قوانین را با امنیت بشکند، نه این‌که کورکورانه از آن‌ها پیروی کند.

مرحله Ri (فراتر از فرم و معلم)

در نهایت دانشجو به مرحله‌ی Ri می‌رسد:

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

در Ri، تو به‌جای این‌که Scrum را «اجرا کنی»، به اصولش فکر می‌کنی و راه مناسب خودت را می‌سازی.

۲. تطبیق Shu‑Ha‑Ri روی تیم‌ اسکرام و نقش اسکرام‌مستر

نویسنده خیلی صریح می‌گوید این استعاره برای تیم‌های اسکرام و نقش ScrumMaster بسیار قابل‌تطبیق است.

تیم در حالت Shu

در ابتدای کار:

تیم تازه با Scrum آشنا شده،
عمدتاً روی “کتاب‌خوانی” و اجرای مکانیکی رویدادها متمرکز است (اسپرینت پلنینگ، دیلی، رِترو، برن‌داون، Definition of Done و غیره).
نقش اسکرام‌مستر این‌جا شبیه Mr. Miyagi است:
«من می‌گم، شما انجام می‌دید، سؤال نکنید» به این معنا که فعلاً روی انضباطِ فرم تمرکز کن، نه خلاقیت در شکستن فرم.

اگر خیلی زود تیم را درگیر «تغییر Scrum» یا «فلسفه‌بافی» کنی، هنوز حتی basic muscle memory را ندارد و کار خراب می‌شود.

تیم در حالت Ha

بعد از چندین اسپرینت، وقتی:

تیم روتین‌ها را خوب بلد است،
خروجی نسبتاً پایدار دارد،
و شروع می‌کند به سؤال‌پرسیدن از خود فرایند («آیا لازم است دیلی حتماً ۱۵ دقیقه باشد؟»، «آیا این نوع تخمین برای ما جواب می‌دهد؟»).

اینجا تیم وارد Ha شده است:

اسکرام‌مستر باید خودش تیم را تشویق کند که امن و آگاهانه بعضی قواعد را بشکنند؛ مثلاً فرمت دیلی را عوض کنند، رِتروهای خلاقانه‌تر بسازند، یا Sprint Goal را به‌شکل دیگری تعریف کنند.
تمرکز از «اجبار به رعایت فرم» به «درک اصول و بومی‌سازی» جابه‌جا می‌شود.

تیم در حالت Ri

در Ri:

تیم به‌خوبی می‌فهمد چرا inspect & adapt مهم است،
می‌داند چرا transparency و feedback loop حیاتی است،
و بدون اسکرام‌مستر هم می‌تواند خودش فرایند را طراحی و تطبیق دهد.

اینجاست که ایده‌ی «خودت را زائد کن» شکل واقعی می‌گیرد:

یک ScrumMaster عالی، تیم را به Ri می‌رساند تا جایی که تیم دیگر به اسکرام‌مستر نیاز ساختاری نداشته باشد، حتی اگر همچنان از حضورش استقبال کند.

۳. استعاره Nanny McPhee: «وقتی به من نیاز دارید ولی نمی‌خواهیدم…»

نویسنده بعد از Karate Kid، فیلم Nanny McPhee را هم وارد بازی می‌کند. در این فیلم، آقای Brown همسرش را از دست داده و هفت بچه‌ی به‌شدت بدرفتار دارد؛ چندین پرستار شکست می‌خورند تا این‌که Nanny McPhee می‌آید.

او در بدو ورود به بچه‌ها می‌گوید:

«یک چیزی هست که باید درباره‌ی شیوه‌ی کارم بفهمید.
وقتی به من نیاز دارید ولی نمی‌خواهیدم، باید بمانم.
وقتی می‌خواهیدم اما دیگر به من نیاز ندارید، باید بروم. این کمی غم‌انگیز است، اما همین است.»

او با تغییر قانون‌ها و محدود کردن آزادی‌های قبلی، اقتدار بچه‌ها را به چالش می‌کشد؛ طبیعتاً بچه‌ها از او متنفر می‌شوند. اما در ادامه، همین قانون‌ها و فرایندها باعث می‌شوند بچه‌ها یاد بگیرند و رفتارشان را تغییر دهند؛ آن‌قدر که در پایان نمی‌خواهند او برود، ولی او «کارش را انجام داده» و باید برود.

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

اول می‌آید، وقتی تیم واقعاً «نیاز» دارد اما شاید Scrum و محدودیت‌هایش را «نمی‌خواهد».
قانون‌ها، رویدادها و شفافیت را تحمیل می‌کند (در حد سالم)، در نتیجه ممکن است در ابتدا محبوب نباشد.
اما هدف‌اش این است که تیم را از Shu به Ha و بعد Ri ببرد، جایی که دیگر به حضور او نیاز حیاتی ندارند.
آن لحظه‌ای که تیم واقعاً نمی‌خواهد او برود اما دیگر به‌طور ساختاری به او وابسته نیست، لحظه‌ی موفقیت نهایی اوست.

۴. پیام مستقیم برای اسکرام‌مستر

نویسنده صریح می‌پرسد:

«چرا باید بخواهم خودم را زائد کنم؟»

و جواب می‌دهد:

چون اگر بتوانی صادقانه بگویی:
«من تیم و سازمانی را آن‌قدر چابک و پرفورمنس‌بالا کردم که دیگر به من نیاز نداشتند»،
این برای حرفه‌ی تو، یک مزیت رقابتی عظیم است.
و از نظر اخلاقی/رهبری هم دقیقاً همان معیار Greenleaf است:
آیا کسانی که به آن‌ها خدمت کردی، در حین خدمت، رشد کردند یا نه؟

پس Shu‑Ha‑Ri و Nanny McPhee، هر دو در خدمت تثبیت همین ایده‌اند:

اول سخت‌گیر و فرآیندمحور باش (Shu)،
بعد آگاهانه تیم را به سمت شکستن اصول در جهت بهتر کردن کار هدایت کن (Ha)،
و در نهایت، آماده‌ی رفتن باش وقتی تیم به Ri رسیده است، حتی اگر دلت بخواهد بمانی.

۱. شعار ظاهری: «حفظ هماهنگی»؛ تفاوت خوب و عالی

عنوان فصل می‌گوید:

اسکرام‌مستر خوب کمک می‌کند تیم «هماهنگ» بماند.
اسکرام‌مستر عالی تیم را از دلِ «ناهماهنگی و تعارض» عبور می‌دهد تا به یک سطح جدید از کار تیمی برسد.

نویسنده به Patrick Lencioni و کتاب Five Dysfunctions of a Team ارجاع می‌دهد و نقل‌قولی را برجسته می‌کند:

«تیم‌های بزرگ از همدیگر چیزی پنهان نمی‌کنند…
از این‌که لباس‌های چرک‌شان را رو کنند نمی‌ترسند؛
اشتباهات، ضعف‌ها و نگرانی‌های‌شان را بدون ترس از تلافی مطرح می‌کنند.»

کل پیام این است: هدف اسکرام‌مستر، حفظ صلحِ ظاهری نیست، بلکه ساختن فضایی است که در آن، تعارض‌های واقعی می‌توانند با احترام مطرح و حل شوند.

۲. داستان تیم Jedis: مشکل Avis و سکوت خطرناک

تیم Jedis در میانه‌ی اسپرینت اول‌شان با Scrum هستند؛ اولین پروژه‌ای است که با هم کار می‌کنند و تازه دارند ریتم کاری پیدا می‌کنند. اسکرام‌مستر آن‌ها، Darryl، هم در Scrum تازه‌کار است اما به خاطر مهارت‌های انسانی انتخاب شده؛ کسی که سابقه‌ی «دور هم جمع کردن آدم‌ها برای کار تیمی خوب» را دارد.

وضعیت:

اسپرینت پلنینگ بد نبود؛ تیم احساس می‌کند کمیت اسپرینت شدنی است.
در طول اسپرینت، هرکس روی کارهایی که برای خودش برداشته تمرکز دارد، اما همکاری واقعی کم است؛ بیشتر کار فردی با هماهنگی حداقلی.
مشکل اصلی، Avis است (بیزنس آنالیست):
- اغلب به دیلی اسکرام دیر می‌رسد،
- طی روز هم پیدا کردنش سخت است وقتی تیم سؤال دامنه/بیزنس دارد.

تیم اما به‌جای این‌که این را بهانه کند، طبق آموزش «Self‑organizing» خودش با دور زدن او مسئله را حل می‌کند:

گاهی مستقیماً با PO صحبت می‌کنند،
گاهی با همکاران Avis،
گاهی خودشان «حدس می‌زنند» و جلو می‌روند.

اما در دیلی، دیررسیدن Avis مسئله‌ساز است:

هر بار ۵–۱۰ دقیقه دیر می‌رسد،
تیم مجبور می‌شود برایش خلاصه‌ی صحبت‌های قبلی را تکرار کند،
و Darryl حس می‌کند ناراحتی و کینه در حال انباشته شدن است، در حالی‌که هیچ‌کس بلند نمی‌گوید.

در رِتروسپکتیو، Darryl موضوع را باز می‌کند:

از تیم می‌پرسد: «به‌نظر شما دیلی‌ها چطور بود این اسپرینت؟»
Avis اول از همه با رضایت می‌گوید: برای من عالی بود، کمک کرد بفهمم بقیه چه می‌کنند!
وقتی Darryl از بقیه می‌پرسد آیا برای شما هم مفید بود، همه ساکت می‌شوند.

اینجاست که Darryl یک مهارت مهم را به‌کار می‌گیرد: سکوتِ ناراحت‌کننده.

صبر می‌کند،
وقتی حس می‌کند باید چیزی بگوید، کمی دیگر هم صبر می‌کند.
در نهایت Amie یخ را می‌شکند و می‌گوید شاید ساعتِ برگزاری برای Avis مناسب نیست چون اغلب جای دیگری است.

Darryl از این نخ استفاده می‌کند و بحثی درباره‌ی زمان شروع دیلی و میزان انعطاف تیم در ساعت‌ها باز می‌کند؛ تیم خوشحال می‌شود چون راهی پیدا کرده که بدون مواجهه‌ی مستقیم با Avis، رفتارش را عوض کند.

اما در اسپرینت بعد، Avis همچنان دیر می‌آید؛
تیم این‌بار سیستم جریمه می‌گذارد (مثلاً هر نفر دیر بیاید ۱ پوند جریمه، Avis هم یک روز با اسکناس ۲۰ پوندی می‌آید که پیش‌پیش جریمه‌ها را بدهد!). نتیجه: تیم پیامش را درباره‌ی «وقت‌شناسی» رسانده، اما هیچ کمکی به همکاری واقعی نشده است.

۳. تحلیل نویسنده: سطح مسئله را کم‌عمق گرفتند

نویسنده توضیح می‌دهد Darryl در رِتروسپکت اول چند کار خوب کرد:

تلاش کرد موضوع را از زبان خود تیم بیرون بکشد، نه با تحمیل نظر خودش.
از سکوت ناراحت‌کننده استفاده کرد تا کسی بالاخره صحبت کند.
وقتی Amie و Avis حرف زدند، از آن‌ها تشکر علنی کرد تا مشارکت‌آینده را تشویق کند.

با این‌حال دو مشکل:

خیلی دیر وارد عمل شدند؛ منتظر رِتروسپکت ماندند، در حالی‌که Scrum تشویق می‌کند هر روز بازرسی و تطبیق فرایند را انجام دهید، نه فقط در پایان اسپرینت. تیم عملاً یاد گرفته بود «تغییر فقط در رِترو اتفاق می‌افتد»، که خطرناک است.
فقط به اولین پیشنهاد سطحی چسبیدند (تغییر ساعت، بعد جریمه) و عمیق‌تر نرفتند:
- Avis در طول روز هم «در دسترس نبودن» را نشان می‌داد.
- سؤال‌های اساسی مثل «کجاست؟ روی چه کار می‌کند؟ آیا واقعاً عضوی از تیم است یا تعهد دیگری دارد؟» نادیده گرفته شد.

نویسنده می‌گوید این‌ها نشانه‌های disengagement بودند و لازم بود ریشه‌شان کاویده شود؛ مثلاً با تکنیک‌هایی مثل ۵ Why، البته با احتیاط، چون می‌تواند دفاعی‌بودن فرد را تحریک کند.

۴. مراحل شکل‌گیری تیم (Tuckman) و معنی «آرامش سطحی»

در ادامه، نویسنده وضعیت تیم Jedis را با مدل Tuckman توصیف می‌کند:

تیم در مرحله‌ی Forming است:
- آدم‌ها می‌خواهند پذیرفته شوند،
- از تعارض و اختلاف جدی پرهیز می‌کنند،
- فشار ددلاین هنوز جدی نیست،
- همه روی «نجات فیس‌سِیوینگ» حساس‌اند.

این مرحله هم‌زمان «راحت» و «آزاردهنده» است:

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

نویسنده می‌گوید تیم‌های Scrum، به‌خاطر Cross‑functional بودن و خودسازمان‌ده بودن و ماهیت تکرارشونده‌ی تحویل، معمولاً خیلی سریع‌تر و با نوسان بیشتر از مراحل Tuckman عبور می‌کنند؛ پس اسکرام‌مستر باید برای هدایت سریع تیم از Forming به Storming و بعد Norming/Performing آماده باشد.

نقطه‌ی تمایز اسکرام‌مستر خوب و عالی این‌جاست:

اسکرام‌مستر خوب تعارض‌ها را سریع و آسان حل می‌کند تا تیم زودتر به «آرامش» برگردد.
اسکرام‌مستر عالی از تعارض استفاده می‌کند تا تیم را یک لِول بالاتر ببرد، حتی اگر این مسیر دردناک و زمان‌بر باشد.

این کار معمولاً نیاز دارد:

کمک به تیم برای شفاف‌سازی ارزش‌های فردی،
و ساخت یا اصلاح ارزش‌ها و هنجارهای تیمی مشترک (Team Norms)،
تا جایی که تعارض‌ها بر مبنای ارزش‌های مشترک حل شوند، نه فقط با مخفی‌کردن ناراحتی.

۵. ابزارها: Norms، دونات و شنا رفتن!

نویسنده چند تاکتیک رایج برای مقابله با تأخیر در Daily را مثال می‌زند:

قفل‌کردن در اتاق سر ساعت.
خریدن یک دونات کمتر از تعداد اعضای تیم.
جریمه‌های فانتزی: کلاه کابوی، شنای سوئدی، یا حتی «بقیه تیم شنا می‌روند و متخلف نگاه می‌کند» (سبک ارتش!).

پیامش این است که این‌ها می‌توانند نشانه‌ی تشکیل هنجار تیمی باشند، اما کافی نیستند؛
نقش اسکرام‌مستر این است که:

فقط به اولین راه‌حل بسنده نکند،
موضوع را زودتر از رِترو هم بالا بیاورد اگر به کار تیم لطمه می‌زند،
به تیم کمک کند هنجارهایی را که خودشان ساخته‌اند، خودشان هم اجرا و از هم مطالبه کنند.

اما باید حواسش هم باشد:

تیم‌ها معمولاً در اوایل رشدشان، نمی‌فهمند دقیقاً چقدر بالغ‌اند؛
اسکرام‌مستر گاهی مجبور است تیم را در «ناحیه‌ی ناراحتی سالم» هل بدهد: نه آن‌قدر که بشکند، نه آن‌قدر کم که رشد نکند.

اگر بخواهم خلاصه‌ی مهندسی‌اش را بگویم:

«هماهنگی بدون حقیقت» = Anti‑Pattern.
اسکرام‌مستر عالی باید شجاعت به‌هم‌زدن این آرامشِ دروغین را داشته باشد، اما با احترام و طراحی، نه با مشت‌کوبی روی میز.

۱. صورت مسئله: تعهد وقتی شخصاً می‌نویسی

نویسنده از یک تحقیق در NHS (سیستم درمانی انگلستان) شروع می‌کند:
وقتی بیماران تاریخ نوبت را خودشان روی کارت می‌نوشتند و نه منشی، میزان «نیامدن به نوبت» حدود ۱۸٪ کم شد. Cialdini این را به تمایل انسان به سازگار بودن با تصویری که از خودش دارد ربط می‌دهد: وقتی خودت چیزی را می‌نویسی، بیشتر حس می‌کنی «این قولِ من است».

نویسنده می‌گوید تیم‌های اسکرام هم همین‌طورند:

همه‌ی گروه‌ها زیر مجموعه‌ای از قواعد نوشته و نانوشته کار می‌کنند (working agreements).
تیم‌هایی که این توافق‌ها را واقعاً می‌نویسند و مالک آن هستند، بیشتر به آن پایبند می‌مانند و خودشان همدیگر را پاسخ‌گو می‌کنند.

۲. داستان Blue Peter: قوانین روی دیوار، بی‌اثر روی رفتار

تیم Blue Peter اسکرام‌مستر جدیدی به نام Vince دارد. در اولین Sprint Planning از تیم می‌پرسد: «برای این‌جور جلسه‌ها چه قوانینی دارید؟ دوست دارید چطور تسهیل شوید؟»
تیم چند قانون می‌گوید:

سر وقت شروع و تمام کنیم.
نظر همه شنیده شود.
«ایده‌ی احمقانه» وجود ندارد.
حواس‌پرتی با موبایل/لپ‌تاپ نداشته باشیم.
تصمیم‌ها را با consensus بگیریم.

Vince این‌ها را روی فلیپ‌چارت می‌نویسد، می‌چسباند به دیوار و جلسه شروع می‌شود.

نیم ساعت بعد:

Janet لپ‌تاپ‌اش را باز می‌کند و در حال جواب‌دادن به ایمیل‌هاست.
بقیه‌ی تیم به او، بعد به برگه‌ی قوانین روی دیوار، بعد به Vince نگاه می‌کنند؛ انگار می‌گویند: «خب حالا چی‌کار می‌کنی؟».

Vince کمی فکر می‌کند؛ هم از این‌که Janet عملاً به تیم و جلسه و تعهد خودش بی‌اعتنایی کرده ناراحت است، هم از این‌که چرا بقیه چیزی نمی‌گویند. بعد بحث را باز می‌کند:

جلسه را متوقف می‌کند و می‌گوید برگردیم به working agreements.
رو به Janet می‌گوید: «می‌بینم الان پشت لپ‌تاپی، و چندبار هم دیدم وسط حرف همدیگر را قطع می‌کنید. هر دو رفتار با قوانینی که این‌جا نوشتیم نمی‌خواند.» Janet سریع عذرخواهی می‌کند و لپ‌تاپ را می‌بندد.

اما Vince بلافاصله تأکید می‌کند قصدش «خورد کردن» Janet نیست:

می‌گوید: «تو تنها کسی نیستی که این قوانین را شکسته، فقط آخرینی که دیدمش.»
و سؤال اصلی‌اش را از کل تیم می‌پرسد:
«آیا این توافق‌ها واقعاً رفتارِ موردنظرتان را نشان می‌دهد؟
چون شما نه‌فقط دارید قوانین خودتان را می‌شکنید،
بلکه هیچ‌کس هم دیگری را بابتش پاسخ‌گو نمی‌کند.
اگر من این‌جا نبودم، معمولاً چه‌کار می‌کردید؟»

تیم فقط به هم نگاه می‌کند و شانه بالا می‌اندازد؛ یعنی هیچ الگوی درونی برای گرفتنِ تعهد از همدیگر ندارند.

۳. جابه‌جا کردن «پلیسِ قوانین» از اسکرام‌مستر به خود تیم

Vince ادامه می‌دهد:

می‌گوید اگر قرار است این‌ها واقعاً قوانین شما باشند، باید خودتان همدیگر را نسبت به آن‌ها مسئول بدانید.
بحثی را تسهیل می‌کند درباره‌ی این‌که چرا قوانین را نوشته‌اند ولی اجرا نمی‌کنند.

از دل بحث درمی‌آید:

برخی مثل Janet توضیح می‌دهند که مدیران‌شان انتظار پاسخ فوری به ایمیل دارند و همین آن‌ها را به استفاده از لپ‌تاپ در جلسه هل می‌دهد.
بقیه می‌پذیرند این فشار واقعی است، اما هنوز معتقدند «حواس‌پرتی الکترونیکی» باید محدود شود.
با هم راه‌حل‌هایی مثل استراحت منظم ایمیل، یا اتوماتیک‌سازی پاسخ‌ها پیشنهاد می‌دهند تا هم به قانون‌شان پایبند بمانند، هم از نظر مدیران خودشان به‌موقع پاسخ دهند.

همچنین درباره‌ی قاعده‌ی «همه باید مجال صحبت داشته باشند» حرف می‌زنند و روی اهمیتِ صبر برای نوبت و نپریدن وسط حرف دیگران تأکید می‌کنند.

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

۴. بازتعریف توافق‌ها: نوشتن، رأی دادن، امضا کردن

تیم از Vince می‌خواهد تمرین working agreements را از نو اجرا کند. این‌بار Vince چند نکته‌ی مهم را رعایت می‌کند:

یادآوری می‌کند فقط رفتارهایی را وارد کنید که واقعاً می‌خواهید و توانِ تعهد به آن را دارید.
برای هر رفتار پیشنهادی، از تیم می‌خواهد اثر آن روی تیم را توضیح بدهند (یعنی «چرا مهم است»).

برای جمع‌کردن توافق، تیم از کارت‌های DECIDE™ استفاده می‌کند:

برای هر قانون پیشنهادی، هرکس سطح حمایت خودش را نشان می‌دهد (دفاع می‌کند، می‌پذیرد، بی‌تفاوت است، رد می‌کند و …).
بعد از کمی بحث و شفاف‌سازی، قوانینی که اکثر تیم یا از آن‌ها دفاع می‌کند یا حداقل می‌پذیرد روی فلیپ‌چارت نوشته می‌شود.
Vince مطمئن می‌شود هر نفر شخصاً حداقل یک قانون را خودش بنویسد؛ همان ایده‌ی «خودت بنویسی، بیشتر پایبند می‌مانی».
در انتها، همه‌ی اعضا برگه را امضا می‌کنند و آن را جای برگه‌ی قبلی روی دیوار می‌زنند.

این‌جا اسکرام‌مستر از نقش «پلیس بیرونی» می‌آید بیرون و تیم را وادار می‌کند خودش صاحبِ قانون و صاحبِ enforcement باشد.

۵. تفاوت اسکرام‌مستر خوب و عالی در پاسخ‌گویی

نویسنده می‌گوید:

اسکرام‌مستر خوب بدون تعارف، افراد را بابت شکستن تعهدات‌شان (مثلاً دیر رسیدن، حواس‌پرتی، زیر پا گذاشتن DoD) صدا می‌زند.
اما اسکرام‌مستر عالی یک لِول عقب‌تر می‌ایستد و خودِ تیم را بابت این‌که همدیگر را پاسخ‌گو نمی‌کنند، مسئول می‌گیرد.

اگر فقط خودت مرتباً تذکر بدهی، دو اتفاق می‌افتد:

نقش‌ات تبدیل می‌شود به «وجدانِ بیرونی تیم» و آن‌ها عادت می‌کنند تشخیص و برخورد را به تو واگذار کنند.
به‌محض این‌که تو نباشی، هنجارها فرو می‌ریزد؛ یعنی خودسازمان‌دهی واقعی شکل نگرفته است.

در عوض، اگر کاری کنی که خود اعضا همدیگر را – با احترام – پاسخ‌گو کنند:

هم پایبندی به هنجارها بیشتر می‌شود،
هم تیم یک گام بزرگ به سمت خودمدیریتی واقعی برمی‌دارد.

۶. فرهنگ بازخورد: بدون آن، پاسخ‌گویی ممکن نیست

نویسنده در ادامه روی فرهنگ فیدبک زوم می‌کند:

بازخورد صادقانه دادن به کسی که به تو «خیانتِ کوچک» کرده (مثلاً قانون مشترک‌تان را لگدمال کرده) سخت است.
پذیرفتن فیدبک انتقادی از هم‌تیمی هم سخت است.
اما اگر تیم این مهارت را یاد نگیرد، امکان ندارد بتواند همدیگر را بابت توافق‌ها پاسخ‌گو کند بدون این‌که رابطه‌ها نابود شود.

او مثال می‌زند که همه می‌گویند «فیدبک صبحانه‌ی قهرمانان است»، اما در عمل یا بلد نیستند، یا آماده نیستند، یا اصلاً حاضر نیستند فیدبک واقعی بدهند/بگیرند.

یک مدل ساده معرفی می‌کند: AID از کتاب The Tao of Coaching:

Actions: دقیقاً چه کاری انجام شده؟ (خوب یا بد)
- تمرکز روی رفتار، نه روی شخصیت.
Impacts: این رفتار چه اثری داشته؟ (از زاویه‌ی «من»، نه «همه می‌گن…»).
Desired outcomes: شکل مطلوب چه‌طور است؟ اگر خوب باشد، چه شکلی است؟

در داستان Blue Peter:

رفتار Janet: چک‌کردن ایمیل وسط جلسه.
اثر: حواس بقیه پرت می‌شود و تمرکز از بحث می‌رود.
نتیجه‌ی مطلوب: پیدا کردن سازوکاری (استراحت ایمیل و autoresponder) که همه بتوانند با تمرکز کامل در جلسه باشند و در عین حال به الزامات مدیران پاسخ دهند.

نویسنده مثال‌های دیگری از ابزار فیدبک مثل WILATI («What I Like About That Idea Is…») و The Perfection Game هم می‌آورد و می‌گوید این‌ها پله‌ی خوبی برای عادت‌دادن تیم به فیدبک مداوم هستند.

جمع‌بندی مفهومی این بخش:

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

۱. نقش اصلی: توانمندساز، نه انجام‌دهنده

نویسنده با نقل‌قولی از Harry Truman شروع می‌کند:

«شگفت‌انگیز است که چه‌قدر می‌شود کار انجام داد، اگر اهمیتی ندهی که چه‌کسی اعتبارش را می‌گیرد.»

بعد می‌گوید اسکرام‌مستر خیلی بیشتر یک «Enabler» است تا یک «Doer»:

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

نشانه‌های یک Enabler خوب:

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

۲. تعریف «Enable» و وظیفه‌ی عملی اسکرام‌مستر

نویسنده به TheFreeDictionary.com استناد می‌کند که فعل enable را این‌طور تعریف می‌کند:

فراهم‌کردن وسیله، دانش یا فرصت؛ «توانا کردن».
ممکن و شدنی کردن.

ترجمه‌ی این برای اسکرام‌مستر یعنی:

بفهمی بزرگ‌ترین دردهای تیم در کار روزمره چیست،
یکی را انتخاب کنی که با کم‌کردن یا حذفش، اثرگذاری تیم را زیاد می‌کند،
و بعد با تمام توان، موانع را در سطح تیم و سازمان برداری.

برای این کار باید بدانی «کار در سازمان واقعاً چطور جلو می‌رود»:

در عمل، برای هر نوع مشکل باید درِ کدام اتاق را بزنی،
چه کانال‌هایی برای گرفتن تصمیم یا حل مسئله واقعاً مؤثرند (نه فقط روی کاغذ). این مهارت شبکه‌سازی سازمانی، یکی از تفاوت‌های کلیدی بین اسکرام‌مستر معمولی و عالی است.

نویسنده یک تیپ عملی هم می‌دهد:

«Battle mapping» را امتحان کن: نقشه‌ای از ساختار رسمی و غیررسمی سازمان، رابطه‌ها، قدرت‌ها و حوزه‌های نفوذ بکش تا بدانی برای چه مشکلی سراغ چه کسی بروی.

۳. روی تاریک «توانمندسازی»: Enabling منفی و White Knight Syndrome

نکته‌ی هوشمندانه‌ی این فصل این است که همان واژه‌ی enable یک معنای منفی هم دارد:

«رفتاری که باعث می‌شود الگوهای سوءاستفاده‌گرانه، اعتیادآور یا خودتخریب‌گر دیگری تداوم یابد.»

ترجمه‌ی این برای نقش اسکرام‌مستر:

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

نویسنده این را White Knight Syndrome می‌نامد:

اسکرام‌مستر مثل شوالیه‌ی سفید، دائماً سوار اسب می‌شود و تیم را از هر خطر و زحمتی نجات می‌دهد.
نتیجه: تیم کم‌کم یاد می‌گیرد خودش مسئله را حل نکند و برای هر چیز کوچک به تو نگاه کند.

پس دو نوع Enabling داریم:

مثبت:
- موانع را برمی‌داری، ولی در عین حال تیم را درگیر حل مسئله و یادگیری می‌کنی.
- استقلال و agency تیم را زیاد می‌کنی.
منفی:
- دائماً سریع‌ترین مسیر را خودت می‌روی،
- فشار را از روی تیم برمی‌داری،
- اما در عمل، قدرت یادگیری و مسئولیت‌پذیری‌شان را تضعیف می‌کنی.

وظیفه‌ی اسکرام‌مستر عالی این است که فرم مثبت را تقویت و از فرم منفی آگاهانه دوری کند؛ یعنی:

همدلی داشته باشد،
در عین حال، تیم را در «منطقه‌ی رشد» نگه دارد، نه در «منطقه‌ی آسایشِ وابستگی».

۱. ایده‌ی اصلی: مواظب اثرگذاری خودت باش

تیتر فصل این است:

اسکرام‌مستر خوب حواسش هست که زیاد روی تیم اثر نگذارد.
اسکرام‌مستر عالی می‌تواند «طبیعی» رفتار کند و مطمئن باشد تیم باز هم تصمیم‌های خودش را می‌گیرد.

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

۲. ابزار تیم Divas: «Bulls**t Buzzer»

نویسنده مثالی از تیمی به نام Divas می‌آورد. این تیم در Daily Scrum از یک ابزار ساده استفاده می‌کند:

یک دکمه / بوق (Bulls**t Buzzer).
هر زمان هر عضو احساس کند کسی در حال مبهم‌گویی، زیاده‌گویی، استفاده از ژارگون یا نگفتنِ چیزهای واقعاً مهم برای تیم است، می‌تواند بوق را بزند.
هدف: برگرداندن صحبت به چیزی که برای تیم مفید و شفاف است، نه قطع‌کردنِ آدم‌ها از روی لجبازی.

نکته‌ی مهم: این ابزار فقط برای اعضای تیم نیست؛ روزی ممکن است خودِ اسکرام‌مستر هم «بوق» بخورد.

۳. داستان Fin، Jaime و Theo

در یکی از دیلی‌های Divas، اسکرام‌مستر تیم، Fin، دارد گزارش می‌دهد:

می‌گوید دیروز برای مشکل تماس با Vendor چند ایمیل زده و یک پیام صوتی گذاشته است.
در این لحظه Jaime دکمه را می‌زند: «BUZZZZZ…» و می‌گوید:
«ایمیل و ویس‌میل؟ جدی؟ فکر نمی‌کنی می‌توانی بهتر از این عمل کنی؟»

Fin بدون دفاع عصبی، می‌پذیرد:

می‌گوید مشغله زیاد باعث شده راهِ آسان را انتخاب کند و پیگیری بعد از ظهر را هم فراموش کرده،
بعد تعهد می‌دهد که امروز حتماً جواب Vendor را بگیرد و اگر لازم شد شخصاً تا شرکت‌شان رانندگی کند.

این صحنه دو پیام دارد:

تیم به خودش اجازه می‌دهد اسکرام‌مستر را هم پاسخ‌گو کند.
Fin از این بازخورد ناراحت نمی‌شود؛ این یعنی authorityِ او در نقش اسکرام‌مستر، تیم را مرعوب نکرده است.

بعد نوبت Theo است، عضو جدید تیم. او می‌گوید دیروز درباره‌ی پارامترهای ذخیره‌سازی یاد گرفته و امروز می‌خواهد «درباره‌ی upload facility اطلاعات بیشتری به‌دست بیاورد»؛ جمله‌اش خیلی مبهم است.

Fin متوجه ابهام می‌شود، اما چون Theo تازه‌وارد و خجالتی به‌نظر می‌رسد، در همان لحظه او را publicly زیر بوق نمی‌برد؛ صبر می‌کند Daily تمام شود و بعد خصوصی با او صحبت می‌کند:

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

Theo همچنین تجربه‌ی بدی از شرکت قبلی دارد:

آن‌جا «مدیر چابک» طوری وانمود می‌کرد دوست دارد واقعیت را بشنود،
اما اگر کسی از مشکل یا گیر خودش حرف می‌زد، بعداً آن را علیه‌اش نزد مدیریت استفاده می‌کرد.
حالا وقتی می‌بیند Jaime همان بوق را روی خود Fin هم می‌زند، می‌فهمد این‌جا Daily status report به مدیر نیست، گفت‌وگوی تیمی صادقانه است.

Fin به او توضیح می‌دهد:

این‌جا هدف، گزارش‌دادن به من نیست؛
ما داریم با هم «share» می‌کنیم، نه «report».
از کمک‌خواستن نترس، و آماده باش که خودت هم یک روز بوق بخوری؛ این بخشی از فرهنگ تیم است.

۴. نشانه‌های یک تیم سالم در این داستان

نویسنده چند نشانه‌ی سلامت را برجسته می‌کند:

بوق زدن برای اسکرام‌مستر
- این یعنی تیم، اسکرام‌مستر را «رئیس» و بالادست نمی‌بیند.
- رابطه‌ی قدرت flatten شده و فضای برابری در feedback وجود دارد.
حساس‌بودن به وضعیت عضو جدید
- Fin و احتمالاً بقیه می‌دانند که Theo هنوز با فرهنگ تیم آشنا نشده؛
- به‌جای این‌که همان ابتدا او را publicly بوق بزنند،‌ Fin انتخاب می‌کند اول اعتماد و رابطه بسازد.
آماده‌بودن برای بازبینی Normها با ورود آدم جدید
- نویسنده پیشنهاد می‌کند وقتی عضو جدید می‌آید، هنجارهای تیم را مرور کنید:
  - شاید چیزی که برای تیم «شوخی بامزه» است برای او تهدیدآمیز باشد،
  - شاید لازم باشد توضیح بدهید چرا این کار را می‌کنید و چه مرزی دارد.
استفاده از Pairing برای ادغام عضو جدید
- pairing با چند نفر مختلف هم سرعت یادگیری Theo را بالا می‌برد، هم رابطه‌ها را می‌سازد.
تغییر تمرکز در Daily از «نفرمحوری» به «کارمحوری»
- نویسنده پیشنهاد می‌دهد گاهی Daily را به‌جای «نفر به نفر»، بر اساس آیتم‌های Product Backlog جلو ببرید؛
- این کار تمرکز را از فرد برمی‌دارد و روی کار می‌گذارد، که برای تازه‌واردها هم راحت‌تر است.

۵. جمع‌بندی: تیمی که می‌تواند با اسکرام‌مستر «راحت» باشد

نویسنده در پایان می‌گوید:

تیمی که با هم و با اسکرام‌مستر خود احساس راحتی و امنیت می‌کند، پتانسیل رسیدن به یک حالت واقعاً High‑performing را دارد.
وقتی اسکرام‌مستر بتواند تیم و افراد را با سؤال‌ها و مشاهده‌های قوی به چالش بکشد، و تیم این‌ها را «در سطح ظاهر» بپذیرد نه این‌که نیت‌خوانی و دفاع کند، این ورودی‌ها تبدیل می‌شوند به نقاط تأمل برای رشد جدی.

در واقع، Bulls**t Buzzer فقط یک ابزار نمادین است؛
پیام اصلی این است که:

اسکرام‌مستر عالی تیم را به جایی می‌رساند که خودِ تیم، خودِ اسکرام‌مستر و همدیگر را در لحظه «align» نگه دارند،
بدون این‌که کسی از قدرت رسمی بترسد یا سکوت کند.

۱. صورت مسئله: «اسکرام خوبه، فقط PO نداریم!»

نویسنده می‌گوید بارها از تیم‌ها شنیده:

«Scrum خیلی هم خوب بود، اگر فقط یک Product Owner درست‌وحسابی داشتیم!»

مسائل رایج:

اصلاً PO ندارند.
PO اشتباه است (کسی که قدرت تصمیم‌گیری یا نمایندگی کسب‌وکار را ندارد).
یا PO درست است، ولی یا نمی‌شود با او خوب ارتباط گرفت، یا در طول اسپرینت اصلاً در دسترس نیست.

۲. داستان تیم Oscars و Phillip: وقتی PO فقط سر Review پیدایش می‌شود

تیم Oscars یک Product Owner به نام Phillip دارد، اما در طول اسپرینت دسترسی چندانی به او نیست:

Phillip قبلاً Business Analyst بوده و عادت داشته نیازمندی‌ها را روی کاغذ تحویل بدهد.
وقتی تیم در طول اسپرینت سؤال دارد، او می‌گوید: «همه‌چیز داخل User Story نوشته شده؛ اگر چیزی هست در Sprint Review می‌گیم.»

در یکی از Sprint Reviewها، Jimmy (عضو تیم) فیچر migration را دمو می‌کند.
Phillip وسط دمو می‌پرسد:

«چیـه این؟ این اون چیزی نیست که من خواسته بودم!»

Jimmy که شوکه شده، دفاع می‌کند:

«ولی دقیقاً چیزی که تو Story نوشته بودی را پیاده کردیم: انتقال کاربران فعال به سیستم جدید.»

Phillip توضیح می‌دهد:

از نظر متن، شاید درست باشد،
اما منظورش این بوده که فقط کاربران گروه A–D به نوع حساب اصلی منتقل شوند و بقیه به نوع حساب ثانویه؛ چیزی که در Story نیامده بوده.

Jimmy می‌گوید:

«ما در طول اسپرینت نتوانستیم ازت سؤال کنیم، پس به متن Story چسبیدیم.»

ScrumMaster تیم، Frank، پیشنهاد می‌دهد موضوع را در رِتروسپکتیو باز کنند؛ فعلاً فیچر را یا Rollback کنند یا نگه دارند برای اصلاح. Phillip می‌گوید این‌طوری قابل‌دیپلوی نیست و باید Rollback شود.

۳. راه‌حل موقت: Proxy Product Owner

در رِتروسپکتیو، موضوع اول بحث، نبودنِ Phillip در طول اسپرینت است:

Phillip می‌گوید دوست دارد بهتر کمک کند، ولی واقعاً نمی‌تواند وقت کافی برای جواب دادن به همه‌ی سؤالات تیم آزاد کند.

Frank راه‌حل رایج را پیشنهاد می‌کند: Proxy PO:

کسی که روزانه کنار تیم است،
می‌تواند نیازمندی‌ها را توضیح دهد،
و تصمیم‌هایی را از طرف PO بگیرد.
Frank به‌صراحت می‌گوید:
اگر بر اساس توضیح‌های Proxy چیزی بسازیم که بعدها با خواسته‌ی واقعی تو نخورد، این دیگر مشکل تو و Proxy است؛ ما طبق ورودی موجود عمل کرده‌ایم.

Phillip موافقت می‌کند کسی را به‌عنوان Proxy معرفی کند.
اما در اسپرینت بعد، با وجود Proxy، باز هم در Sprint Review سوءتفاهم‌های جدی بیرون می‌زند.

۴. کار اسکرام‌مستر عالی: نشان دادن «هزینه‌ی واقعی Proxy»

Frank این‌بار آماده‌تر است؛ برای رِتروسپکتیو بعدی با یک تحلیل هزینه می‌آید:

زمان صرف‌شده برای تلاش‌های بی‌فایده،
کار دوباره (rework)،
زمان منتظر ماندن برای تصمیم، و… .

او این‌ها را جمع می‌زند، در روز ضرب‌در هزینه‌ی روزانه‌ی Scrum Team می‌کند و به Phillip نشان می‌دهد:

«نبودن تو در طول اسپرینت، حتی با وجود Proxy، هزینه‌ی واقعی و قابل‌محاسبه دارد. این عدد کوچک نیست؛ این خودش یک Business Case برای آزاد کردن وقت توست.»

Phillip و Frank این داده‌ها را پیش مدیریت می‌برند و آن‌ها را قانع می‌کنند که مدل Proxy مناسب نیست. مدیران تصمیم می‌گیرند:

بخشی از کارهای Phillip را به یک نفر دیگر بدهند (مثلاً کمک در Testing و مدیریت Backlog)،
تا خود Phillip بتواند در طول اسپرینت با تیم تعامل مستقیم داشته باشد.

نتیجه:

تیم شروع می‌کند به ساختن فیچرهایی که واقعاً همان چیزی هستند که Phillip می‌خواهد.
رابطه‌ی Phillip و تیم از حالت «مشتری/واحد تحویل» به حالت همکاری و اعتماد دوطرفه نزدیک می‌شود؛ راه‌حل‌هایی خلق می‌کنند که هیچ‌طرف به‌تنهایی نمی‌توانست به آن برسد.

۵. پیام برای اسکرام‌مستر: Proxies مُسکن‌اند، نه درمان

نویسنده پس از این داستان چند نکته مهم می‌گوید:

Product Ownerها از چند جهت زیر فشارند:
- درون سازمان: Stakeholderهای مختلف، مدیریت، تیم‌های دیگر.
- بیرون سازمان: مشتریان، بازار، deadlineها.
  در نتیجه خیلی راحت overload می‌شوند و معمولاً فقط برای آماده‌کردن Backlog و حضور در Review وقت می‌گذارند.
بسیاری از POها به این بسنده می‌کنند که Backlog را مرتب نگه دارند و سر Sprint Planning و Review باشند؛
اما در طول اسپرینت غایب هستند، و تیم مجبور می‌شود روی متن Story قمار کند.
Manifesto می‌گوید: ارزش «همکاری با مشتری» بیش از «قرارداد» است؛ نقش PO تلاشی است برای آوردن گفت‌وگو وسط اسپرینت، نه این‌که تیم فقط به کارت User Story تکیه کند.
Proxy شاید موقتاً فاصله را کم کند، اما مسئله‌ی اصلی را حل نمی‌کند:
- هنوز معلوم نیست چرا PO این‌قدر درگیر است که نمی‌تواند وقت بگذارد.
- آیا روی چند محصول کار می‌کند؟
- آیا تیم PO ندارد؟
- آیا بخش زیادی از اسپرینت را صرف Testing و Bug Report می‌کند؟

اسکرام‌مستر خوب هر کاری می‌کند که تیم «به یک PO دسترسی داشته باشد».
اسکرام‌مستر عالی پا را فراتر می‌گذارد: قبول نمی‌کند رابطه‌ی تیم و PO همیشه از فیلتر خودش یا Proxy بگذرد؛
هدفش این است که خود تیم و PO دست در دست هم کار کنند، نه از طریق واسطه.

۶. نتیجه‌گیری عملی: چه‌کار باید بکنی؟

برای خودت به‌عنوان اسکرام‌مستر، چند اقدام عملی از این بخش درمی‌آید:

هزینه‌ی عدم‌حضور PO را شفاف کن
فقط غر نزن که «PO نداریم»؛
مثل Frank، زمان‌های تلف‌شده، rework و انتظار را حساب کن و در قالب عدد و نمودار به PO و مدیریت نشان بده.
کارهای قابل‌تفویض PO را جدا کن
چیزهایی مثل: تست، ریزه‌کاری Backlog، بعضی فعالیت‌های گزارش‌دهی؛
این‌ها را می‌شود به Proxy/کمک‌PO داد تا خود PO وقت تعامل زنده با تیم را داشته باشد.
از User Story به‌عنوان «توکنِ مکالمه» استفاده کن، نه قرارداد
به تیم و PO یادآوری کن که User Story جای گفت‌وگو را نمی‌گیرد؛
اگر صرفاً متن را اجرا می‌کنید، دارید بر خلاف روح Agile کار می‌کنید.

۱. چرا POها در طول اسپرینت غایب می‌شوند؟

نویسنده توضیح می‌دهد که Product Ownerها از چند جهت زیر فشارند:

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

خیلی از آن‌ها مثل Phillip، این‌طوری مدیریت می‌کنند:

Backlog را برای Sprint Planning آماده و اولویت‌بندی می‌کنند.
در Sprint Review هم می‌آیند.
اما در طول اسپرینت، غالباً در دسترس نیستند.

نتیجه‌ی این مدل: تیم مجبور می‌شود برای پیاده‌سازی نیازمندی، روی فرضیات خودش سوار شود؛ چیزی که در داستان Oscars دیدیم و منجر به Migration اشتباه و Rollback شد.

طبق Agile Manifesto، ما باید «همکاری با مشتری» را بیش از «قرارداد» ارزش بدهیم. نقش Product Owner تلاش می‌کند همین همکاری زنده را به دل اسپرینت بیاورد، نه این‌که تیم فقط طبق چند جمله روی کارت کار کند.

برای تو به‌عنوان اسکرام‌مستر، این یعنی:

مسئول هستی مطمئن شوی تیم در طول اسپرینت جواب‌های لازم را می‌گیرد.
این معمولاً یعنی کار با PO برای بهبود Backlog، تسهیل رابطه‌ی PO–Dev و حذف موانعی که دسترسی به PO را سخت می‌کند.

۲. User Story و Acceptance Criteria: کافی نیستند، اگر مکالمه نباشد

وقتی PO در طول اسپرینت دردسترس نیست، تیم‌ها معمولاً دو واکنش رایج دارند:

سفت‌وسخت‌تر کردن نیازمندی‌ها
- Storyهای طولانی‌تر، جزئیات بیشتر، Scenarioهای مفصل‌تر.
Delegation (مثلاً دادن توضیح بیشتر به تحلیل‌گر یا Proxy).

Irony ماجرا:

خیلی‌ها User Story را دقیقاً به همین دلیل انتخاب می‌کنند که از نیازمندی‌های شِبه-قراردادیِ upfront فرار کنند.
ولی اگر PO در طول اسپرینت نیست، تیم دوباره Story را به «قرارداد» تبدیل می‌کند.

نویسنده تأکید می‌کند:

User Story به‌صراحت یک Token (توکن) برای مکالمه است، نه قرارداد فیچر.
فقط وقتی Story کار می‌کند که بعداً با گفت‌وگو درباره‌ی نیاز واقعی دنبال شود.

Acceptance Criteria کمک می‌کند مرز «Done» را دقیق‌تر کنیم، اما باز هم جای مکالمه را نمی‌گیرد.
اگر PO حضور ندارد، هیچ مقدار جزئیات روی کارت نمی‌تواند اتلاف ناشی از حدس‌زدن‌ها را کامل خنثی کند.

۳. Proxies: چرا مُسکن‌اند، نه درمان؟

وقتی دسترسی به PO کم است، Proxy وسوسه‌انگیز می‌شود:

Proxy کسی است که در طول روز کنار تیم می‌نشیند،
نیازمندی را توضیح می‌دهد،
و در نبود PO تصمیم می‌گیرد.

این بهتر از «PO کاملاً غایب» است، اما دو مشکل دارد:

تیم هنوز به جای «گفت‌وگو با صاحب تصمیم»، به متن کارت و برداشت Proxy وابسته است.
ریشه‌ی مشکل حل نشده: چرا PO این‌قدر مشغول است؟

نویسنده چند احتمال مطرح می‌کند:

PO روی چند Product/Project کار می‌کند.
PO خودش تیم حمایتی (PO Team) ندارد.
وقت زیادی را صرف Stakeholderهای بیرونی، یا تولید User Story بیش از ظرفیت تیم می‌کند.
PO خودش تست می‌کند یا Bug Report اسپرینت‌های قبلی را وارد می‌کند.

در حالت ایده‌آل، اگر Proxy هم داشته باشی، او باید کارهای «قابل‌تفویض» PO را بگیرد (مثل تست، ریزه‌کاری Backlog، هماهنگی‌های اداری)،
تا خود PO وقت تعامل مستقیم با تیم را داشته باشد؛ نه برعکس.

۴. نقش اسکرام‌مستر عالی در این فضا

نویسنده جمع‌بندی می‌کند:

اسکرام‌مستر خوب هر کاری می‌کند که فاصله‌ی PO–Dev را کمی پر کند، حتی اگر خودش وسط آن‌ها بایستد یا Proxy را مدیریت کند.
اسکرام‌مستر عالی می‌فهمد که در بلندمدت، خودش و Proxy نباید «واسطه‌ی دائمی» باشند؛ هدف این است که بیزنس و Dev روزانه و مستقیم کنار هم کار کنند.

برای این کار، چند حرکت کلیدی می‌توانی انجام دهی:

به‌جای غر زدن به «PO همیشه Busy»، مثل Frank Cost Case بساز: اتلاف زمان، Rework، Rollback، Delay تصمیم‌ها، و… را به زبان پول / زمان به مدیریت نشان بده.
به PO کمک کن تیم PO یا کمک‌PO بسازد؛ کارهای قابل‌تفویض را از روی دوشش بردارید تا زمان تعامل مستقیم آزاد شود.
هرجا می‌بینی Story دارد تبدیل به «قرارداد» می‌شود، خودآگاه تیم را برگردان به اصل:
«Story = یادآور مکالمه، نه جایگزین مکالمه».

۱. Proxy باید کجا باشد، PO کجا؟

در ادامه‌ی بحث قبلی، نویسنده می‌گوید:

حتی قوی‌ترین و آگاه‌ترین Proxy هم همیشه دقیقاً نمی‌فهمد که Product Owner واقعاً چه می‌خواهد.
Proxy به‌عنوان پلی برای مواقعی که دسترسی به PO صفر است، بهتر از هیچ است، اما ایده‌آل نیست.

مشکل اصلی این است که گذاشتن Proxy روی Interface با تیم، علت واقعی کمبود وقت PO را حل نمی‌کند:

آیا PO روی چندین کار/محصول موازی کار می‌کند؟
آیا PO تیم حمایتی ندارد؟
آیا وقتش را زیاد روی Stakeholderها و تولید Storyهای بیش‌ازظرفیت تیم می‌گذارد؟
آیا خودش Testing می‌کند یا Bugهای Sprint قبلی را ثبت می‌کند؟

در حالت ایده‌آل، اگر Proxy استفاده می‌شود، باید:

کارهای قابل‌تفویضِ PO (مثلاً تست، آماده‌سازی Backlog، گزارش‌دهی) را انجام دهد،
تا خود Product Owner برای تعامل مستقیم با توسعه‌دهنده‌ها آزاد باشد.

۲. وظیفه‌ی اسکرام‌مستر عالی: چسب‌زخم روی زخم عمیق نگذار

نویسنده تأکید می‌کند:

نقش Product Owner در Scrum حیاتی است.
اسکرام‌مستر خوب برای پل زدن بین PO و Dev هرکاری لازم باشد می‌کند – حتی اگر خودش زیاد وسط بایستد.
اسکرام‌مستر عالی سعی نمی‌کند با Proxy یا خودش، فقط یک Band‑Aid روی مسئله بچسباند؛ سعی می‌کند علت را حل کند:
- یعنی کمک کند زمان کافی PO برای صحبت با تیم در طول Sprint واقعاً آزاد شود.

ابزارش هم همان چیزی است که در داستان Oscars دیدیم:

نشان دادن هزینه‌ی واقعی Rollbackها، Reworkها و تأخیر تصمیم‌گیری،
تا PO بتواند justify کند که صرف وقت روزانه روی تیم، از نظر اقتصادی هم به‌صرفه است.

۳. Only True Product Owners Will Do

تیتر بعدی کتاب می‌گوید: «فقط Product Ownerهای واقعی جواب می‌دهند».

معنایش:

اسکرام‌مستر باید هر کاری لازم است بکند تا رابطه‌ی PO و Dev واقعاً کار کند؛
- به تیم کمک کند به زبان بیزنس نزدیک شود،
- به PO کمک کند محدودیت‌های فنی و ظرفیت تیم را بفهمد.
اما در بلندمدت، این‌که اسکرام‌مستر همیشه در نقش مترجم، واسطه یا داور بین این دو بماند، استراتژی درستی نیست.

نویسنده مستقیم به Agile Manifesto ارجاع می‌دهد:

«Business people and developers must work together daily throughout the project.»

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

هدف من این نیست که تا ابد «go‑between» بمانم.
هدفم این است که بیزنس و Dev خودشان، هر روز، مستقیم با هم کار کنند.
هر کاری که لازم است برای نزدیک کردن‌شان انجام می‌دهم، ولی سعی می‌کنم خودم را از وسطِ خط خارج کنم، نه این‌که دائماً وسط بایستم.

نویسنده حتی شوخی می‌کند که PO و تیم باید «hand‑in‑hand» با هم کار کنند (نه به‌صورت literal، چون کمی عجیب می‌شود!)، اما منظورش این است که از نظر همکاری، کنار هم باشند، نه پشت یک لایه‌ی ScrumMaster یا Proxy.

۱. تیتر اصلی: اول به خودت برس تا بتوانی به دیگران برسی

عنوان فصل این است:

اسکرام‌مستر خوب به دیگران خدمت می‌کند.
اسکرام‌مستر عالی اول به خودش خدمت می‌کند، تا بتواند به دیگران خدمت کند.

یعنی اگر خودت از پا بیفتی، دیگر هیچ‌کس را نمی‌توانی کمک کنی؛ شبیه همان قانون ماسک اکسیژن در هواپیما.

۲. داستان Holly: وقتی همه‌ی مشکلات روی سر تو خالی می‌شود

Holly اسکرام‌مستر تیمی است که تحت فشار سنگینی قرار گرفته:

تغییرات ناگهانی مقرراتی (Regulatory) آمده،
باید آن‌ها را در اسپرینت جاری جا بدهند، در حالی‌که اسپرینت قبلاً با تعهد مهمی برای یک مشتری بزرگ پر شده است،
تیم احساس می‌کند «چاره‌ای جز گرفتن هر دو اولویت» ندارد و زیر فشار له می‌شود.

از طرف دیگر، با Remote شدن کار، Holly دیده همکاری و ارتباط سخت‌تر شده:

اعضا به‌جای این‌که خودشان مسائل را حل کنند، دائماً پیش او می‌آیند و «گزارش و گله» می‌آورند.
Holly در ذهنش برنامه‌ریزی می‌کند که Remote Pairing و Eventهای تیم‌سازی مجازی راه بیندازد، اما عملاً خودش هم زیر بار می‌رود.

در ابتدای داستان، بعد از یک تماس طولانی با Charlie (تا ۷:۱۵ شب)، Holly:

Zoom را می‌بندد،
تازه متوجه می‌شود سه ساعت بدون وقفه روی صندلی بوده و سردرد گرفته،
و با خودش فکر می‌کند: «باز قراره سر این دیرکرد سر شام، دعوام بشه!»

پایین می‌آید، شریک زندگی‌اش، Morgan، به او لیوانی می‌دهد و می‌پرسد «باز روز سختی بود؟»؛ Holly می‌گوید بله و از این‌که توانسته به چند نفر کمک کند خوشحال است، اما ذهنش هنوز درگیر تیم است و حتی حرف‌های Morgan را کامل نمی‌شنود.

Morgan یک چیزی را به او آیینه می‌کند:

به Holly می‌گوید به نظر می‌رسد خیلی بیش از حد مسئولیت می‌گیرد، انگار همه‌چیز باید توسط او درست شود.
Holly اول دفاعی است («فقط همین یکی دو ماه را باید رد کنیم»)، اما بعد می‌پذیرد که این را قبلاً هم گفته و وضعیت بهتر نشده.
وقتی Morgan می‌گوید «همه با مشکل‌شان سراغ تو می‌آیند و تو فکر می‌کنی حلش فقط بر عهده‌ی توست؛ بقیه چه می‌کنند؟»، Holly متوجه می‌شود واقعاً دارد زیادی بار می‌برد.

خودش می‌گوید:

«کمک می‌کردم، اما داشتم گزینه‌ی سریع و راحت را انتخاب می‌کردم:
به‌جای سؤال‌پرسیدن، کوچ‌کردن و کمک به این‌که خودشان راه‌حل پیداکنند،
داشتم دستور می‌دادم و جواب آماده می‌دادم.»

Morgan به او پیشنهاد می‌کند این موضوع را با کسی در میان بگذارد؛
Holly تصمیم می‌گیرد دوشنبه با Sam (اسکرام‌مستر دیگر شرکت) صحبت کند و تا آن موقع موضوع را از ذهنش رها کند.

۳. گفت‌وگو با Sam: White Knight و سرعت‌گرفتنِ مسیر اشتباه

روز دوشنبه Holly موضوع را با Sam در میان می‌گذارد:

اعتراف می‌کند که تحت فشار، به سمت میان‌بر رفته: تجویز و حل مسئله، نه کوچ کردن.
Sam اول او را بابت تاب‌آوردن در این شرایط سنگین تحسین می‌کند، بعد می‌پرسد:
«این حفظ‌کردنِ طولانی‌مدتِ تیم، چه هزینه‌ای برای تو داشته؟»

Holly می‌گوید خوش‌شانس است که Morgan همراه و حامی بوده، اما حس می‌کند دارد کار را به رابطه‌اش ترجیح می‌دهد و بابتش احساس گناه دارد.

Sam سؤال کلیدی دیگری می‌پرسد:

«اگر این اسکرام‌مسترِ دیگری بود، به او چه می‌گفتی؟»

Holly متوجه می‌شود که اگر شخص دیگری بود، به او دو توصیه می‌کرد:

اول، به خودش افتخار کند که تیم را در زمان سخت سر پا نگه داشته،
دوم، درباره‌ی گرفتار شدن در نقش White Knight به او هشدار می‌داد.

White Knight Syndrome را قبلاً هم با هم بحث کرده بودند:

در همه‌ی حرفه‌های «کمکی» دیده می‌شود (پزشکی، درمانگری، تدریس، servant‑leadership).
محرک‌اش تمایل (ظاهراً مثبت) به نجات‌دادن دائمی دیگران است.
مشکل‌اش این است که به‌طور ناخودآگاه جلوی این را می‌گیرد که دیگران به خودکفایی برسند؛ چون اگر آن‌ها کاملاً مستقل شوند، انگار دیگر به این شوالیه‌ی سفید نیازی نیست.

Sam می‌گوید:

«اگر این اسکرام‌مستر داشت نقش ناجی را بازی می‌کرد، چه توصیه‌ای به او می‌کردی؟»
Holly: «بهش می‌گفتم یک استراحت بگیرد… ولی خودم نمی‌توانم، الان بدترین زمان برای ترک تیم است.»

Sam کلمه‌ی «ترک/رها کردن» را چالش می‌کند:

«واقعاً اسم‌اش رها کردن است؟»

Holly می‌پذیرد که نگاهش به موضوع شاید تا حدی تحریف شده است و قرار می‌گذارد به محض عبور از این موج فشار، حتماً استراحت بگیرد. اما هنوز فکر می‌کند «خط پایان نزدیک است» و باز همان الگوی تعویق را تکرار می‌کند.

۴. مداخله‌ی تیم: هدیه‌ای که پیام درونی دارد

روز بعد، سه‌شنبه، تولد Holly است.
بعد از Daily، Lou لینکی در چت می‌فرستد؛ یک کارت تبریک دیجیتال برای Holly. Holly خجالت می‌کشد و خوشحال می‌شود؛
اما زمانی که متن کارت را می‌خواند، چشم‌هایش گرد می‌شود: تیم برای او یک Spa Break هدیه گرفته است.

Lou می‌گوید دو شرط دارد:

باید دو روز پشت‌سرهم وسط هفته باشد.
و حتماً قبل از پایان ماه استفاده شود.

Holly می‌گوید: «ولی همین الآن ۲۳م است!»
Lou جواب می‌دهد:

«دقیقاً. بد برداشت نکن، اما فکر کردیم واقعاً به یک استراحت احتیاج داری.»

اینجا کتاب چند پیام را منتقل می‌کند:

Holly خودش نمی‌دید که نیاز به استراحت دارد، اما تیم این را دیده بود.
تیم نه‌تنها این را به‌عنوان «رها شدن» از اسکرام‌مستر ندید، بلکه انگیزه‌شان این بود که او به خودش برسد.
وقتی Holly نمی‌خواهد به خودش کمک کند، هم شریک زندگی و هم تیم در نقش «آینه» وارد می‌شوند.

۵. تحلیل نویسنده: چرا نیت خوب، نتیجه‌ی معکوس می‌دهد؟

نویسنده می‌گوید داستان Holly بین اسکرام‌مسترها بسیار رایج است:

تشخیص این‌که کمک کردنِ ما چه‌زمانی «از حد سالم» عبور کرده و در عمل نتیجه‌ی معکوس می‌دهد، سخت است.

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

سرعت شخصیِ غیرقابل‌دوام (unsustainable pace)
- گفتنِ این‌که «چه‌کار کن» همیشه سریع‌تر از کوچ‌کردن است.
- وقتی خودت overloaded هستی، ناخودآگاه به سمت نسخه‌پیچی سریع می‌روی و کمتر سؤال می‌پرسی.
- این باعث می‌شود تو bottleneck بشوی و سرعت نابود‌کننده‌ات را به خودت و تیم تحمیل کنی.
White Knight Syndrome
- میل پنهان به این‌که ناجی تیم باشی، باعث می‌شود کمتر دیگران را به خودکفایی هل بدهی.
- چون اگر آن‌ها بتوانند بدون تو هم از پس خودشان بربیایند، انگار نقش تو کم‌اهمیت می‌شود.

نویسنده می‌گوید Sam با سؤال‌های کوچینگ‌محور دقیقاً کار درست را کرد:

Holly را وادار کرد از بیرون به خودش نگاه کند («اگر این اسکرام‌مستر کس دیگری بود…»)؛
این فاصله‌گرفتن از مسئله، spotting گرایش به White Knight را آسان‌تر کرد.

تیم هم با هدیه‌ی Spa Break عملاً نشان داد:

غیبت موقت Holly، «رها کردن» تیم نیست؛
برعکس، آن‌ها این فرصت را استفاده کردند تا self‑management و empowerment خودشان را بالا ببرند.
وقتی Holly برگشت، دید تیم در بسیاری زمینه‌ها خودش را بالا کشیده؛ چیزهایی که اگر او باقی می‌ماند و مدام rescue می‌کرد، هرگز رخ نمی‌داد.

۶. چرا اسکرام‌مسترها سخت می‌توانند کمک بخواهند؟

نویسنده اشاره می‌کند اسکرام‌مسترها اغلب در کمک‌خواستن ضعیف هستند، درحالی‌که دائم به دیگران می‌گویند «کمک بخواهید»! دلایل رایج:

می‌خواهند قوی به‌نظر برسند.
می‌ترسند با درخواست کمک، احترام یا اعتبارشان کم شود.
نمی‌خواهند «بار» روی دوش دیگران بگذارند.

نویسنده پرسش جالبی مطرح می‌کند:

وقتی از اسکرام‌مسترها می‌پرسد آیا دیگران برای‌شان بار هستند وقتی کمک می‌خواهند، معمولاً می‌گویند «نه؛ از کمک‌کردن خوشحال می‌شویم».
پس چرا این شادی را از دیگران می‌گیرند و اجازه نمی‌دهند آن‌ها هم با کمک‌کردن به اسکرام‌مستر حال خوبی تجربه کنند؟

شعارش این است:

«سخاوتمند باش و از دیگران کمک بخواه.
خودخواه باش و به دیگران کمک کن.»

۷. اکسیژن ماسک و هنر «کنارکشیدن»

نویسنده به نقل از Robert Greenleaf، از «هنر کنارکشیدن» حرف می‌زند:

توانایی کنارکشیدن و تجدیدجهت (حتی برای لحظات کوتاه) مستلزم این است که یاد بگیری چه چیزهایی را باید عمدی نادیده بگیری،
تا بتوانی انرژی‌ات را روی «مهم‌تر» به‌جای «فوری‌تر» متمرکز کنی.

از استعاره‌ی هواپیما استفاده می‌کند:

اسکرام‌مستر خوب مثل مسافری است که اول ماسک اکسیژن خودش را می‌زند، بعد به دیگران کمک می‌کند.
نه از سر خودخواهی، بلکه چون بدون اکسیژن، به درد هیچ‌کس نمی‌خورد.

راه‌کارهای عملی برای «withdrawal» و خودمراقبتی:

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

همچنین به supervision اشاره می‌کند:

خیلی از اسکرام‌مسترها (از زمان اختراع این نقش) ارزش زیادی در داشتن یک Supervisor/Coach دیگر پیدا کرده‌اند،
دقیقاً مثل رابطه‌ی Holly و Sam: فضایی برای بازتاب‌دادن، بدون قضاوت.
سؤال اخلاقی مهمی هم می‌پرسد: «آیا می‌توانی دیگران را به self‑reflection تشویق کنی اگر خودت این کار را نمی‌کنی؟»

ابزار دیگر: Journaling / دفترچه‌ی روزانه‌ی تأمل؛
هر روز، آگاهانه روزت را دِبریِف کن تا رفتارهای ناخودآگاه روی هم انباشته نشوند.

پیام نهایی این بخش:

برای این‌که servant‑leader خوبی برای تیم باشی، لازم است به‌قدر کافی خودخواه باشی:
- سرعتت را انسانی نگه داری،
- از نقش ناجی بیرون بیایی،
- کمک بخواهی،
- و اجازه دهی تیم در غیاب موقت تو هم رشد کند.

۱. Tactful یعنی چه؟ چرا «ScrumMaster مرده، بی‌فایده است»؟

فصل با نقل‌قولی از Ken Schwaber شروع می‌شود:

«یک اسکرام‌مستر مرده، یک اسکرام‌مستر بی‌فایده است.»

نویسنده توضیح می‌دهد:

اسکرام‌مستر باید تجسم «هنرِ ممکن» باشد: با هر وضعیت و محدودیتی که هست، بهترین حرکتی که می‌شود کرد را پیدا کند تا تیم و سازمان را جلو ببرد.
هم‌زمان باید سمج و بی‌رحم نسبت به حرکت‌دادن تیم/سازمان از «فرماندهی–کنترل» به «servant‑leadership» باشد؛ از «برنامه‌ریزی پیش‌بینانه» به «برنامه‌ریزی مبتنی بر داده‌ی تجربی».

عوض‌کردن این سیستم‌ها، کند و دردناک است؛ حذف موانع تیم و حل مسائل سازمانی برای چابک‌شدن واقعی، هم پایداری می‌خواهد هم پوست‌کلفتی.

وسوسه‌ی رایج این است که بگویی:

«این سازمان هیچ‌وقت عوض نمی‌شود»،
یا «این تیم هیچ‌وقت خودش را نمی‌گیرد».

به‌همین دلیل نویسنده توصیه می‌کند مرتباً نشانه‌های پیشرفت کوچک را ثبت کنی (مثلاً: «جان امروز در رِترو حرف زد»، «آدم‌ها در دیلی به‌جای کفش‌ها، به هم نگاه می‌کنند»، «Dave امروز داوطلب شد به Arush کمک کند»). این ریزپیشرفت‌ها در روزهای سخت، سوخت تو هستند.

اما همه‌ی این‌ها باید با تدبیر و احترام همراه باشد:

فرآیندها و رفتارهای فعلی، هرچند ضدچابک، یک‌روزی برای کسانی که آن‌ها را ساخته‌اند کاملاً عقلانی بوده‌اند.
آدم‌ها به آن‌ها دلبستگی احساسی دارند.
اسکرام‌مستر عالی «توپِ آتشینِ دائم‌الاعتراض» نیست؛
درگیری‌ها را با انتخاب و حساب‌شده شروع می‌کند،
حاضر است در بعضی جاها کوتاه بیاید تا بتواند روز دیگری برای تغییر بجنگد.

نکته‌ی عملی: قبل از ایمیل/جلسه‌ی حساس،

چند ثانیه مکث کن،
اگر می‌توانی با همکار مورداعتماد مرور کن ببین پیام‌ات چقدر تحریک‌آمیز است،
و لحن‌ات را تنظیم کن.

۲. قصه‌ی «A Tale Of Two Scrums»: دو دیلی، دو واقعیت

این داستان، نمونه‌ی خوبی از «تاکتیک بد» است؛ جایی که اسکرام‌مستر فکر می‌کند دارد تیم را محافظت می‌کند اما در واقع اعتماد را می‌کُشد.

وضعیت تیم Icarus

نویسنده به‌عنوان Coach، صبح روز اول با تیمی به نام Team Icarus سر Daily می‌رود:

تیم چند ماه است Scrum کار می‌کند.
اتاق جلسه‌ی شیشه‌ای و باحال کنار دریاچه دارند.
یک دیوار Sprint Backlog، دیوار Burndown، و روی دیوار دیگر خروجی رِتروهای قبلی است. همه سر وقت می‌آیند، حتی PO یعنی Annika.

Daily این‌طور به‌نظر می‌رسد:

هر نفر به ترتیب پیشرفت‌اش را می‌گوید.
نمودار Burndown نشان می‌دهد تیم روی مسیر خوبی است.
جلسه ۶–۷ دقیقه بیشتر طول نمی‌کشد و همه برمی‌گردند سر کار.

Coach خوشحال است، با خودش می‌گوید «کمک زیادی لازم ندارند؛ کارهای پیشرفته می‌توانم باهاشان بکنم.»

دیلی دوم: نسخه‌ی واقعی

اما به‌محض برگشتن به فضای کار تیم، صحنه‌ای عجیب می‌بیند:

ScrumMaster تیم، Stephanie، یواشکی دوروبر را نگاه می‌کند،
از کشو یک نسخه‌ی دیگر از Burndown چاپ‌شده بیرون می‌آورد،
تیم دور او جمع می‌شوند و یک Daily Scrum دیگر می‌گیرند.

این Burndown واقعی خلاف قبلی را نشان می‌دهد:

تیم از تعهد اسپرینت عقب است،
احتمال این‌که به Sprint Goal برسند پایین است.

وقتی Coach می‌پرسد «داستان چیه؟»، Stephanie می‌گوید:

«اون دیلی که با Annika داشتیم، فقط برای PO بود.
این یکی Daily واقعی است.
اگر Annika Burndown واقعی را ببیند، وحشت می‌کند.»

توضیح می‌دهد که آخرین‌باری که Annika یک Burndown بد دیده، این‌طور واکنش نشان داده:

فکر کرده کافی «hands‑on» نبوده،
مدام سر کار تیم حاضر شده،
هر پنج دقیقه می‌پرسیده «چه خبر؟ کجایید؟»،
از تیم خواسته تا تاخیر جبران شود، اضافه‌کار بمانند.

در نتیجه تیم و Stephanie به این نتیجه رسیده‌اند که:

روزی کمتر از ۱۰ دقیقه برای خوشحال‌کردن Annika ارزشش را دارد،
در عوض او تا Sprint Review کاری به کارشان ندارد.

۳. چرا این «تاکتیک دفاعی»، ضد ارزش Agile است؟

نویسنده اعتراف می‌کند از دید Stephanie قابل‌درک است که بخواهد تیم را از فشار بی‌مورد و مداخله‌ی مخرب PO محافظت کند؛ یکی از وظایف اسکرام‌مستر حفاظت از تمرکز تیم است.

اما چند مشکل جدی وجود دارد:

Scrum روی شفافیت (Transparency) بنا شده است.
- Daily و Burndown ابزار تیم برای Self‑management هستند، نه ابزار مدیر برای مایکرو منیجینگ.
- وقتی دو نسخه‌ی واقعیت تولید می‌کنی، عملاً ستون شفافیت را تخریب می‌کنی.
اعتماد PO–Team را می‌کشی.
- اگر Annika بفهمد تیم برایش «نمایش» اجرا کرده، اعتمادش به تیم و کل فرآیند Scrum از بین می‌رود.
از بین می‌بری فرصت PO برای کمک واقعی.
- PO خوب، در برداشتن موانع نقش قوی دارد؛ شبکه و نفوذ دیگری در سازمان دارد.
- اگر تصویر واقعی مشکلات را نبیند، نمی‌تواند برای حل‌شان از نفوذش استفاده کند.

در اصل، Stephanie به‌جای این‌که مسئله‌ی واقعی (واکنش بد Annika به ریسک) را حل کند، روی آن Band‑Aid زده: دروغِ روزانه.

۴. راه درست: شجاعتِ شفافیت، ولی با تاکت

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

هم تیم را در کوتاه‌مدت محافظت کند،
هم در بلندمدت مسئله‌ی ریشه‌ای را با PO و سازمان باز کند.

چند حرکت tactful ممکن:

به‌جای پنهان‌کاری، با Annika نشست جدی بگذارد و هزینه‌ی مداخلاتش را توضیح بدهد (مثلاً افکت context switching، کاهش تمرکز، افزایش خطا).
با هم توافق کنند اگر Burndown بد است، PO به‌جای سر زدن هر پنج دقیقه، در روزهای مشخص و به‌شکل توافق‌شده وضعیت را مرور کند و در حل impediment کمک کند.
به Annika نشان دهد که اگر در برداشتن موانع مشارکت کند، velocity واقعی تیم بالا می‌رود.

نکته‌ی محوری:

«محافظت از تیم» با دروغ‌گویی سیستماتیک تفاوت دارد.
tactful بودن یعنی حقیقت را نگه‌داری، اما نحوه‌ی ارائه و زمان‌بندی نبردها را عاقلانه انتخاب کنی؛ نه این‌که اساس شفافیت را قربانی کنی.

۱. ادامه‌ی گفت‌وگوی Annika و Stephanie: SPEED Model

در ادامه‌ی داستان قبل، Annika از Stephanie می‌خواهد او Jean (مدیر بالای او) را متقاعد کند که هدف quarter بعدی غیرواقعی است و تیم را اذیت نکند. Stephanie قبول نمی‌کند که خودش وارد شود، چون:

Jean او را «طرفدار تیم» می‌بیند و بی‌طرف نیست،
اما Annika از همان «قبیله»ی Jean است (یعنی مدیر/بیزنس) و می‌تواند با همدلی بهتری صحبت کند.

Stephanie پیشنهاد می‌کند Annika را کوچ کند که خودش بتواند Jean را تحت‌تأثیر قرار دهد.
Annika می‌پذیرد و Stephanie از دو مدل کوچینگ استفاده می‌کند:

مدل GROW

Stephanie این مراحل را طی می‌کند:

Goal (هدف): Annika چه می‌خواهد؟
- «می‌خواهم Jean را متقاعد کنم هدف غیرواقعی است، بدون این‌که شغلم یا پیشرفت شغلی‌ام خطرناک شود.»
Reality (واقعیت): او تا حالا چه کرده؟
- پیام خودش را گفته، اما Jean گفته «تو زیادی نرم هستی و تیم راضی‌به‌حال شده».
- هیچ راه دیگری امتحان نکرده، فقط آمده از Stephanie کمک بخواهد.
Options (گزینه‌ها): چه روش‌های دیگری وجود دارد؟
- Stephanie از او می‌پرسد قبلاً چه‌جور نظر دیگران را عوض کرده؛
- Annika می‌گوید معمولاً از استدلال منطقی و داده استفاده می‌کند، اما گاهی با همه‌ی شواهد، آدم‌ها عقیده‌شان را عوض نمی‌کنند.
Will (اراده): آیا Annika آماده است قدم بعدی را بردارد؟
- بله، اگر Stephanie به او نشان دهد چطور.

مدل SPEED

Stephanie مدل SPEED را معرفی می‌کند (روش‌های مختلف تأثیرگذاری):

Suggestions: پیشنهادها/دستورات
Proof: اثبات با داده و شواهد
Enablers: فعال‌کننده‌ها / ابزارها
Environment: تغییر محیط
Drivers: محرک‌های درونی فرد

Stephanie توضیح می‌دهد:

Suggestions و Proof سریع‌اند، اما گاهی نتیجه‌ی معکوس می‌دهند (مثل تجربه‌ی Annika: هرچه داده بیشتر، مقاومت بیشتر!).
Enablers و Environment گاهی مؤثرند.
قوی‌ترین تغییر وقتی است که از Drivers (ارزش‌ها و محرک‌های درونی فرد) استفاده کنی.

Stephanie از Annika می‌پرسد Jean چه محرک‌هایی دارد؛
Annika می‌گوید:

کمال‌گرا است،
کیفیت و کنترل را دوست دارد،
از ریسک و waste متنفر است.

Stephanie پرسش کلیدی را مطرح می‌کند:

«چطور می‌توانی از خودِ این محرک‌های Jean استفاده کنی تا حمایت از Scrum برایش جذاب‌تر و طبیعی‌تر بشود؟»

Annika تازه متوجه می‌شود:

Jean تا حالا Scrum را wasteful دیده، چون بعضی iterationها کارهایی undo یا دور انداخته شده‌اند.
اما Annika می‌تواند به او نشان دهد که این wasteهای کوچک، waste عظیم انتهای پروژه (مثلاً تحویل کامل یک محصول که دیگر به درد بازار نمی‌خورد) را جلوگیری کرده.
بنابراین به‌جای «تغییر عقیده‌ی Jean»، می‌تواند تبریک بگوید به ذهن‌بازش که باعث شده شرکت در این مدت هزینه و زمان زیادی صرفه‌جویی کند.

این shift از «تو اشتباه می‌کنی» به «تو قبلاً عاقلانه رفتار کردی و Scrum همین هدف‌هایت را پیش می‌برد» تفاوت کلیدی در نتیجه‌ی تأثیرگذاری است.

۲. بخش «Respected»: احترام مهم‌تر از محبوبیت

نویسنده فصل بعد را با نقل‌قولی از مادربزرگش شروع می‌کند:

«خیلی بهتر است مورد اعتماد و احترام باشی تا این‌که دوست‌داشتنی باشی.»

و به یکی از واقعیت‌های نقش اسکرام‌مستر اشاره می‌کند:

این نقش هیچ اختیار رسمی ندارد.
اسکرام‌مستر باید ارزش‌های Scrum را تجسم کند، تیم را رشد دهد و عامل تغییر سازمان باشد، بدون قدرت رسمی.

پس تنها راه مؤثربودن این است که احترام را بدست بیاوری:

احترام تیم،
احترام افراد تأثیرگذار در سازمان.

نویسنده می‌گوید اسکرام‌مسترهای عالی:

رابطه‌ی قوی با تیم دارند،
سریع و عمیق با دیگران rapport می‌سازند،
به همین دلیل می‌توانند در شرایط سخت، به‌خوبی تسهیل کنند و سؤالات سخت را بپرسند که تأمل انتقادی در تیم ایجاد می‌کند.

۳. چگونه اسکرام‌مستر را انتخاب کنیم؟ رأی تیم

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

در کارگاهی که می‌گرفت، از گروه ۲۵ نفره خواست هرکس نام کسی را که فکر می‌کند اسکرام‌مستر عالی می‌شود، روی کارت بنویسد (یک کارت = یک نام).
کارت‌ها بی‌نام جمع شد؛ وقتی شمارش کرد، ۲۳ نفر از ۲۵، همان یک نفر را انتخاب کرده بودند.
هر بار این تمرین را انجام داده، نتیجه‌اش مشابه بوده: تیم‌ها غریزی می‌دانند چه‌کسی بهترین Enabler آن‌ها خواهد بود.

نکته‌ی جالب این است که انتخاب تیم، اغلب با انتخاب مدیریت فرق می‌کند! نویسنده پیشنهاد می‌کند:

از آن‌جا که تیم به اسکرام‌مستر پاسخ‌گو نیست، بلکه برعکس است (اسکرام‌مستر servant تیم است)،
منطقی است که خود تیم اسکرام‌مسترش را انتخاب کند،
و حتی اگر اسکرام‌مستر در servant‑leadership موفق نیست، تیم بتواند او را عوض کند.

۴. فروتنی: کلید احترام

نویسنده می‌گوید اسکرام‌مسترهای محترم همه‌شان یک ویژگی مشترک دارند: فروتنی:

بی‌منیت و فداکار هستند،
مرتب وقت می‌گذارند تا فکر کنند چه کسانی به آن‌ها کمک کرده‌اند،
اشتباهات خودشان را می‌پذیرند،
موفقیت دیگران را حتی وقتی بدون کمک یا «در برابر» کمک‌شان بوده، تحسین می‌کنند.

برای تمرین فروتنی:

از دیگران کمک بخواه،
بگو کجاها دانش کافی نداری.

نویسنده یک تیپ عملی می‌دهد:

در رِتروسپکتیو بعدی، از تیم بازخورد بخواه درباره‌ی خودت: چطور می‌توانم اسکرام‌مستر بهتری باشم؟
خود این عمل، احترام را زیاد می‌کند، چه برسد به ایده‌هایی که بدست می‌آوری.

۵. یکپارچگی و قابل‌اعتماد بودن

نویسنده می‌گوید بخش عظیمی از احترام، از Integrity (یکپارچگی) می‌آید:

صداقت، ثبات، قابل‌اتکا بودن و یک کد اخلاقی قوی.
وقتی integrity داری، مردم می‌دانند از تو چه انتظار داشته باشند؛ و این قطعیت برایشان ارزش دارد.

چرا قطعیت مهم است؟
نویسنده به تحقیقی از UCLA اشاره می‌کند که با fMRI نشان داده:

وقتی آدم‌ها با عدم‌قطعیت مواجه می‌شوند، همان بخش‌هایی از مغز فعال می‌شود که در درد فیزیکی فعال می‌شوند.
Scrum مقدار زیادی عدم‌قطعیت معرفی می‌کند (در requirements، ساختار، سلسله‌مراتب، شرح شغل و…)،
بنابراین داشتن یک نقطه‌ی اطمینان (اسکرام‌مستر قابل‌اتکا) در این طوفان، بسیار ارزشمند است.

وقتی اعضای تیم می‌دانند اسکرام‌مستر در کجا ایستاده، اعتماد و احترام شکل می‌گیرد:

مردم راحت‌تر مشکلات و impedimentها را نزد او می‌آورند،
و این به نوبه‌ی خود، دست اسکرام‌مستر را در تسهیل قوی‌تر می‌کند (یادمان باشد او authority رسمی ندارد).

یک تیپ عملی دیگر:

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

۶. جمع‌بندی: Tactful + Respected = نفوذ بدون قدرت رسمی

در دو بخشی که امروز دیدیم، نویسنده دو لبه‌ی مهم تأثیرگذاری اسکرام‌مستر را نشان داد:

Tactful: هوشمندانه بجنگ
- شفاف باش، اما زمان‌بندی و نحوه‌ی بحث‌ها را عاقلانه انتخاب کن.
- از Drivers و ارزش‌های طرف مقابل استفاده کن، نه فقط داده.
- از دروغ (مثل Burndown جعلی) به‌عنوان راه‌حل پرهیز کن.
Respected: محترم باش
- فروتنی داشته باش.
- Integrity نشان بده.
- به تعهدات کوچک خودت پایبند بمان.
- اجازه بده تیم تو را انتخاب کند و از تو بازخورد بگیرد.

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

۱. ENCOURAGE: تشویق به تجربه، حتی اگر به شکست بینجامد

تیتر فصل

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

چرا تغییر و تجربه ضروری است؟

نویسنده می‌گوید:

ثابت هیچ‌چیز نیست؛ تغییر تنها ثابت است.
سازمان‌ها و تیم‌ها باید دائماً adapt شوند.
Scrum فرصت‌های built‑in برای بهبود دارد (Retrospective، Sprint Review)؛ اسکرام‌مستر باید تیم را تشویق کند از این فرصت‌ها استفاده کند.

توصیه‌ی عملی:

حتی اگر یک تغییر کوچک یا آزمایش ساده باشد، هیچ اسپرینتی را بدون امتحان چیز جدیدی رد نکن.
این عادت و حافظه‌ی عضلانی می‌سازد.

کاهش ترس و هزینه‌ی شکست

کلید تشویق به تجربه، کم‌کردنِ ریسک، ترس و هزینه‌ی امتحان چیز جدید است:

تجربه را جذاب و شاد کن.
بگو شکست اشکال ندارد، به شرط آن‌که:
- سریع شکست بخوریم،
- ارزان شکست بخوریم،
- همان شکست را دوبار تکرار نکنیم.

اسکرام‌مستر هم خودش را تشویق کند

نویسنده می‌گوید:

اسکرام‌مستر نه‌تنها باید cheerleader تیم باشد، بلکه باید برای خودش هم همین کار را بکند.
این نقش گاهی خیلی تنها است؛
برای این‌که دیگران را تشویق کنی، باید روی قدرت درونی خودت کار کنی و به خودت هم انرژی بدهی.

۲. FACILITATE: هدف نهایی، تیمی است که دیگر به تو نیاز ندارد

تیتر فصل

اسکرام‌مستر خوب به تیم کمک می‌کند فرآیند خودش را بهینه کند.
اسکرام‌مستر عالی تیم را به جایی می‌رساند که دیگر به فرآیند (و حتی اسکرام‌مستر) نیاز نداشته باشد.

Facilitation: مهارت زیربنایی اسکرام‌مستری

نویسنده می‌گوید تسهیل‌گری، رفتار و مهارت زیربنایی همه‌ی اسکرام‌مسترهای عالی است:

در تمام زمان‌ها، در خدمت اهداف تیم، Product Owner و سازمان هستند.
اگر این اهداف با هم تعارض داشتند، به آثار بلندمدت و پیام‌هایی که هر سازش می‌فرستد فکر می‌کنند.

اسکرام‌مستر عالی چه چیزهایی را تسهیل می‌کند؟

رابطه‌ها درون تیم و بین تیم و بیرون.
فرآیند Scrum و تکامل آن.
ادغام تیم Scrum در سازمان بزرگ‌تر.
تغییر خود سازمان تا فعالانه از Scrum حمایت کند.

بی‌وقفه روی خودت کار کن

نویسنده می‌گوید اسکرام‌مسترهای عالی:

بی‌وقفه روی خودشان کار می‌کنند تا تسهیل‌گران بهتری شوند.
Introspect و retrospect می‌کنند.
از دیگران بازخورد درباره‌ی کارشان می‌گیرند.
با سایر اسکرام‌مسترها Pair می‌شوند تا یاد بگیرند.

اما با همه‌ی این تمرکز روی خود، در نهایت می‌دانند هیچ‌کدام از این‌ها درباره‌ی خودشان نیست:

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

معیار موفقیت: کم‌شدنِ احتیاج به تو

نویسنده می‌گوید موفقیت شخصی اسکرام‌مستر عالی را چه‌طور می‌سنجند:

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

ممکن است روزی حتی ببینی که تیمت را به سمت خارج‌شدن از Scrum تسهیل می‌کنی:

وقتی به Shu Ha Ri رسیده‌اند و دیگر «کفش‌های پشمالو» (استعاره‌ی Ri) را پوشیده‌اند.
اسکرام‌مسترهای عالی می‌دانند این می‌تواند نشانه‌ی خوبی باشد، به شرط آن‌که تیم واقعاً آماده باشد و زمان درست باشد.
این می‌تواند نهایی‌ترین نشانه‌ی کار خوب باشد.

۳. جمع‌بندی کلی RETRAINED

با این بخش‌ها، کل چارچوب RETRAINED کامل شد. بیایید مرورش کنیم:

حرف	واژه	معنا
R	Resourceful	پرمنبع و خلاق در حل مشکل
E	Enabling	توانمندساز، نه انجام‌دهنده
T	Tactful	باهوش و محتاط در تأثیرگذاری
R	Respected	محترم و قابل‌اعتماد
A	Alternative	آلترناتیو: دیدگاه و راه‌حل متفاوت
I	Inspiring	الهام‌بخش
N	Nuanced	ظریف و عمیق در درک
E	Encourage	تشویق‌کننده
D	Disruptive	مخل راحتی کاذب (از روی عمد)

هر کدام، لایه‌ای از servant‑leadership را باز می‌کنند و نشان می‌دهند اسکرام‌مستر عالی چه‌جور رفتار می‌کند و چه نوع ذهنیت دارد.

۴. پیام نهایی کتاب

نویسنده می‌گوید:

Facilitation اساس همه‌چیز است؛ همه‌ی مهارت‌های دیگر به خدمت این می‌آیند.
اسکرام‌مستر عالی در نهایت، خودش را از دل تیم بیرون می‌کشد؛ چون هدفش ساختن تیمی خودمختار و خودسازمان‌ده است.
موفقیت واقعی این است که بتوانی بگویی: «این تیم دیگر به من نیاز ندارد؛ این یعنی من کارم را خوب کرده‌ام.»

برای تو به‌عنوان اسکرام‌مستر، این یعنی:

همیشه به یاد داشته باش که این داستان، درباره‌ی تو نیست؛ درباره‌ی موفقیت تیم است.
وظیفه‌ات این است که خودت را غیرضروری کنی؛ نه این‌که وابستگی تیم به خودت را افزایش بدهی.
اگر تیم به جایی رسید که بتواند بدون تو حتی بهتر کار کند، جشن بگیر، نه این‌که احساس تهدید کنی.

کتاب, مهندسی, برنامه_نویسی