The article <a href="https://itnext.io/agile-projects-have-become-waterfall-projects-with-sprints-536141801856" source="ITNext" author="Ben Hosking">Agile Projects Have Become Waterfall Projects With Sprints</a> argues that a lot of projects using agile aren't agile at all, but are <iq>more like waterfall projects with upfront requirements, fixed deadlines, sprints and 2 weekly demos.</iq> Overall, I understand where the author is coming from, but I found the tone pretty overwhelmingly negative. I can only imagine what the author has seen to have put them in such a dark place. 😐 I thought that this was an interesting comment in the article: <bq>You cannot create fixed deadlines unless you know all the requirements and guarantee no requirements are changed.</bq> However, you <i>can</i> create fixed deadlines (the world kind of expects them sometimes, e.g. when you're preparing for a conference that happens <i>on a specific day</i>), but then you have to be willing to adjust on <i>what</i> will be delivered on that day. Agile started out in a world where a <i>partial</i> product could be delivered and <i>still have value</i>. That is not the case with all projects. Thus, the designations <abbr>MVP</abbr> (Minimum Viable Product) and <abbr>MMP</abbr> (Minimum Marketable Product). Even agile projects have to be honest about what the minimum time frame is for an MVP, though. Where some projects have an advantage is that they can iterate in smaller increments <i>after that</i>, but also can deliver useful, though <i>nonviable</i> pieces as artifacts of iterations. There are some projects where it's more difficult to carve out such deliverables. Although there is always work that has been planned and successfully accomplished and documented, it's sometimes hard to measure or see progress until a larger amount of work has been done. I suppose that's the art of planning and measuring. Here, it's also useful for technical team members or more technically oriented teams to learn how to consider administrative, planning, design, and documentation work as just as useful as producing technical artifacts (be they physical or virtual). A waterfall process doesn't help figure out what to do when the delivery cannot be completed on time. It (generally) has no plan for what to drop if you can't deliver on time. Also, it doesn't really have any ideas for what to do when new things "crop up". An agile process is supposed to help you triangulate toward a version of the product that can actually be delivered by the target date---or help you better (and sooner) predict whether it's even possible to deliver anything useful by that date. I think you have to be honest about which projects really can be run in an agile way---but then also make sure that they take advantage of agility to be bolder than they have been. Release early, release often, think about what your MVP is, all of those things are good to take from the agile process. As far as the "ceremony" of the process goes: I have always found value in the review and retros.