The third principle of the Agile Manifesto tells us to deliver working software frequently. This step is an essential factor in satisfying the customer. While we want to avoid the “are we there yet?” approach to delivering a solution, incremental is valuable. When we take this principle to heart, we provide confidence in our progress, along with opportunities for feedback. Therefore, we need to look at this closer for small and large applications.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Deliver Working Software Frequently
These four words are sometimes easier said than done. The implementation phase is dynamic by definition. We should be steadily making changes as we march towards completion. The idea of frequent milestones of working software may seem antithetical to this process. Likewise, regular deployments can be time-consuming. That adds time to our schedule. However, we can plan for this and find ways to make this a worthwhile investment.
Checkpoints and Testing
When we look only at the cost of deployment, we miss the point. This principle tackles the problem of communicating with the customer and building their confidence in our solution. It also forces us to test integrations and processes that can be costly to fix at the end of the implementation period.
It is well-documented that bugs cost more the later they are found. When we include deployments early and often, we are building in some testing and sanity checks. This deliverable can highlight flaws and bugs that otherwise would be far more expensive to address. We can even respond to customer requests that might be too costly to handle late in implementation. There are architecture assumptions that may need to be altered based on the end-user experience. Early deliverables can bring those to the surface when a change is cheap and easy.
The Elusive User Experience
UX is a hot topic in software. Correspondingly, some people are very good at crafting a sublime user experience. On the other hand, customers can be picky or finicky. Thus, the best validation of our UX is the stamp of the customer. The only way to test this out “in the wild” is to provide deliverables the users can work with. Clicking around and “imagining” how it will work is not the same as concrete functionality. When we deliver working software frequently, we provide the customer with a practical example to review. The feedback we get from this is a valuable input for a product that will satisfy those same customers.
