Agile Is Dead, Long Live Continuous Delivery
I like how he tries to supplant agile with something that doesn&#x27;t even attempt to solve the same problems that agile (like waterfall before it) attempts to solve.<p>Both agile and waterfall methods attempt to give you a pattern by which you can predict when software will be delivered. That&#x27;s the main business value. The suits don&#x27;t care how the devs operate, provided they can get things on time.<p>Waterfall tried to do this by trying to understand the problem as fully as possible, to liken it as much to previously solved problems, and to involve gurus to say &quot;that kind of problem will take X amount of time to resolve&quot;, and thereby create milestones and delivery dates.<p>Agile instead said &quot;look, we don&#x27;t know enough at the start of a project to do that. Let&#x27;s instead keep track of everything we want to do. Let&#x27;s try and estimate each set of tasks (stories), individually. And then let&#x27;s rank them in priority. We can measure how good our estimates are, we can modify them, we can generate more data and determine what we&#x27;ll have at a milestone, and then can either push back the due date, or at least recognize that we won&#x27;t be able to ship the entire feature set at that time.<p>Continuous delivery can be done with either one of those (it almost never is in waterfall, but it -could- be). But by itself it offers a business nothing for planning purposes. All it does is allow an immediacy, a &quot;as soon as it&#x27;s done it&#x27;s out in front of the users&quot;. This may or may not be a good thing to the business, but it doesn&#x27;t solve the basic issue that business people want to know when they can expect a given set of features to be live.