While Agile methodologies have made tremendous advances in programming circles, build and release management teams have traditionally shied away from a “full agile” approach. In informal polling of Build Engineers, I found only one team outside of my own that ran an Agile shop; while there are many out there who do, there are tender points that need special consideration.
A Build and Release Engineering team (which we'll refer to as Engineering Services ) is an excellent candidate for the Agile methodologies. In the first place, our customer is extremely close to the development process - usually right next door if not in the same building. Much like application developers, time is the biggest constraint for Engineering Services teams. In our case bugs, administration of the build system, even instability (in less mature build systems and in-progress products), and the fluid nature of the products all contribute to this constraint.
Agile practices, and scrum in particular is the perfect fit for Engineering Services, assuming we acknowledge the same goals. Firstly, Engineering Services teams are customer focussed, service based, infrastructure development teams ; our customers come first, the services we provide those customers must always be our initial focus. Secondly, we want to eliminate root-causes rather than create band-aid solutions . Lastly, we want to automate the repeatable and ensure the reproducible. Meeting these goals, and transitioning to scrum involves a proactive approach.
An Engineering Services team is no different than an application development team. The scrum approach, process, and tools used are all the same. The real different is the amount of time that can be dedicated to features, as opposed to maintenance work. To achieve this, my Engineering Services team follows the process outlined below.
- Pre-sprint customer meetings
- Sprint planning and retrospective
- Daily Scrum + Commitment Review
- Scrum of scrums
- Sprint demo
- Backlog Grooming
As part of the backlog estimation process, I pro-actively meet with each customer individually, prior to our sprint planning. Much like with application development, this meeting is used as a sounding point with product owners, a period where we discuss stories and understand the nuances, spelling out more detail if necessary. As of this writing, the method is scaling well with five separate meetings.
All our story tracking takes place in VersionOne, which allows our customers (usually development managers and product management) to manage and track their own ordered backlog. Customers add and remove backlog stories as necessary, reordering them along the way. During Pre-sprint customer meetings, we discuss the backlog items, in order to better understand the stories. I add product specific development (not features) stories into the Request bin, again enabling my own tracking, and group discussion with our customers during this pre-planning phase. The key point here is that each customer fully owns their own backlog, providing them the ability to control their own needs and priorities.
Once these customer meetings are completed, I organize the stories by overall priority, by estimating the balance needed to meet customer needs. When conflicts are apparent (usually due to compressed schedules or conflicting needs), I redress priorities with these varying product owners, ensuring an agreement is reached. As part of this planning phase, Engineering Services reserves a percentage of their time per sprint for infrastructure needs; this comprises of our own, internal backlog that helps us expand the system to meet our customer needs.
Sprint Planning and Retrospective
Engineering Services teams engage in the same sprint planning mechanics as application development teams. Our planning meetings start with a retrospective of the current sprint: what should we start doing, stop doing, and continue doing. We review the comments from the previous sprint's retrospective and determine how we improved, and how we can improve.
The next step is sprint planning, looking at the ordered backlog and determining what we can commit to, as a team. Stories are discussed, hour estimates are assigned, and