Session by Ritu Mehta at Regional Scrum Gathering South Asia 2015

1. BEYOND SCRUM OF
SCRUMS-SCALING AGILE
HOW IT WORKS…..

2. 2
Agenda
• A bit about me
• Scrum at the team-level
• Scaling up to an engineering org

3. 3
My background
•Currently working as Director Product Development
at Pitney Bowes Softwares.
•15+ years of Development experience with 9+ years in
Agile
•Master’s in IT with SMP from IIM,Calcutta.
•CSM,CSP,SPC & PMP certified
• Global Agile Head for Pitney Bowes Software.
Heading five regions including Europe, US, Asia
Pacific

4. 4
Our Goal
•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?

5. 5
The Challenge
• 15 software development teams
•6 development and testing server
clusters
• 3 production server clusters in 4 data
centers
• A code base that was first created
around 2007 and built up over time
• And all utilizing one operations team

6. 6
What do we have?
• A mess of inter-dependencies

7. 7
So, how do we address this?
• Scrum of Scrums!
• Um, wait…

8. 8
Quick Review of Scrum
• Fixed iterations
• Daily stand-ups
•What did you do
yesterday, what did you
do today, any
impediments
• Retrospectives
• Burn-down chart
•Board with To Do, In
Progress and Done states

9. 9
Scrum in a slide
3 Meetings
Sprint: 4 weeks
3 Documents
3 Roles
PO
1
SM
3
Product
Backlog
1
Sprint
BL
2
Burn-down
3
Product
Stakeholders
On-going
Collaboration
Sprint
Planning
Sprint
Planning
1
Daily
Scrum
2
Sprint
Review
Sprint
Review
3
Daily
TEAM
2

10. 10
Scrum of Scrums (of Scrums (of Scrums…))
• How to integrate teams in Scrum?
•Hold a Scrum of Scrums
• What happens if you have too many teams?
•Hold a Scrum of Scrums of Scrums, and so on…
•Add a MetaScrum or two

11. 11
Can we apply few core principles of Kanban
• Visualize the workflow
•Team board states are a reflection of the value
stream
• Limit WIP
• Manage Flow
•Implied that flow should be continuous
• Make Process Policies Explicit
• Improve Collaboratively (using models & the
scientific method)

12. 12
Sample Kanban Board

13. 13
Scrum and Kanban: Let’s combine them!
(But how? And why?)

14. 14
Transitioning from Scrum to Kanban
• We did not change how teams were currently
working
• We modeled existing hand-offs within the team,
i.e. each team’s kanban board reflected that
teams style of work

15. 15
The Dilemma
Remember that teams
want (and often need) to
work continuously, but
releases are discrete.
Multiple teams working
together create
interdependencies
How to resolve this?

16. 16
Transforming Scrum (and Scrum of Scrums)
• At the enterprise-level, team(s) management
becomes a problem of dependency management
• Planning, coordination and stand-ups at the
departmental and organizational level need to be
executed with this mind

17. 17
What we have done
• At the organization-level:
•Prioritized project list
•All At Once Planning
•Classes of Service
•(Near) Continuous integration and (mostly)
automated regression testing
•Dependency and deliverable review
•Release train

18. 18
What we have done:
• At the team-level:
•Continuous delivery
•Better metrics and metrics-driven estimation

19. 19
Prioritized Project List
• Product Management, Engineering and
Operations leads meet every two weeks to
prioritize all development projects
• This becomes the organizational backlog, which
drives each team’s backlog

20. 20
All At Once Planning

21. 21
All At Once Planning
• Prior to the start of an iteration, teams use the
prioritized project list to plan their upcoming work.
• Planning involves the identification of deliverables
and dependencies.
• Dependencies are discussed with dependent teams.
• A meeting is held (all at once planning mtg) in which
all development teams present their dependencies to
each other and to the operations team.

22. 22
All At Once Planning, cont’d
• At the end of the meeting, each team has their
planned deliverables and incoming dependencies.
• If they haven’t already, they determine their capacity
and, based on the priorities, commit to a set of work.
• This means that a team may have capacity to do
work, but may not get to it in a release if that work
pushes the operation team beyond its capacity.
• Once the iteration starts, we will have each team’s
set of commitments.

23. 23
Classes of Service
• Inevitably, the operations team can often become a
bottleneck for development.
• We attempt to manage this through classes of
service. We borrow a concept from Kanban that says
similar projects are grouped into classes and each
class is assigned an allocation.
• For example, we may decide that 20% of ops time
should be spent on infrastructure improvements, and
80% spent on servicing development

24. 24
(Near) Continuous integration and (mostly)
automated regression testing
• It is important that builds, deployments and
testing are as automated and continuous as
possible. Tools we use:
•Team City for continuous integration
• Automated deployments
•Maven for managed builds
•Selenium for automated testing
•SVN for source control and versioning
• We still have a lot of work to do in this area

25. 25
Dependency and deliverable review
• We have a daily meeting, about 20 minutes, long
in which we review each project, not each team.
• Project leads review the deliverables and
dependencies to which they have committed and
say if they are on track or not.

26. 26
Dependency and deliverable review, cont’d
• We found the teams could still miss a deliverable
even if they had no impediments. Deliverable
tracking provides a better view of the state of the
iteration
• However, we still call the review meeting “Scrum
of Scrums” because the name stuck!

27. 27
Release Train
• Releases are iterative but development is
continuous

28. 28
Release Train, cont’d
• Scrum aims to make development iterative but
this causes problems:
•How do you handle all the testing at the end of
the sprint? What if defects are found a day before
the sprint ends?
• If a deliverable misses a release (the train), it
simply waits to capture the next one.
• To be reiterate (and be explicit): we don’t
penalize a team if a deliverable is not done at the
end of a release and misses the release train

29. 29
Release Train, cont’d
• To make this work:
•Releases must be short
•Must have those tools for automated
deployments
•Marketing and support must be flexible enough to
react to last-minute product changes

30. 30
Kanban at the team-level
• Teams plan continuously
• Teams test continuously
• It’s OK if a team finds a defect on the last day of the
release.
• It’s OK if a team starts work for the next release in
the current release
• Development and testing can flow more smoothly,
because we do not want the end of an iteration to
feel like this:

31. 31
Kanban at the team-level

32. 32
Metrics
• We gather for each team:
•Cycle time on items after grouping them by size:
• Completion time for small, medium and large
•Spread of cycle times
•Work items completed
•Open defects in production, to give a gross measure
of technical debt

33. 33
Metrics guide planning and estimation
• Over time, we expect that the spread of cycle
times for a given item size goes down.
• So, over time, an estimate of completion time for
items of a given size should become more
accurate.
• We have eliminated planning poker. Work items
are just sized as smalls or mediums and the
average cycle times for those sizes from the last
release become the estimate for the upcoming
release.
• Large items are broken down in smaller items

34. 34
How did we do?
• Releases used to take 12 weeks. Now they take 5
weeks.
• More importantly, testing used to take 6 weeks.
Now it takes 1 week. Testing used to be 50% of the
release cycle, but now is just 20%.
• We have a better picture of our release at any
given moment

35. 35
QUESTIONS…