Agile Codelines and Shared Traffic Space
The way an agile team works with their codeline is analogous to a shared space traffic model. As reported by NPR, shared space is an approach where most traffic signals and markings are removed; drivers, cyclists, and pedestrians are guided by a small set of rules. The approach works because all of the participants need to be more aware of their behaviors and follow the social conventions that govern travel.
Like most metaphors, this one isn’t perfect. But it’s close. Some of the traditional ways teams keep their codeline stable involve delaying integration into a single codeline:
- Staged integration
- Delayed integration using task or feature branches
- Requirements for extensive testing before checking in code
Each of these approaches gives you more stability by slowing down the rate of change on the main development line, rather like adding traffic lights on a road. If everyone pays attention to the signals, you may be safer, but you’ll get to your destination more slowly—and things can still go wrong.
By contrast, an agile team working on a single codeline using continuous integration works in an environment where progress moves more quickly because changes are integrated to the main development line frequently.
The increased awareness, analogous to how a shared space traffic model works, comes from two places:
- Development practices, such as private workspaces and builds, test-driven development, and pair programming, that help prevent errors from entering the codeline
- Notifications from the integration build when there are errors, and a commitment from the team to fix these errors as soon as they occur
Even when developers are careful to follow agile engineering practices and attend to quality, mistakes will happen, and unknown problems will occur. But that’s OK. The goal is not to avoid all problems; doing so would be impossible, and attempts to do so would slow down the team. The goal of agile development practices is to be disciplined enough to avoid significant problems so that the team can make rapid progress, as represented by working code.
There may be cases where slowing things down briefly makes sense. But it’s important to be aware of the impact of adding roadblocks and “traffic controls” to your development process. Rather than moving more slowly to ensure a stable codeline, consider approaches that keep the team more aware of the impact of their changes on the larger goal and help the team to make progress.
