I’m blogging the conference Agile Approaches for Delivering Business Value
Scaling Scrum
Rachel Davies, Agile Experience Ltd.
Summary
Scrum is the simplest possible agile method so it’s easy to get started with a small team of software developers. What happens when you try to apply Scrum to large projects? This talk shares experiences of working with large projects with multiple scrum teams and distributed scrum teams. Come to this talk to explore how to scale Scrum without losing the essence.
Notes
Sees lots of teams being successful with Scrum in small projects, but people tend to get lost when they look at scaling up… It’s an emergent field.
The challenges – highly collaborative, need the team involved in the planning, risk of losing easy way of resolving issues, hard work!
Scrum recommended team size is 7 +/– 2. Scaling could be many teams, geographical distributions, organisational level.
Rachel asked if anyone had experience above 5 teams – very few.
Scaling hits roles differently:
Product Owner – workload, being at all the meetings
Scrum Master – more inter-team issues, dependencies
Scrum Team – less empowered, large or distributed.
Challenges for Scrum Practices:
Establishing Sprint goal, distributed team members at Scrum meeting, Increment has dependencies on other teams, emphasis on electronic management of sprint backlog (remoteness), political impact on product backlog (more at stake on big project), sprint review – who’s in it?, combining lessons from teams in retrospective.
Organisational issues – greater potential for culture clash, impact of organisational impedance. Logistics of working environment and technical infrastructure.
Advice from the literature:
Scrum of Scrums
Start with a “Beachhead team” the use the members to seed other teams. (assumes you are starting a fresh project – Rachel sees lots of organisations getting benefit from Scrum on existing products)
For existing products – extract a virtual team to focus on forward plan, and another to focus on integration, keeping it all working.
May need communities of common disciplines e.g. DBAs
Align iteration boundaries across teams.
Think about series or parallel for multiple daily Scrum meetings
Keep clear about “levels” in plans – vision, releases roadmap, themes per sprint, product backlog, sprint backlogs per team.
Think about using a Product Owner team to share the load.
Common language, domain model, glossary. Architecture guidelines
Think about integration of the product – maybe a virtual team across the teams.
Think about testing – may need additional test team looking at whole product as well as the people in the scrums teams
Organise product showcase meetings for all teams to see whole product
Think about scaling the development infrastructure
Strike a balance:
Larger teams v. More teams
Contention for single Product Owner v. Product Owner team
Cross-functional team v. Specialists
Questions from the floor
Q: You mention feature teams v. component teams – difference?
A: Component teams might be a silo working on particular bundle of software e.g. a layer, possibly across multiple products. Feature team tend to focus on aspect of user-facing functionality for one product, possibly across multiple components – requires huge breadth of knowledge in the team.
Q: Thanks, trade-offs?
A: Knowledge-sharing. Team per component – might find one group is busier than other, so delays features. Feature-based teams address that, but the challenge is the amount of knowledge and skill in each team.
Q: How do you stop multiple sprints in between releases merging into one big sprint
A: Have to keep up strict discipline. Product Showcase on each sprint helps. Sprint Review of completion against velocity.
