Managing Successful Agile Build Management Teams


team members pick off stories as they can. Team members are always asked “are you sure you can commit”, and the team as a whole is responsible for the sprint.


In our case, incomplete stories don't result in an aborted sprint, but a failed sprint. These are usually the result of last minute feature needs, or a decreased availability due to bugs, but underestimation or over-promising also contributes to these events. Rather than dogmatically “abort” the sprint due to a last-minute feature, we've chosen to integrate the XP concept of story trade-off, allowing our customers to eliminate stories to introduce others (where it makes sense).


Availability is the biggest problem facing Engineering Services teams, especially in the Agile ecosystem. Builds break, installers have bugs, infrastructure melts down... which all contribute to a reduced availability. The solution to this is two-fold. Firstly, my team plans different member availabilities based on product release schedules; for example, if two products are releasing in tandem and in the sprint being planned, the Release Engineer (also known as installer developer) will have little time. Secondly, we alter our plan to address infrastructure; ensuring a minimum percentage of our time is spent addressing infrastructure needs. This allows us to to address the root causes for build and infrastructure failure, in turn ensuring we have a higher availability for customer needs in the upcoming sprints.



Daily Scrum and Commitment Review

Like all good Agile teams, Engineering Services teams need to scrum, and scrum daily. The key, much like with other teams is adhering to the rules: talk about what you did yesterday, what you're going to do today, and what got in your way. Make it a point to Parking Lot non-reporting conversation and discussion, to ensure you run through the scrum; this helps the team quickly self-divide for conversation, and keep the process lightweight and engaged. Invite others to the scrum, if they add value. For the better part of three months, I had an application developer, and a team-lead from two separate teams attending our scrums.

Daily commitment is the other major takeaway that drives my team. Each of us commits to finishing something daily, in front of our team. We reinforce that commitment by writing it on the team whiteboard, exposing it to the public, and using it to drive our day. The next day we review the commitments. Did we meet them all? Why wasn't a commitment met? What could we have done to meet the commitment? Not only does forcing a commitment review encourage ownership and accountability, it also gives team members with the feeling of a job well done; it helps bring the idea of job completion to software engineering.




It's the nature of an Engineering Services team that emergencies come up. Machines break, builds require an unforeseen investment, or new installer features are injected at the last minute; all are possible. Anything that changes our sprint, anything that needed to be added into the sprint is done so in the form of a backlog story, added in VersionOne. This allows me to generate a Scope Creep report, in order to discuss what changed, and understand where our interruptions lie. These scope creep features have also been used as the inspiration behind backlog stories, or continue investment. They also help the team drive automation ideas, improving the Engineering Services product offering, while at the same time meeting the immediate needs of our internal customers.


Scrum of Scrums

A good Engineering Services team can affect multiple products, and is trusted to do so. We have

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.