training you have been promised, and “it’s coming.”
On the other hand, if you can barely get the product integrated for a few days every train, you have a high cost of integration. Moving to continuous integration inside trains is going to kill you. I have an even better plan. Move to continuous flow. This is the “just do it” philosophy.
Move to Kanban and Forget About Iterations
Some of you are thinking, “Ok, Johanna has lost it now. Staged integration was difficult, and release trains were difficult to integrate? Why move to kanban?” Because at some point, you will want to release the product. You do not want to wait for a quarter to end. If you start with continuous flow, and make your stories smaller, and each of your feature teams has to integrate as the feature team completes a feature, every single time they complete a feature, you will discover quickly what is going on.
If you visualize the entire technical program, and integrate every single sliver of a feature, you will be able to see the impediments and move to continuous integration more easily than if you struggle with more staged integration and more steps.
With iterations, you were like my college project, where you waited too long to integrate. You have too much work in progress across the entire program, and the costs of integration are killing your progress. Moving to kanban, continuous flow, will allow you integrate little bits (assuming your stories are small), and allow everyone to integrate a little bit at a time every day.
Grab a very large wall. You will need a large wall to visualize all the work in progress. Don’t bother with limits yet. First, visualize all the work in progress from every single team. Yes, for those of you with 47 teams, this is a huge pain in the tush. Well, if you don’t have continuous integration, that’s an even bigger pain in the tush, so get going with the stickies or the cards. Try a board that looks something like this:
This kanban board has the backlog in the ready column, the development and the development-done columns before the system test on the local branch column. Then you can see the Waiting for Integration column. There’s a lot there. Finally, there’s the Done column.
When the teams realize how many local branches they are using, and how many features are waiting to be integrated, they might not even need the cumulative flow diagrams. But, I bet seeing the task boards even out and the cumulative flow look better will help them realize their hard work will pay off is worth it.
Use cumulative flow diagrams, make sure your feature teams are cross-functional, and I would ask each team to make sure they move a story across the board at least once every three days. Why three days? Because it’s less than once a week. I prefer once a day, and I realize that not every team can develop stories or slivers of features that small right away. But almost every team can learn to produce some sliver of a feature that they can deliver and show someone in about three days. If it takes a team about three days to deliver, they have the other two days to integrate and make sure nothing is broken. Now, in a week, they have delivered something of value, integrated it, and they can demo it. Ah, what a feeling. They have experienced what continuous integration is for themselves.
Multiply that by each and every team,