When building a software product from scratch, there is a lot of work to be done. Development teams start working in many different functional areas to flesh out the product. The most important thing to remember is that the value of this work is only realized when it reaches a customer and is providing value.
Kanban teaches us to do one thing at a time and limit the work in progress. The team focuses on the smallest set of tasks they can work on at once. The process visualizes and highlights what is needed to take the tasks through to completion. The key part of this practice is defining completion. Software development teams will often define done as functionally implemented and checked in to a software repository. When this final step does not involve the customer, the developed features may sit without providing immediate value.
Implemented features sitting in a software repository but not yet deployed to a customer can be thought of as inventory. Inventory sitting in a warehouse gets stale and does not provide value. In the context of physical goods, inventory provides the value of being available to the customer immediately and providing a buffer between manufacturing and delivery. In the context of software, there is no value in feature inventory that is not deployed to a customer.
The final step in the Kanban process therefore should focus on delivery to the customer. In practice, sophisticated software teams will setup continuous delivery pipelines that automate build and deployment of developed features. These teams have Kanban boards that are broken into columns such as “Ready for Dev”, “In Dev”, “In QA”, “In Code Review”, “Deployed”. In the final step, deployment may end in a test environment such as QA, UAT, or Staging. Deploying from those environments to production will then be a single-click step awaiting sign off from Product and/or QA.
By crafting processes to focus on the actual value delivered from software development, we end up delivering more value to the customer with less effort. In turn we get earlier feedback from the customer as to whether the features we build help them solve their problem more effectively. This feedback will reduce another form of waste which is building features that customers do not need.
