تمرین تیم‌سازی در چارچوب Scrum

اسکرام نه متدولوژی است، نه ابزار کنترل

سوءتفاهمی که چابکی را در سازمان‌ها خفه می‌کند

اسکرام یک متدولوژی یا فرآیند حاکمیتی نیست

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

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

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

بسیاری از تیم‌های اسکرام در سازمان‌هایی کار می‌کنند که به مدیریت ریسک اهمیت زیادی می‌دهند. این سازمان‌ها می‌خواهند مطمئن شوند که منابع مالی به‌طور اثربخش و هم‌راستا با اهداف کسب‌وکار هزینه می‌شود، استانداردهای امنیت و ایمنی رعایت شده‌اند، و سازمان در معرض ریسک‌های حقوقی یا مقرراتی قرار نمی‌گیرد. برای کنترل این ریسک‌ها، چنین سازمان‌هایی فرآیندهای حاکمیتی (Governance) را پیاده‌سازی می‌کنند.

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

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

¹ با اجازه. برگرفته از Merriam-Webster.com © 2019، شرکت Merriam-Webster

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

اسکرام دقیقاً برای محیط‌هایی طراحی شده که راه‌حل از قبل معلوم نیست؛ جایی که عدم‌قطعیت، تغییر و پیچیدگی، ویژگی ذاتی مسئله‌اند، نه استثنا.

چرا متدولوژی‌ها در دنیای پیچیده شکست می‌خورند؟

تعریف کلاسیک متدولوژی ساده است:
مجموعه‌ای از روش‌ها، قواعد و رویه‌های از پیش تعیین‌شده که فرض می‌کنند:

  • مسئله به‌درستی شناخته شده
  • راه‌حل مشخص است
  • مسیر رسیدن به آن قابل پیش‌بینی است

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

در حوزه‌های پیچیده:

  • مسئله هنگام حل شدن تغییر می‌کند
  • راه‌حل در طول مسیر شکل می‌گیرد
  • یادگیری مهم‌تر از پیروی از برنامه است

در چنین شرایطی، آنچه کار می‌کند رویکرد تجربی (Empirical) است، نه متدولوژی.

اسکرام چیست؟ چارچوبی با حداقل مرز، حداکثر یادگیری

اسکرام یک متدولوژی نیست.
اسکرام یک چارچوب فرآیندی حداقلی است که عمداً:

  • نسخه آماده نمی‌دهد
  • روش مشخص تحمیل نمی‌کند
  • تکنیک واحد معرفی نمی‌کند

در عوض، اسکرام سه چیز را تضمین می‌کند:

  1. شفافیت
  2. بازرسی
  3. انطباق

این سه ستون، به تیم اجازه می‌دهند:

  • فرآیند خود را بسازند
  • تکنیک‌های مناسب خود را انتخاب کنند
  • و بر اساس یادگیری واقعی، آن‌ها را تغییر دهند

به همین دلیل است که پیاده‌سازی اسکرام در دو تیم یا دو محصول هرگز یکسان نیست. اگر یکسان باشد، یعنی اسکرام به‌درستی فهم نشده است.

اسکرام و وسوسه‌ی کنترل سازمانی

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

  • مدیریت ریسک
  • انطباق با قوانین و مقررات
  • امنیت، ایمنی و مسئولیت حقوقی
  • هم‌راستایی هزینه‌ها با اهداف کسب‌وکار

برای پاسخ به این دغدغه‌ها، سازمان‌ها معمولاً سراغ Governance Process می‌روند؛ فرآیندهایی که هدفشان کنترل، تأیید، و کاهش عدم‌قطعیت است.

مشکل از جایی شروع می‌شود که:

اسکرام به‌اشتباه به‌عنوان یکی از همین فرآیندهای کنترلی استفاده می‌شود.

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

اسکرام ابزار حاکمیتی نیست، اما دشمن ریسک هم نیست

نکته‌ی ظریف اما کلیدی اینجاست:
اسکرام فرآیند حاکمیتی نیست، اما به مدیریت ریسک کمک می‌کند.

نه با کنترل بیشتر، بلکه با شفاف‌سازی.

اسکرام:

  • اتلاف‌های پنهان سازمانی را آشکار می‌کند
  • فاصله‌ی تصمیم تا اجرا را کوتاه می‌کند
  • ناسازگاری‌ها با اهداف کسب‌وکار را زودتر نمایان می‌کند
  • امکان اصلاح مسیر را قبل از دیرشدن فراهم می‌آورد

وقتی هر اسپرینت یک اینکریمنت «Done» تولید می‌شود، ریسک تحویل، ریسک کیفیت و ریسک هم‌راستایی به‌طور مداوم مدیریت می‌شوند—نه در انتهای پروژه، بلکه در طول آن.

اشتباه استراتژیک: تعریف روش به‌جای تعریف نتیجه

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

  • به‌جای تعریف نتایج مورد انتظار
  • روی تعریف روش‌های اجرایی تمرکز می‌کنند

در حالی که حاکمیت مؤثر باید بگوید:

  • چه سطحی از ریسک قابل‌قبول است
  • چه استانداردهایی باید رعایت شوند
  • چه نتایجی باید محقق شود

و سپس اجازه دهد تیم‌ها:

  • بهترین راه رسیدن به آن نتایج را خودشان پیدا کنند

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

Done: نقطه تلاقی تحویل، کیفیت و ریسک

تمرکز بی‌وقفه بر یک اینکریمنت «Done» فقط یک اصل فنی نیست؛ یک سیاست مدیریت ریسک است.

Done یعنی:

  • کاری که واقعاً قابل استفاده است
  • کیفیت‌ای که قابل دفاع است
  • تصمیمی که قابل بازگشت یا اصلاح است

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

  • یاد می‌گیرد
  • فرضیاتش را می‌سنجد
  • و ریسک‌هایش را به‌روز می‌کند

این همان چیزی است که هیچ متدولوژی خطی و هیچ فرآیند کنترلی سنگین قادر به انجامش نیست.

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

اگر اسکرام را:

  • متدولوژی کنید، می‌میرد
  • ابزار کنترل کنید، خفه می‌شود
  • جایگزین حاکمیت بدانید، شکست می‌خورد

اما اگر اسکرام را آن‌طور که هست بپذیرید:

  • یک چارچوب یادگیری
  • یک سیستم شفاف‌سازی
  • یک موتور انطباق مداوم

آنگاه اسکرام نه‌تنها با حاکمیت و مدیریت ریسک در تضاد نیست، بلکه آن‌ها را هوشمندتر، سبک‌تر و مؤثرتر می‌کند.

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


منتورینگ رایگان مالکین محصول

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


دیدگاه‌ها

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

error: اجازه کپی محتوا وجود ندارد