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