چرا بعضی تحول‌های Agile به جلسه و ابزار ختم می‌شوند؟

مسئلهٔ واقعی چیست؟

بسیاری از تیم‌ها با یک نیت درست سراغ Agile می‌روند: می‌خواهند سریع‌تر یاد بگیرند، کار را شفاف‌تر کنند و فاصلهٔ بین ایده تا نتیجه را کم کنند. بعد، طبیعی است که از Scrum، backlog، sprint، retrospective و یک ابزار مدیریت کار شروع کنند. این‌ها ابزارهای مفیدی هستند، اما هیچ‌کدام به‌تنهایی outcome تولید نمی‌کنند.

مشکل از جایی شروع می‌شود که نشانه‌های قابل‌مشاهدهٔ Agile جای خود Agile را می‌گیرند. تیم می‌پرسد آیا همه در Daily حاضر بودند، آیا sprint planning برگزار شد و آیا همهٔ کارت‌ها روی برد وضعیت دارند. مدیر هم از روی تعداد storyهای بسته‌شده دربارهٔ پیشرفت قضاوت می‌کند. در این میان سؤال اصلی کم‌رنگ می‌شود: آیا کار مهم‌تری را بهتر و زودتر به کاربر رسانده‌ایم؟

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

آیا اجرای درست مراسم Scrum یعنی تحول Agile موفق شده است؟

نه. اجرای مراسم فقط می‌تواند نشان دهد تیم یک ریتم مشترک پیدا کرده است. برای فهمیدن اثر تحول باید ببینیم این ریتم چه چیزی را بهتر کرده است. Review بدون گفت‌وگو با کاربر یادگیری ایجاد نمی‌کند، Retrospective بدون تغییر رفتار بی‌اثر است و Daily که دورخوانی status باشد، مانع تصمیم‌گیری را حل نمی‌کند.

بهتر است سه لایه را از هم جدا کنیم:

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

جریان ارزش را چگونه از روی تقویم جلسه‌ها تشخیص دهیم؟

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

این نگاه معمولاً چیزهایی را نشان می‌دهد که در گزارش sprint دیده نمی‌شوند:

از اینجا به بعد، ابزار فقط برای دیدن جریان کمک می‌کند. تصمیم اصلی این است که کدام انتظار، handoff یا ابهام را باید حذف یا کوتاه کنیم.

• کارهای زیادی شروع شده‌اند اما تعداد کمی به مرحلهٔ یادگیری رسیده‌اند.
• تصمیمی که باید در یک گفت‌وگو گرفته شود، چند روز بین محصول، طراحی و فنی رفت‌وبرگشت دارد.
• تیم feature را تحویل می‌دهد، اما کسی مالک بررسی نتیجه و رفتار کاربر نیست.
• یک مرحلهٔ تأیید یا handoff گلوگاه اصلی است، نه کمبود سرعت برنامه‌نویسی؛ backlog هم پر است، اما مسئله و معیار موفقیت آیتم‌ها روشن نیست.

نقش Product Manager و رهبر تیم در این تغییر چیست؟

Product Manager نباید Agile را به تیم فنی واگذار کند و بعد فقط گزارش تحویل بخواهد. او باید outcome، موارد خارج از دامنه و شواهد تغییر اولویت را روشن کند. اگر هر درخواست ذی‌نفع به ticket تبدیل شود، backlog بزرگ‌تر می‌شود اما تصمیم محصول بهتر نمی‌شود.

رهبر تیم هم نباید نقش خود را به کنترل velocity یا پرکردن برد محدود کند. او باید شرایطی بسازد که وابستگی‌ها زود دیده شوند، ریسک فنی پنهان نماند و افراد بتوانند دربارهٔ توقف یا تغییر مسیر صحبت کنند.

همکاری این دو نقش در چهار سؤال خلاصه می‌شود:

این پرسش‌ها جای Scrum را نمی‌گیرند؛ آن را در خدمت تصمیم محصول قرار می‌دهند.

• مسئلهٔ اصلی که می‌خواهیم حل کنیم چیست؟
• کوچک‌ترین خروجی‌ای که امکان یادگیری می‌دهد کدام است؟
• چه کسی مالک تصمیم و بازبینی نتیجه است؟
• اگر شواهد خلاف فرض ما بود، چه چیزی را متوقف یا اصلاح می‌کنیم؟

چه زمانی ابزار به‌جای حل مسئله، مسئلهٔ جدید می‌سازد؟

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

پیش از خرید یا جابه‌جایی ابزار، سه آزمایش کم‌هزینه انجام دهید:

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

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

یک تحول Agile موفق چه trade-offهایی دارد؟

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

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

در دو هفتهٔ اول چه کاری انجام دهیم؟

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

معیار موفقیت الزاماً افزایش سرعت نیست؛ می‌تواند روشن‌ترشدن مالکیت، کمترشدن انتظار، کاهش کارهای هم‌زمان یا سریع‌ترشدن تصمیم دربارهٔ یک فرضیه باشد. معیار باید پیش از آزمایش با تیم توافق شود.

• روز اول: مسئله و outcome مورد انتظار را در یک جمله بنویسید.
• روز دوم: مسیر کار تا بازخورد کاربر را رسم و انتظارها و handoffها را علامت بزنید.
• روز سوم: یک گلوگاه قابل‌حل و مالک تصمیم‌های معطل را مشخص کنید.
• هفتهٔ اول: کارهای هم‌زمان را محدود کنید؛ در هفتهٔ دوم، Review را به گفت‌وگوی شواهد و Retrospective را به تغییر یک رفتار اختصاص دهید.
• پایان هفتهٔ دوم: تصمیم بگیرید آزمایش ادامه پیدا کند، اصلاح شود یا متوقف شود؛ نه اینکه صرفاً مراسم کامل‌تر شوند.

جمع‌بندی: تحول را از رفتار و نتیجه بسنجیم، نه از ظاهر فرایند

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

برداشت اجرایی من این است: پیش از اصلاح ceremony، جریان واقعی را ببینید؛ پیش از خرید ابزار، گلوگاه را نام‌گذاری کنید؛ و پیش از اعلام موفقیت، تغییر رفتار یا outcome را مشخص کنید. برای ارتباط با نقش‌های محصول، از Scrum Master تا Product Lead و برای طراحی جریان عملی، راهنمای نقشه‌برداری و اتوماسیون workflow را بخوانید.