Continuous Integration not Continuous Isolation
I firmly believe the power of Continuous Delivery (CD). I have experienced the value of it, and I had also seen significant issues when it was missing. With the right implementation, CD tackles the last mile issues and keeps the cost of maintenance low. CD requires an initial investment, which gets paid off during the lifetime of the software.
When I first heard about CD what caught my attention was the idea — making every commit deployable. Fundamental to CD is the obsession to provide value to the customers. Every business exists to serve their customers, and if that is the case, CD should be a natural choice.
Continuous Integration, not Continuous Isolation
Having the right Continuous Integration setup is mandatory for any team to start with their CD journey. Continuous Integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day. If the team is not doing such frequent integration, it is called CI Theatre, not CI.
Using Jenkins or CircleCI or any such tools does not mean the team is practicing Continuous Integration. It is Continuous Isolation and not Continuous Integration when the team works in silos either in their local branches or remote branches.
Small Batches
Paul Hammant has written — A ‘Small Stories’ case study — about how they achieved an average of 1.25 days for “deployable” stories back in the early 2000s. They planned stories in such a way that the stories would get completed in half a day to one day. The Testers, Business Analysts, and Designers would work together to provide input at the right time.
The team achieved such a high speed because the entire team was working together than in isolation. Working closely helped the team to plan in short chunks and provided clarity to move forward than getting stuck every once in a while. This article has more details about the implementation of the same.
Shorter Cycle Time
What else is the key for such short cycle time? Is it the team size or is it the art of slicing? According to Joshua Kerievsky, it is tackling the handoffs among the team matters more than the actual number of people.
I have seen teams where the teams are waiting for APIs even when the team size is as small as 4–6. Waiting is such as deadly waste and the team while “waiting” moves to another task keeping both of them in progress state.
The solution to such situations is having teams with generalists or small, focused groups based on the tasks than on technology or stack. While the former, having generalists in the team, might be difficult to implement because of the learning curve, the latter is possible. As Joshua writes:
You don’t need to get it perfect from the start. Your initial team may need to grow as you discover slow handoffs and eliminate them by inviting the people who were part of the handoff to become a part- or full-time member of your team.
Try Pairing or Mob Programming; this improves the focus and understanding among the team significantly. The idea is to provide anything that helps the team to focus and deliver than getting interrupted or stuck often.
Incremental Design
Another critical aspect of the small batches is practicing emergent design, i.e., design in a continuous, incremental manner. The same can be applied to the product design too, by approaching the product design in an iterative and incremental way.
For the product to emerge, it is essential to focus on what matters the most — focus on the rocks than on pebbles or sand.
