Agile Teams at Scale: Beyond Scrum of Scrums
Esther Derbyesther derby associates, inc.
www.estherderby.com@estherderby
Tuesday, December 13, 11
(c) 2011 esther derby
One team or a handful of teams may be able to deliver small systems. Large complex systems require teams of teams to deliver significant features.
How can companies benefit from “the team effect” at scale?
Tuesday, December 13, 11
(c) 2011 esther derby
Teams share...
a compelling work goal
responsibility and accountability
an approach to work
teams have...
complementary skills
five-seven members
history
Teams are one sort of goal-oriented social unit.
Teams can form the building blocks for larger goal-oriented social units.
Tuesday, December 13, 11
(c) 2011 esther derby
Teams offer possibilities that functional or component work groups do not.
flexibility
learning
engagement
responsibility
Tuesday, December 13, 11
(c) 2011 esther derby
Principles: A handful of guidelines for scaling team-based work.
Practices: Social and technical practices that enable team-based work.
Tuesday, December 13, 11
(c) 2011 esther derby
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
...and remember the Agile Manifesto
Tuesday, December 13, 11
(c) 2011 esther derby
Technical PracticesContinuous 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
Tuesday, December 13, 11
(c) 2011 esther derby
Social Practices
Scrum of Scrums
Integrating Teams (keeping in mind “avoid late learning”)
Decision Boundaries
Component shepherds
Tech council
Product council
Tuesday, December 13, 11
(c) 2011 esther derby
Scrum of Scrums can work with a small number of teams working within the same context.
Tuesday, December 13, 11
(c) 2011 esther derby
But a large system may have several contexts. (Think of context as a feature group, for example “order entry” in a sales system.)Form cross-functional teams within contexts.
Tuesday, December 13, 11
(c) 2011 esther derby
Make communication across context boundaries explicit. Use integrating teams to agree how to handle the interface and integration between systems. Integrating teams should also agree on and write acceptances tests that confirm integration across boundaries.
Tuesday, December 13, 11
(c) 2011 esther derby
When several teams touch the code of shared services or components, add Component Shepherds. Component Shepherds work to maintain the integrity of components. They review code, coach, provide standards and guidance to teams.
Tuesday, December 13, 11
(c) 2011 esther derby
Large systems may need both integrating teams and Component Shepherds.
Tuesday, December 13, 11
(c) 2011 esther derby
Tech Councils, made up of integrating team members, component shepherds, and test experts attend to the integrity of the whole system.
Tuesday, December 13, 11
(c) 2011 esther derby
Some useful resources from within the software domain:
Domain Driven Design by Eric Evans
Practices for Scaling Lean & Agile Development by Craig Larman and Bas Vodde
...and from the field of Organization Development and Design
Designing Team-Based Organizations by Mohrman, Cohen, and Mohrman
Creating Strategic Change by William Pasmore
Resources and References
Tuesday, December 13, 11