In our first post looking at Scrum and the Build Server we focused on the interaction between the Build Server and the individual build team. In this follow up, we take a look at how scaling agile practices like Scrum to a larger organization impacts the relationship with the build sever.

Small teams working together

Scrum places an emphasis on breaking down hard problems into smaller, more manageable pieces. It does the same thing with the project team. Scrum, like many agile methodologies, pushes for small teams of about eight people. For an enterprise delivering on large initiatives, dozens or hundreds of people can be devoted to a single initiative. This large group is split up into smaller cross-functional teams who keep each other updated through short daily meetings – the Scrum of Scrums.

While communication and easy visibility into project health is key for a small Scrum team, the difficulty of providing visibility into the numerous software projects of a department – or several departments – is significantly more challenging. The build server can’t simply light up the red lava lamp when the build breaks if the audience interested in that build is spread across six time zones. Emails, instant messages and RSS feeds start playing bigger and bigger roles. Even those messages can end up just being noise. As dashboards that help teams track the health of numerous inter-related projects at become more critical, we see agile teams looking to the build server for that information.

Challenges Scaling Continuous Integration

As several software teams work on the same code, some of the strategies popular in small scale software development with Scrum start running into difficulties. Continuous Integration suffers when hundreds of developers are working on the same code base and builds take longer. The rate of broken builds increases, the ease of determining the offending code decreases, detection of problems takes longer, and problems impact more people.

To address these issues, enterprise Scrum efforts will usually try to find a way to insulate teams from the problems other teams introduce while keeping high bandwidth communication – ideally merging working changes from the other teams frequently so that as much as possible the Scrum of Scrums can deliver together.

A Build of Builds

One approach that we’ve seen as particularly effective is breaking the project into components that can be built, and lightly tested separately. Just like how Scrum breaks a large team into smaller teams that work together through a Scrum of Scrums, a large application can often be broken into components and then assembled in a Build of Builds.

Any given component will usually have only one or two teams making changes. The rest will have that component delivered to them automatically when it passes some level of testing. Typically a bad change will fail testing, limiting its impact to only the team or two that is actively working on it. The rest of the teams remain unaffected. Dependency management tools like Maven, Ivy or Urbancode’s own CodeStation play a key role in supporting a component strategy to faster builds and insulation from bad changes.

The build server is a key component in managing the diverse components, and promoting them from the Scrum team level to the application team level. It should be aware of the dependency graph for smart build triggering, build avoidance and provisioning artifacts.
The same strategy is often pursued with SOA and related architectures. Here the components tend to be assembled not in a single build, but in a coordinated deployment. Scrum organizations using SOA often rely on enterprise build servers that have deployment capabilities to coordinate promotion of services in models similar to the code components discussed above.

A Tools and Processes Team

A final pattern the consulting team at Urbancode has noticed among larger organizations using Scrum, as well as more traditional organizations looking to be more efficient in the economic downturn, is the establishment of teams who are focused on delivering efficiencies for other groups. Instead of each Scrum team selecting and maintaining their own tool sets, they turn to a central team for best practices and shared services.  This strategy tends to make best practices easily transferred from team to team and gets project and configuration templates in place. If many of the software projects are built and tested in a similar ways, the central improvement team can spend an entire sprint optimizing that flow and getting teams on boarded into the build and deployment toolset.

When we consult with these teams, we’re often helping push this kind of process along and become a member of that Scrum team for a time.  From our experiences, these shared services models have been extremely effective at improving processes across the enterprises while leaving the application Scrum teams free to focus on delivering functionality rather than optimizing tool usage.
Large teams split into numerous small teams through Scrum seem to be leveraging the build server aggressively to communicate project health, and coordinate module sharing. The most successful teams often have a group focused less on delivering functionality, but rather on improving their customers – the development teams.
 
Naturally, being AnthillPro guys, we may see a stronger relationship between the build server and Scrum than others. Does this match what you see or are we way off base? Leave a comment and let us know