There is a popular notion in agile that incremental delivery of Features allows the project to stop at any time and deliver value to those paying for the work. This is another concept of agile, in the absence of a domain and context, is pretty much meaningless in terms of actionable decision making.
We need to know ahead of time what collection of features produce what business value to the customer. Arbitrarly stopping the project may be too soon or too late. If too soon, we'll leave the current features orphaned. They won't have what is needed to provide value to the customer.
Stopping to late leaves the delivered features with partially completed work that either pollutes the functionality or prevents complete use of that functionality.
What we need is a PLAN. A business capability deployment plan like the one below for a health insurance provider network system. This system integrates legacy systems with a new Insurance ERP system.
Project Maturity Flow is the Incremental Delivery of Business Capabilities on the Planned Need Date.
Partial completion may provide value to the customer. Or it may not, depending on what is provided. The pilot with demo grade data conversion doesn't do the providers much good as it's not real data and it's not real enrollment. Getting the shared group matrix up and running can test the integration across the provider network. The real value starts when real data is in the Data Mart and accessible by the new ERP system.
So Once Again
When we hear the platitudes of deliver early deliver often or incremental delivery can be stopped at any time and value delivered to the customer please ask for a picture like this and have that person point to where and what on the picture can be stopped at what time.
Building this picture is part of Project Governance. Part of the business management planning process of how and when to spend the customers money in an agile emerging domain where requirements certainly do change. But it's not about coding and the needs of the coders. It's about business management and managing in the presence of MicroEconomics of Software Development. This project governance paradigm should be in place for any non-trivial effort.
And the Final Notion
Of course to do this successfully we need estimates of everything in order to assure the business plan is going to be met with some degree of confidence. Time to reach a useful capability, cost to reach that capability, risks in reaching that capability as planned, resource demands, and a myriad of other random variables. With this information and a statistical model (Monte Carlo, COD, Method of Moments, Design Structure Matrix, Probabilistic Value Stream Map), we can make decsisions about the business choices.
Without these processes, any non-trivial project is just coding until time and money runs out.
