در این قسمت با ارد سمسارزاده در مورد موضوعات زیر گفتگو کردم:
۱. چه اتفاقی می‌افتد که مدیران صبرشان تمام می‌شود و با ادامه پیاده سازی اسکرام همراهی نمی‌کنند؟
۲. موفق ترین و ناموفق ترین تجربه پیاده سازی اسکرام کدام است؟
۳. چه پیش فرض هایی برای پیاده سازی اسکرام وجود دارد که مدیران معمولا در نظر نمی‌گیرند؟
۴. رهبری چه انواعی دارد و کدام یک پایدارتر است؟
۵. اسکرام مستر چه مسئولیتی در اتفاق افتادن این موقعیت دارد؟
مهمان: ارد سمسارزاده، اسکرام مستر و مدرس کانبان
اجرا: پدرام کشاورزی، اسکرام مستر حرفه‌ای
تدوین: پانته‌آ شهریاری
سلام و درود به همه‌ی شنوندگان گرامی. من پدرام کشاورزی هستم و با یکی دیگر از قسمت‌های پادکست «اجایل‌گپ» همراه شما هستم.
در این اپیزود، یک دوست قدیمی را نیز در کنار خود داریم تا درباره‌ی موضوعی مهم و چالشی صحبت کنیم: چالش‌های پیاده‌سازی اسکرام (Scrum) در سازمان‌ها. پرسش اصلی ما این است که چرا برخی مدیران، پس از مدتی همکاری، ناگهان در برابر ادامه‌ی پیاده‌سازی اسکرام مقاومت می‌کنند و اصطلاحاً «زیر میز می‌زنند».
مهمان برنامه:
«سلام پدرام، از دعوت شما سپاسگزارم. خوشحالم که دوباره در پادکست حضور دارم و امیدوارم گفت‌وگوی امروز نیز همچون دفعات گذشته، هم مفید باشد و هم چالش‌برانگیز. همان‌طور که می‌دانی، من تجربه‌ی کار با اسکرام و کانبان (Kanban) را دارم، اما در این قسمت تمرکزمان را بیشتر بر تجربه‌های مربوط به اسکرام بگذاریم. به نظرم موضوع بسیار واقعی و ملموسی است.»
چرا مدیران مقاومت می‌کنند؟
باید به یاد داشت که تجربه‌ی بسیاری از افراد در دنیای اجایل (Agile) با اسکرام آغاز شده است. اسکرام چارچوبی شناخته‌شده و پرکاربرد است و من نیز شخصاً تجربه‌های بسیار ارزشمندی با آن داشته‌ام. اما پرسش کلیدی این است که چرا، در عمل، مدیران سازمان‌ها در برابر تداوم پیاده‌سازی آن مقاومت می‌کنند؟
انتظارات غیرواقع‌بینانه:
مدیران معمولاً بر اساس شنیده‌ها یا مقالاتی که خوانده‌اند، انتظار دارند اسکرام بلافاصله مشکلات را حل کرده و نتایج خارق‌العاده‌ای همچون «تحویل سریع‌تر، ارزان‌تر و با کیفیت بالاتر» ایجاد کند. بنابراین، اسکرام‌مستر استخدام می‌شود، چند دوره‌ی آموزشی برگزار می‌گردد و تیم‌ها آغاز به کار می‌کنند.دوره‌ی گذار و هزینه‌ی تغییر:
برخی مدیران در ابتدا می‌پذیرند که اجرای اسکرام با هزینه‌هایی همراه است: افت موقت عملکرد، نارضایتی برخی کارکنان یا حتی ترک سازمان توسط عده‌ای از آنان. اما انتظار دارند که این وضعیت ظرف چند ماه بهبود یابد. در غیر این صورت، صبر خود را از دست می‌دهند و روند تغییر را متوقف می‌کنند.نادیده گرفتن ماهیت انسانی تغییر:
برخلاف خط تولید کارخانه‌ها، در سازمان‌ها با انسان‌ها طرف هستیم، نه ربات‌ها. کارکنان، گذشته، تجربه‌ها و هویت‌های حرفه‌ای متفاوتی دارند. برای نمونه، فردی که سال‌ها به عنوان «بیزینس آنالیست»، «بک‌اند دولوپر» یا «تستر» کار کرده است، این نقش بخشی از هویت اوست. تغییر این نقش و انتظار همکاری نزدیک در قالب تیمی کراس‌فانکشنال، به سادگی پذیرفته نمی‌شود.
بنابراین، مشکل اصلی در بسیاری از سازمان‌ها نه در ذات اسکرام، بلکه در مدیریت انتظارات و نحوه‌ی مواجهه با تغییر است.
یکی از مشکلات اساسی در پیاده‌سازی اسکرام (Scrum) این است که سازمان‌ها شرایط و بستر لازم برای کارکرد صحیح این چارچوب را فراهم نمی‌کنند. اسکرام همانند یک ابزار است که تنها در صورتی کارآمد خواهد بود که پیش‌نیازها و الزامات آن وجود داشته باشد. برای توضیح ساده‌تر، می‌توان مثالی آورد: مدیری قصد دارد یک پیچ را در دیوار محکم کند و برای این کار به دنبال پیچ‌گوشتی است. فروشنده به او پیشنهاد می‌دهد به جای پیچ‌گوشتی دستی، نوع برقی آن را تهیه کند که هم راحت‌تر است و هم تخفیف دارد. مدیر پیچ‌گوشتی برقی را می‌خرد، اما زمانی که به خانه می‌رسد متوجه می‌شود برق ندارد. در نتیجه، برای استفاده از آن ابزار باید زیرساختی جدید (سیم‌کشی برق) فراهم کند که هزینه‌ی آن بسیار بیشتر از خرید یک پیچ‌گوشتی دستی است.
این مثال بیانگر وضعیتی است که در بسیاری از سازمان‌ها رخ می‌دهد: اسکرام به سازمان آورده می‌شود، اما شرایطی که برای کارکرد آن ضروری است (مانند تیم‌های خودگردان، شفافیت در فرآیندها، و حذف موانع یا Impediments) وجود ندارد. حذف این موانع، به‌ویژه زمانی که به رفتارها و عادات انسانی گره خورده‌اند، بسیار پرهزینه و دشوار است.
از سوی دیگر، مدیران تنها تا زمانی حاضر به پرداخت این هزینه هستند که امید به بازدهی داشته باشند. اما در عمل، تغییر معمولاً با کاهش اولیه‌ی عملکرد همراه است. کارکنان سردرگم می‌شوند، تیم‌ها مقاومت می‌کنند، و بهره‌وری پایین می‌آید. این مرحله همان جایی است که در ادبیات تغییر سازمانی، به آن «منحنی J» (J-Curve) می‌گویند. در ابتدای تغییر، عملکرد افت می‌کند و در پایین‌ترین نقطه‌ی این منحنی است که بسیاری از مدیران تصمیم می‌گیرند «زیر میز بزنند» و پروژه‌ی تغییر را متوقف کنند.
در نتیجه، یا سازمان به وضعیت پیشین بازمی‌گردد، یا اسکرام به‌صورت ناقص و تحریف‌شده ادامه پیدا می‌کند. در این حالت، ممکن است عنوان «اسکرام‌مستر» به فردی داده شود، اما نقش واقعی او چیزی شبیه به «پروژه منیجر» یا «دلیوری منیجر» باقی بماند. به بیان دیگر، سازمان به جای تغییر واقعی، اسکرام را مطابق با سیاست‌ها و قوانین دیرینه‌ی خود تغییر می‌دهد و چیزی به نام «اسکرام کاستومایز شده» پدید می‌آید.
این وضعیت معمولاً ناشی از مقاومت‌های عمیق سازمانی است؛ قوانینی که طی سال‌ها در سازمان نهادینه شده‌اند و به بخشی از هویت و فرهنگ کاری تبدیل شده‌اند. از همین رو، بخشی از مدیران ارشد ممکن است از تغییر حمایت کنند، اما بخشی دیگر مقاومت نشان دهند. در نهایت، اگر فرد یا گروهی در سطح مدیریت ارشد وجود نداشته باشد که با قدرت تغییر را حمایت و «پوش» کند، سازمان به‌سادگی به حالت سابق بازمی‌گردد.
هرچه تغییرات سازمانی بزرگ‌تر باشد، منحنی J نیز عمیق‌تر و گسترده‌تر می‌شود و در نتیجه، هزینه و احتمال شکست افزایش می‌یابد. بازگشت افراد به شیوه‌های کاری پیشین غالباً ناشی از این است که یا راه‌حل پیشنهادی اساساً متناسب با مسئله‌ی آن‌ها نبوده است، یا اینکه آن‌ها آمادگی پذیرش چنین راه‌حلی را نداشته‌اند.
بسیاری از افراد، زمانی که در تیم‌های اسکرام (Scrum) قرار می‌گیرند، نه تنها کمتر با دیگران همکاری می‌کنند، بلکه حتی خودِ تیم به یک «سیلو» جدید تبدیل می‌شود. این موضوع نشان می‌دهد که پیش از ورود اسکرام، اگرچه همکاری‌ها کامل و بی‌نقص نبود، اما دست‌کم در یک چارچوب مشخص انجام می‌شد. با ورود اسکرام، نه تنها برخی مشکلات پیشین حل نمی‌شود، بلکه مسائل جدیدی نیز به آن اضافه می‌شود.
این نکته حائز اهمیت است که انسان‌ها ذاتاً با تغییر راحت نیستند. تغییر می‌تواند ارزشمند باشد، اما برای بسیاری از افراد استرس‌زا است. بیشتر انسان‌ها در یک «منطقه‌ی امن» یا Comfort Zone زندگی و کار می‌کنند؛ محیطی که شاید بی‌نقص نباشد، اما برایشان قابل پیش‌بینی و کنترل‌پذیر است. خروج از این محیط و ورود به فضایی که نیازمند یادگیری مداوم، همکاری بیشتر و پذیرش مسئولیت جمعی است، به‌سادگی پذیرفته نمی‌شود.
یکی از تغییرات بنیادینی که اسکرام به همراه دارد، «چندرشته‌ای بودن» یا Cross-functionality است. این تغییر به ظاهر ساده، در عمل بسیار بزرگ و پرچالش است. زیرا افراد باید مسئولیت‌پذیری بیشتری نسبت به تصمیم‌های تیمی داشته باشند. در گذشته، تصمیم‌های درست یا غلط بر عهده‌ی مدیران بود؛ اما اکنون اعضای تیم باید خودشان تصمیم بگیرند و عواقب آن را بپذیرند. این مسئولیت‌پذیری برای بسیاری از افراد نگران‌کننده است، چرا که می‌ترسند در صورت تصمیم نادرست، موقعیت شغلی‌شان به خطر بیفتد.
بر همین اساس، تجربه نشان می‌دهد که تغییرات کوچک و تدریجی (Incremental Changes) بسیار پایدارتر از تغییرات بزرگ و یک‌باره‌اند. اگر سازمان‌ها به جای ایجاد یک منحنی J بزرگ و پرریسک، مجموعه‌ای از منحنی‌های J کوچک‌تر و پی‌درپی ایجاد کنند، احتمال شکست کاهش می‌یابد و به مرور زمان، بلوغ تیم‌ها افزایش پیدا می‌کند. چنین تغییراتی برای افراد قابل‌تحمل‌تر بوده و می‌تواند در طول زمان به یک راه‌حل پایدار (Sustainable Solution) منجر شود.
در همین راستا، کانبان (Kanban) دقیقاً بر تغییرات کوچک، تدریجی و مداوم تأکید دارد. در حالی که اسکرام معمولاً هدفی نهایی و ایده‌آل را ترسیم می‌کند و سازمان‌ها را وادار می‌سازد قدم‌به‌قدم به سمت آن حرکت کنند، کانبان بر این باور است که مقصد نهایی از پیش مشخص نیست. سازمان تنها کافی است امروز یک تغییر کوچک و مؤثر انجام دهد، فردا تغییر دیگری، و همین روند را ادامه دهد. این نگرش موجب می‌شود مسیر تحول بر اساس شرایط واقعی شکل بگیرد، نه بر اساس یک تصویر ایده‌آل و از پیش‌تعیین‌شده.
در پایان این بخش، سه محور اصلی جمع‌بندی می‌شود:
مدیران زمانی زیر میز می‌زنند که هزینه‌ی تغییر از آستانه‌ی تحمل‌شان فراتر رود.
افراد در تیم‌ها به دلیل عادت‌ها، منطقه‌ی امن، و ترس از مسئولیت‌پذیری، در برابر تغییر مقاومت می‌کنند.
تغییرات کوچک و تدریجی به‌مراتب پایدارتر از تغییرات انقلابی و بزرگ هستند.
نکته‌ی مهمی که باید بر آن تأکید کرد این است که اسکرام (Scrum) ذاتاً مشکلات را حل نمی‌کند؛ بلکه آن‌ها را آشکار می‌سازد. اسکرام با ایجاد Timeboxing (زمان‌بندی محدود) و تقسیم کارها به بخش‌های کوچک، نقص‌ها و گره‌های سیستم را برجسته می‌کند و نشان می‌دهد که در چه بخش‌هایی سازمان دچار کندی یا اختلال است.
برای نمونه، فرض کنید برنامه‌نویسی امروز کدی می‌نویسد که باید دو روز بعد منتشر (Deploy) شود و پس از آن تست گردد. در یک پروژه‌ی یک‌ساله، این فاصله‌ی دو روزه چندان محسوس نیست. اما در اسپرینت (Sprint) ده‌روزه، چهار روز معطل‌ماندن برای انتشار، معادل ۴۰ درصد زمان کل اسپرینت است. همین امر بلافاصله ضعف فرآیند انتشار را آشکار می‌کند و سازمان را وادار می‌سازد به سمت انتشار خودکار (Automated Deployment) حرکت کند. به بیان دیگر، اسکرام مانند همان «پیچ‌گوشتی برقی» است که بدون برق بلااستفاده می‌شود: ابزار بد نیست، اما اگر شرایط لازم فراهم نباشد، کارکردی نخواهد داشت.
حال اجازه دهید به تجربه‌ای موفق اشاره کنم؛ تجربه‌ای که خود من را به اسکرام علاقه‌مند کرد و در نهایت مسیر حرفه‌ای مرا به سمت اسکرام تغییر داد. در یکی از نخستین پروژه‌هایی که در استرالیا تجربه کردم، یک اسکرام‌مستر خانم مسئولیت پیاده‌سازی اسکرام را بر عهده داشت. این پروژه به‌قدری موفق بود که بعدها در جامعه‌ی اجایل استرالیا به‌عنوان یک نمونه‌ی مهم مطرح شد.
پروژه مربوط به یک شرکت مخابراتی بود که خدمات اینترنت ارائه می‌داد. وظیفه‌ی تیم ما طراحی سرویسی بود که مشتری با وارد کردن آدرس خود می‌توانست ببیند چه نوع خدماتی در آن منطقه قابل ارائه است.
ترکیب تیم به این صورت بود:
یک Product Owner (مالک محصول) که شناخت کاملی از بیزینس داشت و وظیفه‌ی اولویت‌بندی نیازمندی‌ها را بر عهده گرفت.
فردی با تجربه‌ی بالا در سیستم، که به‌عنوان Subject Matter Expert انتخاب شد تا به پرسش‌های تیم پاسخ دهد.
چند Developer (توسعه‌دهنده) که هرکدام در بخش‌های مختلفی مانند Frontend و Backend تخصص داشتند.
و مهم‌تر از همه، تیم تستری اختصاصی وجود نداشت؛ بلکه توسعه‌دهندگان موظف بودند خودشان تست بنویسند.
در این تیم، رویکرد TDD (Test-Driven Development) اجرا می‌شد. به این معنا که ابتدا تست نوشته می‌شد و سپس کدی نوشته می‌شد که آن تست را پاس کند. این موضوع برای من که پیش‌تر تجربه‌ی برنامه‌نویسی در ایران را داشتم، کاملاً تازه و متفاوت بود. در عمل، توسعه‌دهندگان هم کد می‌نوشتند و هم تست‌های مرتبط را طراحی می‌کردند.
علاوه بر این، نقش‌ها انعطاف‌پذیر بودند. برای مثال، من که با زبان PHP وارد تیم شده بودم، به دلیل تجربه‌ی پیشینم در Java به‌تدریج بخشی از کارهای Backend را هم بر عهده گرفتم و عملاً در هر دو بخش Frontend و Backend مشارکت داشتم. این چندمهارته بودن (Cross-functionality) باعث شد همه‌ی سناریوهای مختلف کسب‌وکار و داده‌ها به‌خوبی پوشش داده شوند.
این تجربه‌ی موفق برای من روشن کرد که زمانی که شرایط لازم فراهم باشد، اسکرام می‌تواند کارآمد و بسیار اثربخش باشد. وجود یک اسکرام‌مستر توانمند، همکاری نزدیک با Product Owner، و پذیرش مسئولیت تست توسط خود توسعه‌دهندگان، همه عواملی بودند که این موفقیت را رقم زدند.
تیم ما شامل پنج تا هفت توسعه‌دهنده، یک Product Owner و یک Scrum Master بود. شرایط به‌گونه‌ای پیش رفت که زمانی که من کدی را می‌نوشتم، کامیت می‌کردم و Push می‌زدم، بلافاصله مجموعه‌ی تست‌های خودکار روی محیط Development اجرا می‌شد. در صورت موفقیت، کد به‌صورت خودکار Merge می‌شد و در نهایت، اگر همه‌چیز بدون مشکل پیش می‌رفت، به‌صورت خودکار روی محیط Production مستقر (Deploy) می‌گردید.
از لحظه‌ی ثبت کامیت تا استقرار نهایی روی محیط Production، معمولاً حدود ۴۰ دقیقه طول می‌کشید. البته ما کدها را به‌صورت محلی نیز آزمایش می‌کردیم، اما باز هم پیش می‌آمد که یکی از تست‌ها در محیط Development با خطا مواجه شود. در چنین شرایطی، ایمیلی به همه‌ی اعضا، حتی مدیرعامل (CEO)، ارسال می‌شد که مثلاً «فلانی بیلد را شکسته و فرآیند دیپلوی متوقف شده است».
این وضعیت بسیار سخت‌گیرانه بود؛ زیرا هر فرد تنها ۱۰ دقیقه فرصت داشت تا سیستم را به حالت پایدار بازگرداند. در غیر این صورت، یا باید مشکل را فوراً رفع (Roll Forward) می‌کرد یا سیستم را به نسخه‌ی قبلی بازمی‌گرداند (Roll Back). فشار زیادی روی اعضای تیم بود و بسیاری از توسعه‌دهندگان با این سازوکار مخالف بودند. اما به‌محض وقوع چنین مشکلی، سایر هم‌تیمی‌ها نیز وارد عمل می‌شدند و همکاری می‌کردند تا مشکل در سریع‌ترین زمان ممکن برطرف شود.
این سازوکار تنها در تیم ما اجرا می‌شد. در سازمانی حدوداً ۵۰۰ تا ۶۰۰ نفره، ما نخستین تیمی بودیم که اسکرام را به‌طور کامل پیاده‌سازی کرده بودیم. پس از مدتی، برخی تیم‌های دیگر نیز تلاش کردند همین الگو را اجرا کنند، اما موفق نشدند. در نهایت، Scrum Master تیم ما هم سازمان را ترک کرد و من نیز پس از مدتی از آن تیم جدا شدم.
با این حال، تجربه‌ی کار در آن تیم برای من یک الگوی «اسکرام کامل» یا Perfect Scrum بود؛ یعنی تقریباً تمام آنچه در منابع و کتاب‌ها به‌عنوان اجرای صحیح اسکرام بیان می‌شود، در عمل تجربه شد. بعدها که وارد سازمان‌ها و شرکت‌های دیگر شدم، متوجه شدم چنین شرایطی بسیار نادر است. بسیاری از سازمان‌ها یا هیچ فرآیند مشخصی نداشتند یا تنها بخش‌هایی از اسکرام را به‌صورت ناقص پیاده‌سازی کرده بودند.
این تجربه‌ی خاص، تصویری از اجرای کامل و دقیق اسکرام به من داد، اما در عین حال باعث شد بفهمم که چنین شرایطی در همه‌جا وجود ندارد و نمی‌توان آن را به‌سادگی تعمیم داد.
در همان بخش نرم‌افزاری، برای نخستین بار خودم تیم اسکرام تشکیل دادم. تلاش من این بود که بدون شناخت کامل از تمام جزئیات، شرایطی مشابه تجربه‌ی موفق قبلی ایجاد کنم. بنابراین شروع کردم به پیاده‌سازی برخی از همان قابلیت‌ها: نوشتن تست‌های خودکار، افزودن Code Review، و ایجاد فرآیند Deployment خودکار. هرچند به پیشرفته‌گی شرکت قبلی نبود، اما با نوشتن اسکریپت‌هایی روی لینوکس ــ در زمانی که عمدتاً از SVN استفاده می‌شد ــ توانستم این سازوکار را تا حدی بازتولید کنم. به این شکل که پس از ثبت Commit، اسکریپت‌ها به‌طور خودکار اجرا می‌شدند، تست‌ها ران می‌شد و پیام ساده‌ای به اعضای تیم ارسال می‌گردید که «کد در حال دیپلوی شدن است». این تجربه تا حد زیادی موفق بود.
در شرکت بعدی، که با عنوان Head of Technology فعالیت می‌کردم، اجرای اسکرام باز هم موفقیت‌آمیز بود؛ اما موفقیتی «دستوری». یعنی به واسطه‌ی اقتدار من و اجبار به رعایت قوانین، تیم پیش می‌رفت. به محض اینکه سازمان را ترک کردم، تمام ساختار فروپاشید؛ زیرا همه‌چیز وابسته به من بود و به‌صورت درونی نهادینه نشده بود.
از مجموع این تجربه‌ها آموختم که چه شرایطی برای کارآمدی یک تیم اسکرام ضروری است. نخستین شرط، وجود اعضایی است که توانایی انجام کارهای متنوع داشته باشند؛ به اصطلاح «T-Shaped». به این معنا که مثلاً توسعه‌دهنده‌ی بک‌اند بتواند در صورت نیاز روی فرانت‌اند یا تست نیز کار کند و بالعکس. هرچه تعداد افراد T-Shaped بیشتر باشد، کارایی تیم بالاتر می‌رود.
شخصاً ترجیح می‌دهم در تیم اسکرام افرادی موسوم به «ابر‌قهرمان» (Super Hero Developers) حضور نداشته باشند؛ یعنی کسانی که در یک حوزه بهترین هستند اما تمایلی به همکاری و تعامل با دیگران ندارند. از نظر من، داشتن توسعه‌دهندگان «متواضع» (Humble) که حاضرند دانش خود را به اشتراک بگذارند، سؤال بپرسند و به دیگران کمک کنند، ارزشمندتر از داشتن متخصصانی است که صرفاً در یک حوزه مهارت خارق‌العاده دارند. مثال ساده این است که تیمی با بهترین ستاره‌ها اما بدون روحیه‌ی کار گروهی، مانند باشگاه پاری‌سن‌ژرمن است که با وجود بازیکنان ممتاز، اغلب در رقابت‌های مهم شکست می‌خورد.
شرط مهم بعدی، حذف انتظارهای طولانی در فرآیند است. به بیان دیگر، وابسته نبودن تیم به افراد یا گروه‌های خارج از خود، و همچنین خودکار بودن عملیات کلیدی همچون Deployment و Integration. زیرا در بازه‌های دو هفته‌ای اسپرینت، چنین انتظارهایی قابل تحمل نیست و به سرعت به مانعی جدی تبدیل می‌شوند. اسکرام این مشکلات را نمایان می‌کند و تیم را وادار می‌سازد به‌دنبال راه‌حل باشد.
به‌عنوان نمونه، زمانی که تسترها بار کاری سنگینی دارند و توسعه‌دهندگان بیکار می‌مانند، منطقی است که توسعه‌دهندگان به تست کمک کنند. این همان مفهوم T-Shaped است. در عمل، برخی اعضای تیم در برابر چنین تغییراتی مقاومت می‌کنند و بهانه‌هایی مانند «تمرکز کار پایین می‌آید» یا «این کار تخصص من نیست» می‌آورند. درواقع، این نه یک تناقض با اسکرام بلکه یک مقاومت شخصی در برابر تغییر است.
در این میان، نقش اسکرام مستر بسیار حیاتی است. اسکرام مستر باید شرایطی فراهم کند که تیم بتواند به‌تدریج تست‌های خودکار را توسعه دهد، فرآیند Deployment و Integration را ساده و سریع کند، و وابستگی‌ها به تیم‌های خارجی را کاهش دهد. همچنین باید تیم را تشویق کند تا فرهنگ یادگیری، مسئولیت‌پذیری و تعامل را درونی کند، نه اینکه صرفاً با اجبار پیش رود.
در این‌جا باید اشاره کنم که تجربه‌ی من نشان داد شرایطی که اسکرام برای موفقیت نیاز دارد، به‌روشنی مشخص است. نخست آن‌که تیم باید توانایی انجام کارها را به‌صورت «عمودی» یا Vertical Slicing داشته باشد؛ یعنی هر ویژگی یا User Story باید از ابتدا تا انتها در همان تیم تکمیل شود و وابستگی به تیم‌های بیرونی حداقل باشد. اگر توسعه آغاز شود اما برای تست یا دیپلوی به تیم دیگری وابسته باشیم، نتیجه ناکارآمد خواهد شد.
از سوی دیگر، نقش Product Owner بسیار حیاتی است. اگر این فرد اختیار و استقلال تصمیم‌گیری نداشته باشد و مجبور باشد هر روز با چندین استیک‌هولدر مذاکره کند یا زیر فشار مدیران دیگر قرار گیرد، عملاً از تمرکز بر روی بک‌لاگ و نقشه‌ی محصول بازمی‌ماند. شرط لازم برای اجرای درست اسکرام این است که تصمیم‌گیری‌های محصولی در اختیار Product Owner باشد. اگر چنین اختیاری به او داده نمی‌شود، بهتر است اصلاً وارد مسیر اسکرام نشویم.
شرط مهم دیگر، مهارت‌های ارتباطی و توانایی گفت‌وگو در تیم است. اعضا باید بتوانند با یکدیگر مذاکره کنند، پیامدهای تصمیمات خود را توضیح دهند و با صداقت مسائل را مطرح کنند. اساساً «اعتماد» پایه‌ی موفقیت تیمی است. اگر بین اعضا اعتماد وجود نداشته باشد، همکاری واقعی شکل نمی‌گیرد. این اعتماد به‌سادگی و در کوتاه‌مدت ایجاد نمی‌شود؛ بلکه نیازمند سیاست‌های سازمانی درست است.
اگر سازمان بر ارزیابی فردی تمرکز کند، اعضا صرفاً به منافع شخصی خود می‌اندیشند. اما اگر تمرکز بر عملکرد تیمی باشد، به‌مرور اعتماد شکل می‌گیرد. اعضا درمی‌یابند که ممکن است امروز من اشتباه کنم و فردا دیگری، اما در نهایت موفقیت تیم مهم‌تر است. اینجاست که انگیزه برای کمک‌کردن به یکدیگر تقویت می‌شود.
به‌طور خلاصه:
استقلال Product Owner در تصمیم‌گیری.
توانایی تیم برای تکمیل عمودی کارها بدون وابستگی شدید به بیرون.
مهارت ارتباطی و ایجاد اعتماد متقابل.
تمرکز سازمان بر عملکرد تیم به جای عملکرد فردی.
هر زمان این شرایط فراهم بوده، اسکرام در تجربه‌ی من به‌خوبی عمل کرده است؛ و هرگاه نبوده، شکست یا ناکارآمدی طبیعی بوده است.
مدل‌های رهبری در تیم‌های اسکرام تفاوت‌های چشمگیری دارند. سه الگوی اصلی که می‌توان به آن‌ها اشاره کرد عبارتند از:
رهبر کارشناس (Expert Leader):
فردی است که خود بیشترین دانش و مهارت را دارد و در عمل بسیاری از کارهای دشوار را شخصاً انجام می‌دهد. ایراد این مدل آن است که دیگر اعضا فرصت رشد پیدا نمی‌کنند. همانند والدینی که مشق یا تمرین ریاضی فرزند خود را به‌جای او می‌نویسند: نتیجه موقتاً خوب است، اما فرد در بلندمدت چیزی نمی‌آموزد. در تجربه‌ای که داشتم، زمانی که از تیم جدا شدم، هیچ‌کس نمی‌دانست فرایندها دقیقاً چگونه باید انجام شوند و کل سیستم از هم پاشید.رهبر فرمانده یا رهبر ارکستر (Conductor Leader):
این دسته شبیه رهبر ارکستر است که خود هیچ‌گاه ساز نمی‌زند، بلکه فقط دستور می‌دهد. اگر کاری درست انجام شود، نتیجه را به نام خود ثبت می‌کند و اگر شکست بخورد، تقصیر را به گردن اعضای تیم می‌اندازد. این سبک عملاً به میکرومدیجمنت منجر می‌شود و استقلال تیم را از بین می‌برد.رهبر خدمتگزار (Servant Leader):
این الگو همان چیزی است که در اسکرام بیش از همه توصیه می‌شود. رهبر خدمتگزار وظیفه‌ی اصلی خود را رشد دادن افراد می‌داند. اگر یک عضو تیم مهارتی دارد، اسکرام مستر کمک می‌کند سه نفر دیگر نیز آن مهارت را بیاموزند. نتیجه آن است که اگر فرد اصلی در دسترس نباشد، تیم همچنان قادر به ادامه‌ی کار خواهد بود، هرچند شاید با کیفیت پایین‌تر.
تجربه نشان داده است که بهترین راه برای پرورش تیم، سپردن کارها به اعضا و همراهی در فرآیند یادگیری است:
به جای آن‌که اسکرام مستر خود، دیپلوی را انجام دهد، باید آموزش دهد و بگذارد اعضا مسئولیت را به عهده بگیرند.
به جای نوشتن یوزر استوری‌ها برای تیم، باید به اعضا فرصت داد که خود آن‌ها را تدوین کنند، حتی اگر ابتدا با خطا همراه باشد.
به تعبیر رایج، این همان یاد دادن ماهیگیری است، نه دادن ماهی آماده.
در این‌جا به نکته‌ی مهم دیگری هم باید اشاره کرد: بسیاری از شکست‌های سازمان‌ها در پیاده‌سازی اسکرام، تنها ناشی از مقاومت مدیران یا ضعف تیم نیست. بخش مهمی از مشکل به خود اسکرام مسترها و مشاورانی بازمی‌گردد که اسکرام را به سازمان‌ها معرفی می‌کنند. آنان گاه تنها جنبه‌های مثبت و ساده‌ی اسکرام را نشان می‌دهند، بدون آن‌که به دشواری‌های واقعی و تغییرات فرهنگی عمیق موردنیاز اشاره کنند. همین امر موجب می‌شود که مدیران با تصویری غیرواقعی وارد مسیر شوند و در نخستین بحران، «زیر میز بزنند».
در این گفت‌وگو به بررسی دلایل اصلی شکست در پیاده‌سازی اسکرام پرداخته شد. نخست توضیح داده شد که چرا بسیاری از مدیران، پس از مدتی، «زیر میز اسکرام می‌زنند». علت اصلی این است که آن‌ها تغییر را ساده‌انگارانه می‌بینند و از پیچیدگی رفتار انسان‌ها غافل می‌شوند. مدیران معمولاً بازه‌ی زمانی کوتاهی را برای مشاهده‌ی نتایج در نظر می‌گیرند. هنگامی که عملکرد تیم به سرعت بهبود نمی‌یابد و هزینه‌ها افزایش پیدا می‌کند، تصمیم به توقف تغییر می‌گیرند.
در ادامه، تجربه‌ای شخصی مطرح شد که نشان می‌داد اسکرام مشکل‌ها را حل نمی‌کند، بلکه آن‌ها را آشکار می‌سازد. با تایم‌باکسینگ و کوتاه‌سازی چرخه‌ها، نارسایی‌های موجود ــ مانند نبود اتوماسیون تست، وابستگی به تیم‌های بیرونی، یا فقدان اعتماد و ارتباط میان اعضا ــ برجسته می‌شوند. این مشکلات همانند «خانه‌ای بدون برق» هستند: ابزار پیشرفته خریداری شده است، اما زیرساخت فراهم نیست.
از دل این تجربه‌ها، شرایطی استخراج شد که برای موفقیت اسکرام ضروری‌اند:
اعضای تیم باید مهارت‌های متنوع داشته باشند و به‌صورت تی‌شکل (T-shaped) فعالیت کنند.
فرآیند یکپارچه‌سازی و استقرار مداوم (CI/CD) باید پیاده شود تا انتظارهای طولانی از میان برود.
اعتماد و توانایی ارتباط مؤثر میان اعضا باید تقویت گردد.
صاحب محصول (Product Owner) باید اختیار تصمیم‌گیری مستقل داشته باشد و اولویت‌ها را روشن سازد.
وابستگی تیم به واحدهای بیرونی باید به حداقل برسد.
همچنین به نقش حیاتی اسکرام مستر پرداخته شد. برخی از شکست‌ها ناشی از خود اسکرام مسترها هستند که رویکرد بالا به پایین را در پیش می‌گیرند و صرفاً جملات کتابی را تکرار می‌کنند. در حالی که اسکرام مستر واقعی، نه «پلیس اسکرام»، بلکه رهبر خدمتگزار (Servant Leader) است: فردی که بستر رشد تیم را فراهم می‌کند، اعتمادسازی می‌نماید و به اعضا می‌آموزد خودشان وظایف را انجام دهند.
جمع‌بندی این بود که هدف نهایی، نه «اجرای اسکرام به هر قیمت»، بلکه حل مسئله‌ی مشتری و افزایش چابکی سازمان است. هر ابزاری که در این مسیر یاری‌رسان باشد ارزشمند است؛ خواه اسکرام باشد، خواه کانبان یا هر رویکرد دیگر. تغییرات نیز باید تدریجی و متناسب با ظرفیت انسان‌ها اعمال شوند تا پایدار بمانند.
اجایل گپ را می‌توانید از طریق شبکه‌های اجتماعی لینکدین، اینستاگرام و تلگرام دنبال کنید
