چرا اسکرام (Scrum) مزخرف است!

امروز سر کلاس مهندسی کامپیوتر داشتم در مورد فرآیند‌های توسعه‌ی نرم‌افزار و متدولوژی‌های محبوب این روز‌ها صحبت می‌کردم که به بحث داغ اسکرام (Scrum) رسیدیم. وسط بحث بودیم که یکی از دانشجو‌هام گفت:

این که خیلی مزخرفه!

با اینکه برای دادن چنین فیدبکی خیلی زود بود و احتمالا هنوز اصل مطلب رو نگرفته بود اما من رو یاد چند سال پیش خودم انداخت. سال ۹۲ بود که من به عنوان مهندس کامپیوتر (Android Developer) وارد شرکت تدبیرگستران شدم و برای اولین بار واژه‌ی اسکرام به گوشم خورد و اولین فیدبکم همین بود: چقد مزخرف!

تا قبل از اون من فقط با RUP کار کرده بودم، یه متدولوژی نسبتا قدیمی که این روزها دیگه کمتر کسی ازش حرفی به میون میاره. توی متدولوژی RUP، طراحیِ مهندسی و همینطور داکیومنتیشن اهمیت ویژه‌ای داشتند و من خیلی روی مهارت طراحیِ مهندسی و داکیومنتیشن خودم کار کرده بودم. اما اسکرام (و بطور کلی متدولوژی‌های Agile) اهمیتی برای این موضوع قائل نبودند و درست کارکردن نرم‌افزار در لحظه رو مهم‌تر از داکیومنت کردن آن برای نگه‌داری و توسعه‌ در آینده می‌دیدند. اگر چه بعدها متوجه دلیل این رویکرد شدم اما در آن زمان حس خوبی به آن نداشتم. یک سال بعد، شرکت دیجی‌کالا (که هنوز بسیار جوان بود و تبدیل به غول اینترنتی ایران نشده بود) متوجه پتانسیل نهفته در اپلیکیشن‌های موبایل شد و تصمیم به توسعه‌ی اپلیکیشن اندروید در کنار وب‌سایتش گرفت و برای من یک Job Offer فرستاد. زندگی کاری من در دیجی‌کالا متحول شد. پس از مدتی من سرپرست تیم برنامه‌نویسی موبایل (Head of Mobile Development) بودم که شرکت سرمایه‌گذار دیجی‌کالا (سرآوا)، از سهراب سلیمی، بنیانگزار Scrum Academy دعوت کرد که یک ورکشاپ آموزشی چندروزه برای سرپرستان شرکت‌های زیرمجموعه (دیجی‌کالا و کافه‌بازار و ANetwork و ...) برگزار کند. در آن ورکشاپ، من تازه فهمیدم اسکرام چیست و متوجه شدم ما و بیشتر مجموعه‌های دیگه با برداشت‌های سطحی خودمون از اسکرام فقط یک پیاده‌سازی اشتباه از آن را دنبال می‌کنیم که نه تنها خوب نبود بلکه به نظر من حتی بدتر از بی‌فرآیندی بود.

اگر فکر می‌کنید شما اسکرام رو به‌درستی پیاده‌سازی کرده اید موارد زیر رو بررسی کنید:

- تا به حال شده یک فیچر رو پیاده‌سازی کنید و در انتها، کارفرما نظر خود و نیازمندی قبلی را تغییر دهد؟ اگر ازین موضوع آزرده شدید و می‌خواستید بگید الان دیگه به راحتی نمیشه اینطور که میخوای تغییرش داد، یعنی اصلا شما Agile نیستید چه برسه به اسکرام. چون Agile بودن فقط یک معنی دارد و آن هم توانایی واکنش سریع نسبت به تغییرات در نیازمندی است.
- اگر در تیم کسی رو دارید (معمولا Product Owner) که به جز اولویت‌بندی کار‌ها، آتوریتی بیشتری دارد و تا حدی رییس شما به حساب می‌آید، اسکرام را اشتباه پیاده‌سازی کرده اید. در اسکرام ساختار تیم کاملا فلت است و هیچ‌کدام از نقش‌ها بالاتر از دیگری نیستند.
- اگر در جلسه‌های استندآپ (Daily Scrum) به کسی گزارش می‌دهید، احتمالا اسکرام را اشتباه پیاده‌سازی کرده اید چون جلسه استندآپ، یک mini-plan برای کارهای روز و هماهنگی وابستگی‌های مرتبط به آن‌ها است نه جلسه‌ی گزارش دهی.
- اگر در جلسه Sprint Review مشتریان و ذی‌نفعان حضور ندارند و شما فقط به مدیرتان دمو می‌کنید، اسکرام رو اشتباه پیاده‌سازی کردید چون جلسه‌ی Sprint Review فرصتی برای گرفتن فیدبک مشتری در سریعترین زمان ممکن است.
- اگر یک Backlog تمیز و Groom شده ندارید و در ابتدای اسپرینت برای اولین بار با نیازمندی‌ها روبرو می‌شوید، اسکرام رو اشتباه پیاده‌سازی کرده اید. داشتن یک بک‌لاگ گروم شده جزو پیش‌نیاز‌های اولیه‌ی اسکرام است.

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

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

احتمالا الان با نظر من موافق نیستید اما بیاین یکم واقع بینانه و صادقانه چند مسئله‌ی مهم رو با هم مرور کنیم.

مسئله اول:

اسکرام یک timebox ثابت (معمولا ۲ هفته‌ای یا ۴ هفته ای) به اسم Sprint دارد که (خیلی خوشحال!) فرض می‌کند قبل از شروع هر اسپرینت، کار‌های آن اسپرینت در قالب User Story هایی برنامه‌ریزی (Plan) شده اند و در طول مدت اسپرینت این برنامه‌ریزی به هیچ‌وجه تغییر نمی‌کند.
درسته که از نظر تئوری این موضوع بسیار مطلوب و مورد پسند تیم است و به تیم اجازه‌ی تمرکز کردن بر روی کارها را می‌دهد، اما در واقعیت هیچ‌وقت این اتفاق نمی‌افتد و نباید هم انتظار داشت که بیفتد! همیشه تسک‌های از قبل برنامه‌ریزی نشده (Ad-hoc) و غیرقابل اجتناب وارد تیم می‌شود. سیستم‌ها بطور ناگهانی دچار خطاهایی می‌شوند، باگ‌های Critical بطور ناگهانی سر از سیستم در می‌آورند و مدیران و مالکان کسب و کار، همیشه نیازمندی‌های فورس‌ماژوری را raise می‌کنند که انجام آنها از پایندی به متدولوژی به مراتب با اهمیت‌تر است و البته که منظور از Agility هم توانایی پذیرش به موقع این تغییرات است!

برای غلبه بر این مسئله، معمولا موقع برنامه‌ریزی، روی ۷۰ درصد ظرفیت تیم حساب باز می‌کنیم و ۳۰ درصد ظرفیت افراد رو برای کارهای برنامه‌ریزی نشده و Ad-hoc خالی نگه می‌داریم. بنابراین اگر کار ad-hoc پیش نیاید، عملا ۳۰ درصد ظرفیت تیم در هر Sprint هدر می‌رود و اگر کار Ad-hoc پیش بیاید هم با اینکه قابل انجام است و زحمت و انرژی زیادی از تیم می‌گیرد،‌ اما انجام این کار‌ها استوری پوینت نمیسوزاند و در اندازه گیری سرعت و ظرفیت دلیوری تیم، Velocity و محاسبه‌ی نیروی انسانی مورد نیاز تیم، که هدف اصلی ثابت گرفتن time-box بوده، حساب نمی‌شوند. پس این راه حل با اینکه ظاهرا جواب می‌دهد اما در عمل چیزی از مزخرف بودن اسکرام کم نمی‌کند و البته که این منعطف نبودن نسبت به نیازهای لحظه‌ای در تناقض آشکار با تعریف Agile است.

مسئله دوم:

در اسکرام، فرض ما بر این است که هر User Story باید بتواند طی یک اسپرینت طراحی، پیاده‌سازی، تست و تحویل شود. اگر یک User Story امکان اتمام در یک اسپرینت را نداشته باشد فرض می‌کنیم که در واقع یک Epic است و هنوز کاملا شکسته نشده. اما در واقعیت این موضوع به سایز time-box هم وابسته است. اینکه اسپرینت‌های شما یک هفته ای باشند یا ۱ ماهه، باعث می‌شود یک نیازمندی Story تلقی شود یا Epic! این یعنی در واقعیت همیشه Story هایی داریم که از منظر بیزنسی و محصول، تا جای ممکن شکسته شده اند و اگر آن‌ها را ریزتر کنیم وارد جزییات فنی می‌شویم، با این حال طراحی، توسعه، تست و تحویل آن‌ها بیشتر از یک اسپرینت طول می‌کشد. مطمئنم که همه ما تجربه Done نشدن واقعی Story ها در طول اسپرینت رو داریم. شاید الان به راحتی و خیلی خوشحال اون رو به اسپرینت بعد منتقل می‌کنید اما این خودش در تناقض با اصول اولیه‌ی اسکرام است و Scope اسپرینت را به هم می‌زند.

مسئله سوم:

در روزگاران پیش از Agile از متدولوژی‌های آبشاری (Waterfall) استفاده می‌شد. به این صورت که:

- ابتدا یک جلسه‌ی مصاحبه با مشتری گذاشته می‌شد و نیازمندی‌های دقیق او گرفته می‌شد.
- با تحلیل نیازمندی‌ها سیستم مورد نیاز مهندسی می‌شد.
- واسط کاربری طراحی میشد.
- ساختار داده ای و معماری طراحی میشد.
- سیستم از روی مستندات مهندسی، پیاده‌سازی (کد) میشد.
- سیستم تست میشد.
- سیستم به مشتری تحویل داده میشد
- و مشتری میگفت این چیه دیگه؟! من اینو نخواسته بودم!

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

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

حالا یک سوال:
چقدر برایتان پیش آمده که UI Designer مدت زیادی را صرف طراحی یک UI کند و طرح کامل را به برنامه‌نویس تحویل دهد و برنامه‌نویس به او بگوید: "این بخش اصلا قابل پیاده‌سازی نیست"؟!
این موضوع که شروع یک دلخوری در تیم است، بطور معمول در تیم‌هایی که من دیده ام اتفاق می‌افتد. گاهی واقعا با توجه به ساختار دیتابیس‌ها یا ساختار API ها یا مسائل مربوط به پرفورمنس یا محدودیت در فریم‌ورک‌های استفاده شده، آن طرح قابلیت پیاده‌سازی در آن شرایط را ندارد. نتیجه این‌ می‌شود که دیزاینر یک طرح دیزاین میکند، برنامه‌نویس یک چیز دیگر را کد می‌کند! و این شروع یک سری اتفاقات بد است.
اینجا مقصر کیست؟! برنامه‌نویس یا دیزاینر؟!
هیچ‌کدام. باز هم مقصر فرآیند است. اگر چنین کانفلیکتی در تیم مشاهده کردید، فرآیند شما کاملا Waterfall است و بویی از Agile نبرده است.

حالا بیایم سر اصل مطلب. اسکرام در زمینه همکاری افرادی که کارشون پیش‌نیاز همدیگه است بسیار ناتوانه. در اسکرام فرض می‌شود که یک تیم، شامل همه‌ی تخصص‌های مورد نیازش می‌شود. یعنی اسکرام فرض میکند شما در یک تیم، دیزاینر دارید، تستر دارید، برنامه‌نویس فرانت دارید، برنامه‌نویس بک دارید، نیروی DevOps دارید، دیتاساینتیست دارید و ...
یعنی در تیم هم دیزاینز دارید و هم دولوپر و هم تستر. هر User Story هم که باید تماما در یک اسپرینت انجام شود. نمی‌توان بخشی از آن را در یک Sprint و بقیه را در Sprint دیگر انجام داد. به عبارت دیگر برای یک User Story باید Sub-task های مربوط به دیزاین و دولوپ و تست ساخته شوند و همگی در یک اسپرینت انجام شوند. اما اسپرینت شروع می‌شود و برنامه نویس بیکار و منتظر طراح است. طراحی هم کار سلیقه ای و زمان‌بری است و برنامه‌نویس نمی‌داند چه زمانی طرح به دستش میرسد. پس نصف زمان خود در اسپرینت را از دست داده و وقتی طرح به دستش برسد نمی‌تواند آن را تکمیل کند و باید Story به اسپرینت بعد منتقل شود و اسکوپ آن خراب می‌شود. تستر هم در طول این مدت کلا بیکار است!

لطفا توجه کنید که نگید خوب UI یک اسپرینت جلو‌تر طرح را آماده میکند. چون این یعنی User Story در عمل طی دو اسپرینت Done می‌شود نه یک اسپرینت. حالا یا باید تستر هم یک اسپرینت بعد تست کند که این یعنی هر استوری سه اسپرینت طول میکشد و یا در روزهای آخر همان اسپرینت که این هم یعنی تستر عمده زمان اسپرینت رو بیکار است.
راه حلی که برای این موضوع استفاده می‌شود این است که UI Designer رو از تیم اسکرام خارج می‌کنند (تناقض با self-organizing بودن تیم) و طراحی UI رو جزو فرآیند Backlog Refinement (که قبل تر بهش Grooming
میگفتیم) در نظر میگیرند. یعنی قبل از اینکه یه User Story برای انجام توسط تیم پلن شه، باید طرح UI آن به عنوان پیش‌نیاز آماده‌شده باشه. این یعنی برنامه‌نویس در جلسه‌ی پلنینگ برای اولین بار UI را می‌بیند و مشکلات تازه شروع می‌شوند چون این فرآیند Waterfall است. اینجاست که راه‌حل‌هایی مثل Lean UX و Agile UX مطرح می‌شوند که باز هم با اینکه مشکلات رو کم میکنند اما چیزی از مزخرف بودن خود اسکرام کم نمی‌کنند.
در مورد دیتاساینتیست‌ها و تحلیل‌گر‌های داده هم قضیه همین است. نوع کاری آن‌ها با توسعه محصول متفاوت است و نمی‌توان انتظار تخمین صحیح یا تحویل increment در هر اسپرینت را از آنها داشت. معمولا تیم‌های دیتاساینس خارج از تیم اسکرام و از متدولوژی‌هایی مثل CRISP-DM استفاده می‌کنند که مجددا این موضوع با self-organizing بودن تیم اسکرام در تناقض است.

مسئله چهارم:

برنامه‌نویسی بیش از هرچیزی به تمرکز نیاز دارد. تا به‌حال هیچ برنامه‌ی خوبی در یک محیط شلوغ و پر از interruption نوشته نشده است. اما اسکرام برپایه‌ی تعامل شدید افراد ایجاد شده و آن را مهم‌تر از فرآیند‌ها و ابزار‌ها می‌داند. در صورتی که برنامه‌نویس‌ها تمایل دارند روی کارخود متمرکز باشند و از ابزار‌‌ها و فرآیند‌ها برای پیشبرد کار‌ها استفاده کنند. در اسکرام، زمان زیادی از افراد در جلسات می‌گذرد. جلسات Daily Scrum و Sprint Planning و ‌Sprint Review و Retrospective و گاها Backlog Refinement زمان زیادی از افراد را می‌گیرد. با اینکه اسکرام تاکید دارد که جلسات استنداپ بیشتر از ۱۵ دقیقه نشوند اما همه تجربه کار با افراد حراف در تیم را داریم و می‌دانیم در عمل چه اتفاقاتی می‌افتد و چه بخشی از زمانمان می‌تواند هدر برود. ازین رو جلسات اسکرام برای کسی که کاری برای انجام دادن دارد و می‌خواهد روی کارش تمرکز کند بسیار مزخرف اند.

مسئله پنجم:

مسئله پنجم هیولایی به نام Product Owner است. من سال‌ها در این نقش کار کرده ام و اصلا به آن افتخار نمی‌کنم. در اسکرام فرض بر این است که هر کسی در تیم نقشی را بر عهده دارد و ارزش و جایگاه همه‌ی نقش‌ها یکسان است. اما فقط یک نامگذاری اشتباه، باعث شده که Product Owner ها خود را مالک محصول، مالک تیم و مالک زمین و آسمان بدونن. در تئوری، برای اینکه تیم بتواند روی کارش متمرکز باشد و مدام توسط افراد خارج از تیم Interrupt نشود، از یکی از نقش های برابر تیم (PO) به عنوان نقطه تماس با تیم استفاده می‌شود ولی خیلی مشاهده میشه که در عمل این کار باعث Bottleneck شدن اون شخص و ایزوله شدن تیم و دیده نشدن تلاش اعضای تیم از بیرون میشه و اون شخص چه ضمنی چه بطور صریح از داخل تیم به عنوان رییس تیم پذیرفته میشه. در صورتی که همه‌ی نقش‌ها در تیم جایگاه یکسان دارند. UI Designer مسیول طراحی UI، برنامه‌نویس فرانت مسئول پیاده‌سازی UI و PO مسئول refine کردن بک لاگ است. فقط همین. PO نقطه تماس تیم اسکرام با ذینفعان خارج از تیم و مشتریان است، نیازمندی آن‌ها را جمع آوری کرده و در بک لاگ درج می‌کند. سپس به کمک اعضای دیگر تیم میزان بزرگی نیازمندی ها را در آورده و به Story ها میشکند و بر اساس اولویت های کسب و کار مرتب می‌کند.

در واقع PO مسیول تمیز بودن و مرتب بودن بک لاگ براساس نیازهای کسب و کار و مشتریان است.

اما متاسفانه در عمل بسیار دیده میشه که این افراد به جای تمرکز روی بک لاگ و ارتباط با ذی‌نفعان خارجی، تمرکز خود را روی مدیریت داخلی تیم می‌گذارند که این موضوع چند مشکل به وجود می‌آورد:

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

برای حل این ضعف اسکرام، معمولا یک نقش اضافه به نام Engineering Manager یا Tech Lead یا Team Lead به تیم اضافه می‌کنند تا برنامه‌نویسان بتوانند او را به عنوان رهبر خود بپذیرند. اما از آنجا که اولویت‌ها و بک لاگ همچنان توسط PO مدیریت می‌شود، حضور این نقش مصداق بارز حضور دو آشپز در آشپزخانه است که خروجی آن یا یک محصول شور است یا یک محصول بی نمک. برنامه‌نویسان هم این بار به جای یک نفر باید به دو نفر گزارش پس بدهند و معمولا این موضوع بسیار براشون آزاردهنده می‌شود. البته راه حل های دیگری نیز مانند خارج کردن PO از تیم development و استفاده از Product Manager به جای آن و قرار گرفتن Tech Lead بین این دو هم مطرح شده و من هم خیلی تجربه این کار رو در تیم‌های مختلف کوچک و بزرگ مثل دیجی‌کالا، اسنپ، بامیلو، اسنپ‌فود، اینپین و ... دارم اما حتی اگر این راه حل ها مشکلات رو حل کنه باز هم اسکرام نیست و تغییر کرده. پس چیزی از مزخرف بودن اسکرام کم نمی‌شود.

مسئله ششم:

ترکیب دو فرهنگ Agile و DevOps یکی از قشنگ‌ترین و مفیدترین کارهایی است که در حوزه‌ی توسعه و استقرار نرم‌افزار‌ها استفاده می‌شود. در این راستا پیاده‌سازی Continuous Deployment نقش کلیدی دارد. به این صورت که هر نیازمندی در یک پایپلاین منظم به ترتیب: گروم می‌شود -> پلن می‌شود -> طراحی می‌شود -> پیاده‌سازی می‌شود -> (به صورت خودکار) تست می‌شود -> (به صورت خودکار) دیپلوی می‌شود -> مانیتور می‌شود.
یعنی هر User Story به محض تکمیل روی یک برنچ جدید تست می‌شود و همزمان با مرج شدن با برنچ اصلی، به صورت خودکار دیپلوی می‌شود.

این سطح از اتومایسون و پیوستگی در اسکرام امکان‌پذیر نیست. زیرا در اسکرام همه‌ی User Story ها در انتهای اسپرینت جمع‌آوری، ریلیز و Done می‌شوند.

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

و اما راه حل چیست؟!

متدولوژی‌‌های دیگر مثل Kanban و XP و TDD و ... محبوبیت کمتری نسبت به اسکرام دارند. همینطور هر کدام از آن‌ها نیز معایبی را دارند و البته مناسب انوع مختلف پروژه‌ها و تیم‌ها اند. با این حال من شخصا استفاده از Kanban به ویژه وقتی از بعضی مفاهیم خوب اسکرام در آن استفاده می‌شود (Kanplan یا Scrumban) را ترجیح می‌دهم. زیرا:

- نقش‌های اضافی مثل Product Owner و Scrum Master در آن وجود ندارد و برابری نقش‌ها در آن بیشتر به چشم میخورد. پس استرس افراد کمتر و خلاقیتشون بیشتر است.
- برخلاف اسکرام که نیاز به آموزش و همینطور یک مربی تمام‌وقت (Scrum Master) در کنار تیم دارد، مفاهیم Kanban بسیار ساده است بطوری که ابتدا در بغالی‌ها استفاده می‌شده بعد وارد صنعت نرم‌افزار شده.
- جلسه‌ها و تشریفات اضافی و وقت‌گیر در آن وجود ندارد. اما انقدر انعطاف دارد که بتوان از جلسات daily و On-Demand Planning و short Kaizen event در صورت نیاز استفاده کرد.
- یک time-box ثابت و محدود وجود ندارد و کارها در یک pipeline انجام می‌شوند. کارهای UI می‌توانند به راحتی قبل از توسعه و کارهای تست بعد از توسعه انجام شوند.
- کارهای مربوط به دیتا و زیرساخت و ... به راحتی در یک بورد با بقیه کارها مدیریت می‌شوند و هر کدام ددلاین‌های متفاوت دارند و حتی می‌توانند Estimate نشده باشند.
- اولویت‌های بک لاگ در هر لحظه قابل تغییر اند و این انعطاف باعث Agility بیشتر می‌شود.
- دیگر نگران بزرگ بودن استوری‌ها و نرسیدنشان به انتهای اسپرینت و انتقال به اسپرینت بعد نیستیم.
- کار‌های فورس و ad-hoc بدون هدر رفت بخشی از زمان تیم، به راحتی به لیست کار‌ها اضافه میشوند و به عنوان کار انجام شده تلقی می‌شوند.
- تسک‌ها به صورت مداوم تحویل می‌شوند و برخلاف اسکرام می‌توان از مفاهیمی مثل Continuous Deployment استفاده کرد.
- باتل‌نک‌های تیم به وضوح با یک نگاه به بورد برای همه‌‌ی افراد واضح است و نیازی به جلسات retro نیست.