Work Sequencing using multiple Kanban Systems
Two product teams are using Kanban to manage their flow. Each team makes frequent deployments. The teams are settled and have invested a lot of time and effort into test and deployment automation. All of their environments are just where they need them to be – a true reflection of live. Cycle time has stabilised around 3-5 days so each team is highly predictable. Company growth is on-plan with the customer base doubling in the past quarter alone. With a very healthy product roadmap for both products the future is looking really exciting.
Analytics show a large proportion of customers are registered for both products. Ding! Someone in the business has an idea “We need a single view of the customer”. The Architects evaluate, select, and look at CRM systems and how they fit into the overall technical landscape. As this is a new technology in the company there’s going to be a steep learning curve for the org. The decision is taken to outsource the ‘heavy lifting’ part of bringing in the CRM system. Following a thorough and robust selection process XYZ Corp is selected to install, configure, and support the core CRM server and platform.
XYZ Corp are experts in the CRM field, unfortunately they work to a Waterfall delivery process. This means delivery times are in the order of 6-12 months. The Architects visit each of the Product teams and stick a card in each product backlog. On the card is written ‘Implement CRM’. The card then has a bright magenta post-it note stuck to it to signify it is blocked. On the blocker is written the ETA for when the CRM platform is expected to be ready for the teams to plug into it.
Fourteen months go by. XYZ Corp have delivered late but at least it’s working. In the meantime the Product teams had each delivered an enormous amount of new features further growing revenue and customer base.
The Architects are now happy the Architectural runway has been extended so go to each product board and remove the blocker from the ‘Implement CRM’ card. The product owners for each board prioritised the whole backlog as normal. Eventually, the CRM card is picked up. The BA realises this is actually an Epic rather than a story so explodes the Epic into several stories and places them in the backlog. Training is given to the delivery team on how to consume the CRM API’s. The team pull in the cards to work on them but only when they have capacity to do so. Meanwhile, the architects update their board to say what’s in progress by which team. As the Epic is completed for each team the architects move their ‘Single View of the Customer’ card (on their board) to the done column.
