Good software is never complete

We often think in terms of projects to deliver software solutions with a defined scope and deadline. But this often leads to the same software reaching maturity early and in the long term shortens the life span of the software. If software has been architected well, is in a modern language / platform with good developers freely available, has very little technical debt, and is well understood by business users and developers then it likely that some improvements can be made to bring more value to the business than the incremental cost of the development.

Instead of handing the software to support, mothballing the source code, and waiting for the business to raise a request for a change we should be more proactive. Meet regularly with the business owners of the software, check that it’s still being used in the way it was originally intended. If any parts have fallen into disuse find out why – too complicated, business needs changed, found a bug but didn’t report it, adopted offline workarounds. Discuss ways of addressing these issues effectively. Understand how the business is changing and what impact this will have on the software

This is a similar issue to the product vs project centric nature of agile vs waterfall. Traditional software development has been dominated by a tendency to treat a problem as a project – plan the approach, budget it, resource it, execute it, then stop. However, the solution to one problem often reveals a different business problem to solve.

The project centric approach also drives us towards separating PMO and Support functions with often a very abrupt handover, and ultimately a painful transition for both customers and IT staff. Support's remit is to keep the software running, but customers see problems with it and want enhancements. Eventually the frustration builds up enough to kick off another project to cover the gaps between what the product delivers and the current business needs. By the time the project is developed, delivered, and handed off to support there are new gaps, and the cycle continues.

Agile practices like Scrum and XP are as approriate to a support mode of operation as they are to a project, and can be used in a continuum to remove the transition step. Of course in 'support' mode, the number of resources can be reduced, and sprint lengths could be increased (if there is less need to be as 'agile'), but there should continue to be a product owner with responsibility for the managing the ROI on any investment and for maintaining a backlog of proposed changes. At the beginning of each budgeting cycle the product owner can apply and justify the money allocated to their Product for the next budget period - if this is a large amount with significant change the next period will feel like an agile project - if it is a small amount with minimal change it wil lfeel more like support.