"And there is no reason you can’t simply forgo sprints entirely...and still check in, see how things are going, pivot, evaluate new information." Because 'chec

"And there is no reason you can’t simply forgo sprints entirely...and still check in, see how things are going, pivot, evaluate new information." Because 'checking in' on something doesn't create incentive to completion, or actual material outcomes. You can have 'the software developers doing stuff and meeting objectives on their terms' - or have deadline driven wherein business/software objectives are set and people move towards them. The problem with the objection to 'deadlines' is the fact that inherently software is not created for it's own aesthetic sake, or for it's cleanliness, or architectural integrity, or some arbitrary measure of quality. 'Time' is the key ingredient often missing from the architectural/development equation, because 'time is money' both in cost, and opportunity cost. 'Time' (which implies cost, ROI etc.) will likely be driven as a business impetus and has to be put into the equation in very serious terms. Many devs might complain about 'technical debt' or 'messy software' or 'some things that don't work' - but in reality, those situations may actually represent optimal business scenarios. It may not make sense at all to make certain systems perfect, or at least, in the short run or on first iteration. In other terms, the 'QoS' expected is I think always way higher on the dev side than real business terms may mandate. What devs view as 'a mess' may be a perfectly good condition. 'Building the wrong thing' is the #1 reason that companies fail, not 'technical debt'. If customer outcomes are generally good, revenues are increasing, then technical debt is normal, and it's a function of pragmatism at that point more than anything. Taking too long to build something, or taking a long time to build something that is 'the wrong thing', is almost guaranteed death. Finally ... I think milestones with deadlines are important also for the psychological and organizational factors. In NATO, for examples, all 'orders formats' are the same. Any NATO General, from Polish to American, gives a set of orders that are crudely similar to those given by section commanders to their privates. That's to enable operational efficiency. The 'most important' part of the orders are the mission objective with a timing. Literally it has to be said twice. I'm not kidding - while giving orders, the mission statement is verbally repeated. Always. This is because in the fog of war 'everything goes wrong', nothing goes according to plan, things break, people die, obstacles abound, opportunities arise (just like at a startup) - but if everyone involved knows what they need to do, then they can adapt and make it happen by hook or by crook. So 'the gap at grid reference 0000 1111 needs to be bridged by 0600h tomorrow so 6th calvary can cross with heavy tanks' is a mission. Everything else about the plan is secondary, everything could go wrong, but when individual sappers/soldiers, NCO's, junior officers all have that 'this spot has to be gapped by 0600 for heavy vehicles' ... then they can rally around it whatever happens. Obviously there are tradeoffs and obviously devs have to participate in the establishment of their own deadlines and objectives ... but in my view it has to be done, and it's healthy to break it down.