More than XP. More than one day.

Should we use build & deployment teams on large projects? Build & deployment work often emerges as a specialisation on project teams. This specialisation becomes important on medium to large projects as the complexity of deploying code and configuring enterprise environments increases. But how do we coordinate the work of this team with the work of the development teams and how do we ensure this team helps the development team that it serves rather than hinders it?

In this report we share the experience of an eight person distributed Agile build team on a large bespoke software project at an investment bank. The report will span the formation of the team from the USA, the UK and India to the adjournment of the team after finishing the deployment to production on time without fuss. Topics include: how we worked in a distributed Agile 8-10 person team in San Francisco and London; how we used Agile methods to track build and deployment tasks; how we worked in iterations and estimated each iteration’s work, tracking velocity over time.

The project ran for months and raised many questions along the way:

• How is build and deployment work represented in a story world? Who are the customers? How do you prioritise? Are functional stories “complete” if they can’t be deployed to production?

• What are the trade-offs in having build and deployment specialisation? How do you keep the application and the deployment process integrated? Do the trade-offs change over time?

• Who should take overall responsibility for deployment? Should developers deploy their own code so they can eat their own dogfood? Or can a specialist team do this more efficiently?

• Who should own the build process? Should the build team keep their build machinery well maintained, or should they consult to the development team, enabling them along the way?

• Are developers incented to write code that is easily deployable? Is business value delivered if you can’t prove that code will work on a UAT system, if not production?

• Why do we procrastinate on doing deployment work so often on projects? Do the development team’s incentives match the value of automating deployment? What is the effect of trying to retrofit a deployment process at the end of a project?

• How many rehearsals of the deployment process should you have? Is there always a case for automating it?

• Should the IT department be in the deployment loop, or enable the build team?

Our conclusion is that the build team is a necessary part of a large project; but raising an organisational barrier between development and build/ deploy teams comes at a high price: The build team can end up as the owner of the build and release processes, changing the build scripts and deploying every release in the building. This can reinforce the importance of the build team to the other teams, thus perpetuating the role of the build team long after the original issues that led to the formation of the team have been resolved.

Finally we will present our advice for build and deploy specialists, developers and project managers on how to run an Agile Build Team, how to obviate the need for a large build and deploy team, and what we would do differently next time.