Scrum Mastery

From Good to Great Servant Leadership

Scrum Mastery

توضیحات

نظر

امتیاز : 00/10
به دیگران توصیه می‌کنم :
دوباره می‌خوانم :
ایده برجسته :
تاثیر در من :
نکات مثبت :
نکات منفی :

مشخصات

نویسنده :
انتشارات :
صفحه مشخصات : 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 – یا “کفش پشمالو” و استعاره‌ی 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 رسیده است، حتی اگر دلت بخواهد بمانی.

در این نوبت، فقط بخش «Keeping The Peace?» (حفظ یا عبور از هماهنگی ظاهری) را باز می‌کنم؛ یعنی داستان تیم Jedis، مفهوم امنیت روانی و ربط‌اش به تئوری Tuckman.

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

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

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

نویسنده به 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.
اسکرام‌مستر عالی باید شجاعت به‌هم‌زدن این آرامشِ دروغین را داشته باشد، اما با احترام و طراحی، نه با مشت‌کوبی روی میز.

در این نوبت فقط بخش «Holding To Account» را باز می‌کنم؛ یعنی مسئله‌ی «تعهد و پاسخ‌گویی» و این‌که اسکرام‌مستر عالی چه‌کسی را واقعاً مسئول می‌گیرد.

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

نویسنده از یک تحقیق در 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 هم می‌آورد و می‌گوید این‌ها پله‌ی خوبی برای عادت‌دادن تیم به فیدبک مداوم هستند.

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

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