Scaling Agile: Transitioning to Kanban

 

Large-scale agile projects include multiple feature teams working in rhythm over short iterations or time-boxes one after the other.  That happens when features for the first release are coded, integrated and tested in time-boxes.  When the first release or a subsequent release goes to production, we see an emerging need for forming one or two teams to work on daily iterations unlike 2 or 3-week iterations of feature teams.  This is because of the need to provide timely support and daily fixes to product owners and end-users.  Here, the transition from iteration-based or Sprint-based development into Kanban becomes essential.  Obviously, those one or two teams that support end-users cannot afford to make their stakeholders wait for 2 or 3 weeks for defect fixes and patches. They need to be even more agile, and they need to respond daily by fixing critical issues and responding to end-users.  Potentially, they must be able to understand and implement Kanban.

 

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?
 

Related Posts:

1. Scaling Agile: What Do Architects Deliver?
2. Scaling Agile: Architecting Your Agile Team
3. Scaling Agile: Feeding Your Feature Teams
4. Software Architecture and Design in Agile World
5. Scaling Agile: Emerging Architecture and Technical Debt
6. Scaling Agile: The Value of Independent Testing
7. Scaling Agile: Hardening Sprint and the Problem of Procrastination
8. Scaling Agile: Succeeding in Release Management
9. Scaling Agile: Disastrous Software Factories