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.
http://submit2012.agilealliance.org/files/session_pdfs/ScalingAgileTeamsDerby2012.pdf
