Potentially deployable in Kanban

A Kanban system is well suited for ways of working based on continuous flow, where the start/stops are reduced and work items flow through the system in a continuous fashion. Continuous Delivery (CD) is a set of capabilities that enable us to get changes of all kind — features, configuration changes, bug fixes — into production safely, quickly and sustainably [1]. Continuous flow doesn’t necessarily translate into Continuos Delivery (CD). For instance, one can have a system where work-items flow in a continuos fashion, but releases to production are done at a regular cadences (fortnightly as an example), releasing multiple work-items in one bigger batch. To achieve CD, where each completed item gets deployed to production as soon as it was completed it requires some more thought. I’m often asked how to we model in Kanban and CD the activities that are not executed necessarily at individual work-item levels, yet are required to perform before a release? Examples of such activities could include non-functional testing (like performance testing, penetration testing) or accessibility testing. A typical Kanban system would model the work in workflow phases, such as and . Then, work items such as User Stories are moved individually and through the board. The rules are usually simple — can not happen before , conversely should not happen before . Analysis, Development, Component Testing System Testing sequentially Component Testing Development System Testing Component Testing In a CD model, each developed work-item can produce a software. As it gets promoted through the system, this potentially deployable software artifact is tested with the aim to increase the confidence level on its quality. If it meets all the quality criteria, then it can be deployed to production. potentially deployable At one point in the workflow a potentially deployable software is created. The coloured circles indicate test activities aimed to increase confidence levels on quality. In the above simple Kanban system I’m showing that as soon as ‘ we have a software artifact that is potentially deployable. The work-item has morphed from requirement to software. This is true for each and every work-item — they can produce a (different) deployable software. Development is done’ From the multitude of potentially deployable versions, some meet the quality criteria and can be deployed to production. As the work-item goes through the workflow, it is quite common to release a version of the software, the potentially deployable software, to various test team members (functional, non-functional, accessibility) who will perform test activities in parallel. These parallel activities are not easy to visualize in Kanban given its inherent sequential nature. Furthermore, the problem can be compounded by the fact that non-functional testing could take longer than functional testing, especially if specialized, non-dedicated teams (such as security, or performance test teams) are used. Activities can happen in parallel, sometimes performed by different team member or different teams What should happen at the Kanban level — should the item progress in the workflow even though some testing hasn’t been completed? Use of tags for parallel activities that are not explicitly modelled One solution is to capture these parallel activities in one workflow column, set a definition of done for it so that items can not progress further until all the activities are complete. Visually the work items can be tagged, giving one tag for each type of activity. As soon as an activity has been completed, a tag is attached to the work-item. When all the tags are present, the work item can progress further in the workflow. When all the tags are present, the item can progress through the next step in the workflow Another solution would be to clone the work-items for the parallel activities, as described in the sketches below. Use a queue to split the work-item into multiple child items, which are then taken through their own mini parallel workflow Once all the split items are completed, the parent work-item continues the main workflow Other solutions could aim to eliminate the parallel activities. For instance, could developers embed performance testing as part of their ‘Development’ phase? Or, could the team defer some testing post deployment? For instance, in big enterprises User Acceptance Testing (UAT) is still a major test phase, run quite often in parallel with other test activities. Could this be executed post deployment by restricting the access to the newly deployed version to a limited number of users? Lastly, maybe there are even more advanced solutions, such as modelling the work as a network of activities, similar to telecommunication networks. Work-items are broken down into small packets, intelligently routed by ‘routers’ to nodes of the network, which represent a work-station capable of performing a type of work. Is this Kanban? Probably not, but could offer a solution to the problem. A different type of workflow, more akin to networking [1] Accelerate: The Science of Lean Software and Devops: Building and Scaling High Performing Technology Organizations, and (27 Apr 2018) Nicole Forsgren Phd Jez Humble