In recent public certified ScrumMaster classes, I was struck yet again by how many folks have burning questions about how to manage multi-team programs with agile.

Technically, the CSM is an introductory course, designed to give the basics of scrum sprints and releases and of how to lead scrum teams. More and more, though, I find that people feel the need to at least conceive how agile works at scale, even as they begin to implement agile for a single team. Tough questions from last month's class included: How to collaborate with non-agile teams on a single project, and how to handle coordination between multiple scrum teams.

I began to answer these questions in a recent webinar: "The Secret to Coordinating Multi-Team Agile Programs." In the webinar, I described why agile teams have the advantage when it comes to quality, value *and* coordination in multi-method programs. Because agile teams work iteratively and incrementally, bringing discrete bits of functionality all the way to their definition of done every sprint, they have maximum flexibility when problems arise with the inevitable dependency challenges. They find it easier to adjust from sprint to sprint based on new project information. And, they tend to contribute higher quality code to the overall program.

I have found that a key to success for the multi-team agile program--especially when all participants are new to agile--is to explicitly launch the program. A launch event brings all players together to form scrum teams (if needed), to create a shared understanding of program goals and constraints, to build initial working agreements, and to decide how the teams will coordinate activities. After that event, teams should be given a chance to start sprinting before they try to do release planning, so they can learn what iterative and incremental delivery means in their environment.

I was really excited to be joined on the webinar by Srikrishna Gopalakrishnan, eBay Senior Product Development Manager. I had the good fortune to work closely with Sri when we were launching eBay?s first Agile program. Sri talked about what it's really like not only to make the coordination work, but also to change the way you lead and manage, along with putting a different kind of energy into motivation.

Sri described how he helped the team get started, which is of course the hard part. He helped the teams see how they could set themselves up to learn--through the order they implemented stories--and thus replace fear with knowledge. Sri also did a great job of buying the program the freedom to fail safely; he set reasonable expectations with stakeholders which allowed the team to use an iteration or two for learning without jeopardizing project dates.

Sri and I also gave some practical tips for making coordination and integration work. In addition to the scrum ceremonies, multi-team programs will find they need to add other coordination events. For example, ScrumMasters and/or team leads might meet in a scrum of scrums. In addition, the product owners might need their own synchronization meeting; the frequency depends on how connected their backlogs are. Sprint demos should include all teams in addition to stakeholders, and sprint planning meetings might end with a chance for the teams to share their plans with one another.

A question from an audience member reminded me that programs-level scrum also adds new roles. For example, you might have product owners on each team, and then a chief product owner who has a leadership and coordinating role. A ScrumMaster or program manager might monitor cross-team coordination and remove cross-team or escalated impediments. A project manager might take on some of the work of sharing program-level information radiators inside and outside the program.

Coordination of course extends beyond dependencies and rolled-up reporting. As Sri explained to one questionner, teams must coordinate builds and integration on a technical level. For Sri's program, the stories in their sprints reflect when to use mock objects versus when to integrate and test end-to-end functionality. They have identified sprints where they need to merge code from other teams to do their end-to-end testing. They usually work of our own branch and frequently keep rebasing to the latest dev base (once every other sprint). This of course was just one group's solution.

Sri and I got to tell our stories, adding real-world experience to make sense of textbook agile.

I invite you to listen to and watch the recorded webinar - http://bit.ly/9yoVf1

About the Author