Creating elegant solutions to complex challenges is something Mobomo teams are well known for among our customers and partners. Several years ago, one of our teams was challenged with a novel situation in which our customer required two separate companies to develop alongside each other using the same codebase. Each company was to work independently on different features, but the application had to include changes from both teams on a regular basis. Each team was already developing using the Agile Scrum methodology. So, what could we do?
Two Teams, One Codebase
We knew we could not follow a normal Sprint schedule where both teams committed to the same codebase throughout the Sprint. Doing so would likely destabilize the code and developers from both teams would constantly be introducing conflicts and surprising each other with code changes. Since both companies were in competition, but also collaboration, we also had to manage blame, so that one team was responsible for their own code changes without blaming code changes from the other team. Both teams were motivated to keep the application running as smoothly as possible for our common customer, and for the users we support. In order to allow each team to work independently, foster a single clean and robust codebase, minimize conflicts, and keep each team responsible for its own changes, as the team’s Lead Developer, I devised a new Sprint methodology: Zipper Sprints. With Zipper Sprints, each team (Team A and Team B) has its own 2-week Sprint Cycle. Team A’s Sprint starts halfway through Team B’s Sprint, and vice versa. In this way, each team has one week to work on features in complete isolation, and a second week to incorporate changes from the other team and stabilize the code for release. Releases happen weekly but alternate between teams. So, one team releases one week, and the other team releases the following week. This provides a clean hand-off. This process allows for independent work as well as for coordination, clean and robust code, minimal conflicts, and clear responsibility. The graphic below illustrates how Zipper Sprints work for each individual team:
Breaking Down the Zipper Sprint Process
To understand how Zipper Sprints work for a single team, we should consider a single team’s viewpoint. Team A’s Sprint begins just after they have delivered code from the previous Sprint. All the code changes for the previous week (half of the 2-week cycle) have been made by Team A, so all of the code is familiar. Team A then works on tasks for the next 2-week Sprint. Ideally, the bulk of the work for the 2-week Sprint should be completed during the first week of the Sprint. This allows the second week for integration and testing of changes from Team B’s overlapping Sprint. At the end of the first week of development for Team A, Team B is finishing their own 2-week Sprint (having just integrated the changes from Team A’s delivery), and Team B delivers the code to the customer. Team A, in the middle of its two-week Sprint, then pulls Team B’s code changes from the customer’s Git repository and resolves any conflicts in the code. For the next week, Team A can work on integration and testing. While testing their own code changes, Team A is also testing how that code integrates with changes made by Team B. It is possible that Team B’s changes cause problems with the 1-week-old code changes already made by Team A, and this week of testing and integration should provide time to help find and fix these problems. At the end of the second week, code is finalized and pushed to the customer’s Git repository for one week of customer testing while simultaneously allowing Team B to pull the changes into their own Sprint.
To understand how Zipper Sprints work for a customer, we can consider the customer’s viewpoint. The customer provides tasks to both teams. Each week, one of the teams delivers code changes with their tasks that they have completed. Their code changes build on the work delivered by the other team from the previous week. The customer has one week to test this code, since another code release will come in the following week. The customer should find that the code is well tested and integrated. If bugs are found during testing, an attempt is made to determine if those bugs were also in the previous release (from the other team). If the bugs are new, they are assigned to the team that just delivered the code, since it is that team’s responsibility to deliver a clean release (without introducing new bugs). If the bugs existed before, they can be put in the backlog, prioritized, and a determination can be made about which team is responsible for fixing them. In this way, Zipper Sprints help the customer by providing a stable set of releases, and a constantly improving codebase with new features and fixes arriving each week from two different teams.
Embracing the Zipper Sprints Development Methodology in Your Organization
The concept of Zipper Sprints is not just a theory or a thought experiment. Our team has been using this technique for the past 4 years with great success. We have not made any significant changes to the process in that time, as both teams and the customer have all agreed that it works well. The Zipper Sprint process helped ease the tension from this unusual situation, while also allowing team isolation and promoting collaboration. To help facilitate this process, each team delivered its code changes as a Git Pull Request on the customer’s Git, and the other team had to approve the request before it could be merged. This not only facilitated communication about the changes being made (before they were applied), but it allowed each team to help enforce best practices and coding standards on the other team. Both teams had to come to an agreement about what coding styles would be followed and also had to follow them. Overall, I believe this process resulted in higher code quality overall. I recommend Zipper Sprints to any organization that finds themselves in this unique situation. It might also make sense for internal teams within the same company that has a large project and teams that are naturally split in this way. It may also be possible to extend this to more than two teams, but there are questions about the efficiency when split more than two ways.To learn more about the innovative technology solutions our talented teams have created for our customers, please visit the Mobomo website where you can peruse our service offerings, portfolio of work, and currently available positions.
