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.  Continue reading →

Increasingly, when we visit enterprise customers, we find organizations that are using or adopting Scrum. In conversations amongst our consultants, we’ve observed a natural affinity between the build server and the Scrum process. While the most critical piece of technology for the Scrum team is often an agile project management tool like Rally or VersionOne, build and test automation can be a key to the success of a Scrum team.

Improving communication and visibility

Scrum is driven by an emphasis on good communication, flexibility, and empirical decision-making. For the software team, that means knowing and broadcasting information about the health of the code base is critical. This is where the build server plays a critical role. By constantly building and testing the codebase, providing reports, and broadcasting results the team has the information it needs to make solid decisions without devoting a lot of time to constantly rerunning tests or reports manually. Continue reading →