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