Agile teams often start delivery with a short Discovery phase where they research the main user needs for a service, explore the approach and team needed for delivering the service and generally get a sense of what success might look like and whether it’s worth building the service at all.
Discovery teams know that their work may lead to the project progressing no further. Indeed, it’s a big win for the organisation if the project can be stopped during or after Discovery as it saves them the significant actual and opportunity costs of developing and operating a service that won’t achieve acceptable outcomes or will be too expensive or risky to deliver and evolve.
In non-agile teams, lots of thinking happens before delivery. There’s an assumption that once delivery starts it’ll continue through to the end — you’ve already thought your way to project success after all.
In either world, projects can have momentum of their own. This can come from senior stakeholders, the team and even customers unwilling to see that their original ideas are untenable. In some organisations it can also be really time-consuming and difficult to get a project started — and once started, sponsors are unwilling to stop given all their efforts in getting the thing started in the first place. Of course, this is a sunk cost.
With agile projects shipping to users incrementally you at least have some visibility of delivery progress and if you are regularly shipping you can see whether your outcomes are being met. This isn’t the case with big-bang, all-or-nothing releases where you won’t know until much later. The option to stop is valuable in its own right.
That you may be stopping more projects earlier, and that stopping them is success not a failure, are significant changes in thinking for organisations moving to agile. But organisations that can make these changes in thinking will as a result have fewer services in their portfolio and will be able to invest more in developing services that achieve their outcomes.