Transitioning to Kanban comes with two key aspects. The first one is about learning and implementing Kanban and the second one is about aligning the engineering processes such as configuration management, build and release management, tools etc.
When you and your team are transitioning to Kanban, you need to do a good mix of unlearning and learning. This is because, when you do Kanban, you are not going to do Sprint Planning or Story Point Estimation. You are not going to do daily stand-ups with the anticipation of delivering something at the end of the Sprint. You are going to learn about visual boards or more specifically Kanban boards. You are going to experience how team members ‘pull’ work items. You are going to learn the concept of ‘Work in Progress’ and WIP Limit. And of course, when you work with virtual teams, you will need tools that support distributed Kanban teams and offer electronic visual displays.
Coming to the second aspect on engineering processes, the first step is to think through configuration management. How are you going to establish configuration management across multiple feature teams that synchronously work on 2 or 3-week iterations and Kanban based production support teams? An obvious solution is to have 2 branches – one for ongoing development and the other for production support activities. How frequently are you going to merge? And what is going to be the efforts involved in merging them together? Next, how are you going to perform independent validation or testing in the new model? What are going to be the revised overheads or estimates? Finally, how will this new model impact your build and release management process?
Are you looking at all these aspects while transitioning to Kanban? Are there any other key factors or issues?