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