Agile and SCM: Avoiding Agile Merge Disaster

February 22nd, 2011 by clucca Leave a reply »

As you start to scale Agile, code and user stories have to be merged more often. Sometimes changes may flow from one organization to another. This means that you will need to take code from one team, merge, integrate, and test those changes. Each team needs to be able to work on their own schedule, and if multiple teams want to work on different sized iterations, they can. In addition, they can deliver changes as necessary and on a regular basis, independent of other teams.

The problem? With a traditional SCM system, you have to merge these code changes daily for them to be of any use. You also need to keep visibility into what stories are shared between teams, because delivering changes from user stories that are not completed in a sprint would be disastrous.

Typically, people use a single baseline or “trunk” methodology for this configuration, where changes from each team are delivered to trunk and pulled from trunk as their iterations complete.

Working within an Agile context, your teams will have to deal with these branching and merging issues. But there are other problems that can happen when you do not use this methodology:

  1. Delivering 2 weeks worth of changes only causes isolation among teams
  2. It’s too hard to pick out each user story as it completes from our codebase
  3. Figuring out the dependencies of those user stories is complex
  4. Being able to identify what changes came from each branch becomes impossible

This “baseline pollution” is not scale-able. You can get around this by using a development hierarchy, and manage the relationship of dependencies between branches. This could also include process steps such as integration, quality assurance and code reviews. A separate code configuration can be used for each step and user stories could simply be drag and dropped between each team, state or branch instead of a merge.

Doing this will increase code stability. As a completed user story is pushed from one stage to the next, the particular change as well as the system as a whole reaches a higher level of maturity. Many traditional SCM tools do not easily support or surface a development hierarchy. An Agile SCM system supports the creation of a hierarchy, gives visibility into the changes at each stage, and enables straightforward merging between stages.

Advertisement

Leave a Reply

Anti-Spam Protection by WP-SpamFree