If you need a build of some sort, does protocol require you to ask someone to run it? Do you have to wait until the build team Bob is back from lunch in order to perform a build? Do you have to wait for one of a few people who actually know how to do a QA deployment in order to deploy to QA? If so, then you already know Bob the Builder.
We see Bob regularly: he is supported by institutional procedures, and in some cases Bob the Builder just makes sense: Putting the build or deployment in Bob’s hands ensures the build occurs when and how it should. And for deployments to production environments, these restrictions are often necessary. Even so, the knowledge of how to do the deployment should not reside in just Bob the Builder’s head: if he wins the lottery, the rest of the team can be in big trouble. Continue reading
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