مشکلات فرآیندی
به جای اینکه حقوق و دریافتی، عناوین شغلی، ترفیع و پاداش را با چابک سازی هم سو کنید، در افراد برای کار تیمی و مسئولیت مشترک انگیزه ایجاد کنید.
حتی اگر همه امور صحیح و طبق برنامه پیش برود، استفاده نادرست از فرآیندها، تقریباً هر پروژه چابکی را از بین خواهد برد. جان نمونه ای عالی از یک کابوس فرآیندی است و بهترین خرابکاری هایش را بدون اینکه بداند، انجام داده است. جان توسعه دهنده ارشد تیم مستقر در شیکاگو بود که طراحی نرم افزاری برای تأیید یا رد درخواست های وام را به عهده داشت. او علاوه بر توسعه دهنده ارشد، اسکرام مستر نیز بود (دقت کنید که چگونه گام اول خود را با پذیرش دستورالعمل ۱۳، که به خودی خود می تواند ویران کننده باشد، برداشت).
جان و تیمش تازه با مفهوم اجایل و اسکرام آشنا شده بودند و سعی داشتند از شر قسمت های غیر ضروری آن خلاص شوند. آنها سریعا جلسات روزانه را لغو کردند چرا که همه تیم در یک دفتر کار می کردند و بیشتر مکالمات رد و بدل شده در آنجا توسط همه شنیده می شد.
همچنین تصور می‌کردند که انجام تست خودکار، غیر ضروری است. از آنجایی که برنامه آنها، برنامه جدیدی بود، شانسی برای خراب کردن کدهای قدیمی نداشتند و از آنجایی که هر فرد کدهای جدید به ذهنش می رسید احتمال کم ولی ممکنی برای خراب شدن این کدها وجود داشت. با این حال جان و همکارانش بازآفرینی و مالکیت کدها را پذیرفته بودند.
قانون جدید آنها این بود که هر برنامه نویس می تواند کد دیگری را در هر زمان تغییر دهد. آنها به زودی دریافتند که بدون وجود شبکه ایمن، تست های خودکار برای جلوگیری از اشتباه حین تغییر کد، بازسازی و مالکیت کد می‌تواند بسیار خطرناک باشد. جان و تیمش ناخواسته درگیر این دو دستورالعمل برای شکست خوردن اسکرام شدند.
دستورالعمل ۱۴: فرآیندهای اسکرام را قبل از اینکه بر اساس راهنمای اسکرام پیش ببرید، شخصی سازی کنید.
دستورالعمل ۱۵: قبل از درک کامل راهنمای های مهم اسکرام، آن را رها کرده و شخصی سازی کنید (مواردی از آن را به دلخواه حذف کنید).
ما به عنوان راهنما با تیم های زیادی مواجه می شویم که تکنیکی را یاد گرفته اند یا کاری به آنها محول شده و حتی زمانی که نیازی به آن تکنیک نیست نیز آن را انجام می دهند.
دستورالعمل ۱۶: ترفند‌های اسکرام را بدون درک اصول پایه ای و مانند برده (بی چون و چرا) دنبال کنید.
اگر در اجرای دستورالعمل های ۱۴ تا ۱۶ ناموفق بودید و پروژه چابک شما، علی‌رغم تلاش های شما موفق شده است، به راحتی و بدون تغییر هیچ چیزی می توانید یک پروژه موفق را متوقف کنید.
از تیم استاتوس‌کیو الگوبرداری کنید. استاتوس‌کیو برای ساخت سیستم جدید رزرواسیونی مبتنی بر وب (سیستم رزرو آنلاین) انتخاب شده بود و شروع خوبی هم داشت. اعضای تیم با مفهوم اسکرام نا آشنا بودند اما تحقیقات پیشرفته ای در ارتباط با آن انجام دادند و تعدادی از افراد خود را برای دریافت گواهی اسکرام مستر اعزام کردند.
پروژه به سرعت از شیوه های جدید بهره مند شد. استاتوس‌کیو در عرض یک ماه، وب سایت ساده ای را راه اندازی کرد و با نمایش چند رابط کلیدی به مشتریان خود، خاطر نشان کرد که ایده آنها از یک سیستم رزرواسیون در دسترس و قدرتمند، عملی خواهد بود.
استاتوس‌کیو هیچگاه در پایان هر اسپرینت بازنگری انجام نداد. اسکرام مستر هم اصراری به انجام این کار نداشت چرا که آن را لازم نمی دید. همه چیز به طرز شگفت انگیزی خوب کار می کرد. شما نیز می توانید اگر قرار بر بررسی طرح های قدیمی در جلسه ای شد، با شکایت مکرر از اسکرام مستر و اعضای تیم، این رفتار را در تیم خود ترویج دهید. به آنها گوشزد کنید که نشستن و صحبت کردن در مورد پروژه ای که به خوبی پیش می رود اتلاف وقت است و بازنگری گذشته تنها زمانی معنا پیدا می‌کند که همه چیز اشتباه پیش رفته باشد.
کارها در استاتوس‌کیو با گذشت زمان کندتر پیش می رفتند. نرخ تغییر و رشد پایه ای کد باعث ایجاد مشکلات بازنگری شده بودند. تغییراتی که در سیستم ایجاد می‌شد قرار بود برایشان مفید باشد، اما برنامه (کد سیستم اجرایی) نمی توانست همگام با این تغییرات پیش رود. کد سیستم انقدر بی ثبات شد که به نظر می رسید پروژه در حال پس‌رفت کردن است. سرانجام مدیریت شرکت وارد عمل شد، تغییرات را متوقف کرد و قرارداد را با نصف قیمت به پایان رساند.
این تیم نا آگاهانه دو دستورالعمل بعدی را برای شکست اسکرام به ما نشان دادند.
دستورالعمل ۱۷: مدام اصلاحات را انجام ندهید.
دستورالعمل ۱۸: رویه های فنی را تغییر ندهید.
مشکلات و مسائل فرآیند شرکت ممکن است در ابتدا به نظر غیرمرتبط با پروژه بیایند اما می توانند تأثیر منفی بر روحیه و انگیزه تیم داشته باشند. مثلا پرونده دیو را ببینید، هنرمند نوظهوری که برای توسعه دهنده بازی تلفن همراه، کار می‌کرد. استفاده از اسکرام توسط شرکت به نظرش عملی منطقی بود پس از این کار استقبال کرد. تیم های جدید اسکرام متشکل از برنامه نویسان، هنرمندان، طراحان و افرادی دیگر از رشته های مختلف بودند. همگی برای ایجاد و تکرار بازی به یکدیگر متکی بودند. اگر عملکرد هنرمندان خوب بود، کل تیم خوب به نظر می رسید. دیو معمولا کارهای اصلی خود را کنار می‌گذاشت تا از طریق اجرای امور هنری به هم تیمی‌های خود برای بهبود بازی کمک کند. این اغلب به قیمت ناتمام ماندن کار خودش تمام می شد؛ اما برای دیو، هدف تیمی ارجحیت داشت.
تیم دیو کاری عالی عرضه کرد، به شهرت رسید، هزاران نسخه از بازی را فروخت و سود قابل توجهی را برای شرکت به ارمغان آورد.
دیو اولین جلسه بررسی عملکرد خود را با هنرمند ارشد شرکت، در پایان سال داشت و وقتی فهمید پاداش سالانه اش ناچیز است، شوکه شد. به دیو گفته شد که اهداف تولیدات هنری خود را انجام نداده است و به همین دلیل هنرمند ارشد شرکت تصمیم بر کاهش پاداش سالانه‌اش گرفته است. در آخر معلوم شد که هنرمند ارشد به جای اینکه مقدار واقعی کاری را که دیو انجام داده مد نظر قرار دهد، تعداد وظایفی که به او محول شده بود را حساب می‌کرد.
دیو با ناراحتی به تیم خود بازگشت و به خود قول داد که کارهای اصلی خود را نسبت به نیازهای تیم در اولویت قرار دهد. دستورالعمل ۱۹ می تواند برنامه کمکی شما برای شکست اسکرام در سازمان شما باشد.
دستورالعمل ۱۹: به جای اینکه حقوق و دریافتی، عناوین شغلی، ترفیع و پاداش را با چابک سازی هم سو کنید، در افراد برای کار تیمی و مسئولیت مشترک انگیزه ایجاد کنید.
اصل مشترک همه فرآیندهای چابک این است که کار بر اساس ارزش حاصل از ویژگی ها، اولویت بندی می‌شود. عوامل دیگر مانند ریسک و ایجاد آگاهی نیز در نظر گرفته می شوند، اما اندازه ارزش ارائه شده همچنان عامل غالب است. روشی که قطع به یقین منجر به شکست چابک می شود، نادیده گرفتن این اصل و پیروی از دستورالعمل ۲۰ است.
دستورالعمل ۲۰: به خود تلقین کنید که قادر هستید تمام کارهایی که به شما محول شده را انجام دهید، پس نیازی به اولویت بندی کارها ندارید.
علاوه بر موارد بررسی شده، راه های دیگری نیز برای شکست وجود دارد که ممکن است قبلاً با تلاش در خراب کردن پروژه موفق خود، برخی از آنها را به تنهایی کشف کرده باشید. البته احتمالاً به روی خود نمی آورید که آنها را کشف کردید زیرا بسیار مهم است که تا زمانی که کار از کار گذشته باشد راجب اشتباهات صحبت نشود. مطمئن هستیم که با به کارگیری دقیق دستورالعمل ها یا دستورالعمل‌هایی که فقط شما می شناسید می توانید از پیاده سازی موفق اسکرام در پروژه های خود جلوگیری کنید.
