BEYOND SCRUM OF
HOW IT WORKS…..
• A bit about me
• Scrum at the team-level
• Scaling up to an engineering org
•Currently working as Director Product Development
at Pitney Bowes Softwares.
•15+ years of Development experience with 9+ years in
•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
•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?
• 15 software development teams
•6 development and testing server
• 3 production server clusters in 4 data
• A code base that was first created
around 2007 and built up over time
• And all utilizing one operations team
What do we have?
• A mess of inter-dependencies
So, how do we address this?
• Scrum of Scrums!
• Um, wait…
Quick Review of Scrum
• Fixed iterations
• Daily stand-ups
•What did you do
yesterday, what did you
do today, any
• Burn-down chart
•Board with To Do, In
Progress and Done states
Scrum in a slide
Sprint: 4 weeks
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
Can we apply few core principles of Kanban
• Visualize the workflow
•Team board states are a reflection of the value
• Limit WIP
• Manage Flow
•Implied that flow should be continuous
• Make Process Policies Explicit
• Improve Collaboratively (using models & the
Scrum and Kanban: Let’s combine them!
(But how? And why?)
Transitioning from Scrum to Kanban
• We did not change how teams were currently
• We modeled existing hand-offs within the team,
i.e. each team’s kanban board reflected that
teams style of work
Remember that teams
want (and often need) to
work continuously, but
releases are discrete.
Multiple teams working
How to resolve this?
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
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
What we have done:
• At the team-level:
•Better metrics and metrics-driven estimation
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
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
• 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.
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.
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
(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
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.
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
• However, we still call the review meeting “Scrum
of Scrums” because the name stuck!
• Releases are iterative but development is
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
Release Train, cont’d
• To make this work:
•Releases must be short
•Must have those tools for automated
•Marketing and support must be flexible enough to
react to last-minute product changes
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
• 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:
• 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
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
• 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
• Large items are broken down in smaller items
How did we do?
• Releases used to take 12 weeks. Now they take 5
• 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