Agile Teams at Scale: Beyond Scrum of Scrums

Agile Teams at Scale: Beyond Scrum of Scrums

Esther Derby

[email protected]+1 612 239 1214@estherderby

www.estherderby.com

mailto:[email protected]


http://www.estherderby.com


+1 612 239 1214 || [email protected] || www.estherderby.com || twitter: @estherderby || (c) 2013 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?






Three main challenges in scaling teams:

coordinating work across teams

integrating work across teams

maintaining technical integrity of the system






Principles: Guide stars for scaling team-based work.

Practices: Social and technical practices that enable team-based work.

Pathways: Steps to get from here to there.






Principles to AddressCOORDINATION

• Organize people and work to reduce coordination overhead

• Analyze demand

• Context teams over component teams

• Minimize product dependencies

• Aim for flow

• Build in slack and redundancy






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.






Teams offer possibilities that functional or component work groups do not.

flexibility

learning

engagement

responsibility






Scrum of Scrums can work with a small number of teams working within the same context.






Mike Cohn






A large system may have several contexts. (Think of context as a feature group, for example “Student Financial Aid” in a system to track financial aspects of students registered at a university.)

Form cross-functional, multi-skilled teams within contexts.






Principles to AddressINTEGRATION

• Make cross team and cross context communication explicit

• Teams that integrate together plan together

• Lateral links

• Design for early learning






Make communication across context boundaries explicit. Use integrating linkers to agree how to handle the interface and integration between contexts. Integrating linkers should also agree on and write acceptances tests that confirm integration across boundaries.






Principles to AddressTECHNICAL INTEGRITY

• Global and local standards

• Technical stewards

• T-shaped people






When several teams touch the code for services or component, add Component Stewards or Component Steward Teams.

Component Stewards work to maintain the integrity of components. They review code, coach, mentor, develop standards and provide guidance to teams.






Large systems usually need both integrating linkers and Component Stewards.






Tech Councils, made up of integrating linkers, component stewards, and test experts attend to the integrity of the whole system.

Product Councils look after product integrity.

Define decision boundaries for each sort of group.






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, UI & coding standards

Technical reviews






Social PracticesScrum of Scrums within context to surface impediments

Integrating links (keeping in mind “avoid late learning”)

Decision boundaries

Component stewards or teams

Tech councils

Product councils

Planning

Story Mapping

Central AND Local






• Lateral structures handle coordination and integration. People close to the issues have both the knowledge and means to make decisions.

• Scrum of scrums handles impediments.

• Information flows across and through, rather than up and down.






How do we get there?

Mid-level planning

Demand analysis

Removing technical dependencies

Smaller chunks

Pathways






It’s not simple

It’s not easy

There is no one right way

There is no prescriptive plan

You won’t get there in one giant leap






It is possible

You will get there by adapting, iterating, learning

You will create a more flexible organization

You will increase the speed and ease of communication

You will unleash potential






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

Images of Organization by Gareth Morgan

Designing Team-Based Organizations by Mohrman, Cohen, and Mohrman

Creating Strategic Change by William Pasmore

Leadership and the New Science by Meg Wheatley

Resources and References






Esther Derby

[email protected]

+1 612 239 1214

www.estherderby.com

@estherderby







Agile Teams at Scale: Beyond Scrum of Scrums

Business

Transcript of Agile Teams at Scale: Beyond Scrum of Scrums