Looking through The DevOps Handbook audio-book materials .pdf, I found this useful figure of a kanban board for DevOps.
I like how it depicts dev and ops tasks in separate columns and shows User Acceptance Test (UAT) to follow after both dev and ops work is completed.
Lead Time (LT) can be calculated by capturing the time it takes for an item to reach Delivered from the time it was added to the “Ready” column.
Process Time (PT) would be defined as the time from Investigate to Delivered.
I do not like the “Done” columns under Dev and Ops. the work should not be considered “done” until the change has been deployed to production. For this reason, I find those columns confusing from a terminology perspective. There goes Mike nit-picking again. However, since not having them would potentially force the items to go to UAT prematurely, I would prefer to relabel the columns “Ready” or “Completed” instead of “Done.”
You also want to manage work in progress (WIP) by identifying an upper limit of work items allowed in each column of the kanban. The DevOps Handbook states insightfully, “Limiting WIP also makes it easier to see problems that prevent the completion of work.”
The book provides an example where limiting the WIP causes resources to not have work to do because of an upstream bottleneck. It may be tempting to add more items to the queue rather than identify the problem causing the upstream delay. I love this example, but the presupposition here is that the overall team is healthy and inquiries into and offers of help for the upstream challenge are well received. This assumes a productive partnership is in place. For engineers working in large silos, the reality here is obvious.
Who is in charge of ensuring overall team cohesion? Is there, or should there be, a Release Train Engineer (RTE) equivalent for DevOps work groups? Are there benefits to DevOps team members belonging to the same organizational hierarchy? I believe these questions support my belief that DevOps is more appropriately implemented as small work groups who ‘do’ devops together rather than attempting to overlay a devops methodology on top of existing organizational structures. That is not to say other implementations cannot be successful – they are simply short of the ideal.
My 2 cents.
If you have comments or feedback on this entry, please consider leaving a comment. I would appreciate any feedback or questions.