Wednesday August 15, 2012 11:00am - 12:00pm
@ Texas C
Agile methods depend on effective cross-functional teams. We’ve heard many Agile success stories…at the team level. But what happens when a product can’t be delivered by one team? What do you do when the “team” that’s needed to work on a particular product is 20 people? Or 20 teams? One response is to create a coordinating role, decompose work, or add layers of hierarchy. Those solutions introduce overhead and often slow down decision making. There are other options to link teams, and ensure communication and integration across many teams. There are no simple answers. But there are design principles for defining workable arrangements when the product is bigger than a handful of agile teams. In this talk, I'll cover principles and practices and explain how they work together to address coordination, integration, and technical integrity. These are the principles and practices I'll illustrate. 6 Principles: Manage dependencies in the backlog as much as possible Aim for long-lived cross-functional teams Go as far down the technology stack as feasible Organize teams around context boundaries rather than component boundaries were ever possible Make cross-context communication explicit Avoid late learning Technical Practices: Continuous integration (CI) within context Integration across contexts at some other interval (keeping in mind “avoid late learning”) Mutually agreed upon and developed automated test across context boundaries Architectural & coding standards Technical reviews Social Practices: Scrum of Scrums Integrating Teams (keeping in mind “avoid late learning”) Decision Boundaries Component shepherds Tech council Product council I've attached a PDF of the current version of my slides on this topic. I'm sure they will evolve by next August.