It was repeatedly observed that as the number of Scrum teams within an organization grew, two major issues emerged:
* The volume, speed, and quality of their output (working product) per team began to fall, due to issues such as cross-team dependencies, duplication of work, and communication overhead.
* The original management structure was ineffective for achieving business agility. Issues arose like competing priorities and the inability to quickly shift teams around to respond to dynamic market conditions.
In this presentation I will show you how to counteract these issues, using Scrum@Sclae framework for effectively coordinating multiple Scrum teams was clearly needed which would aim for the following:
* Linear scalability: A corresponding percentage increase in delivery of working product with an increase in the number of teams.
* Business agility: The ability to rapidly respond to change by adapting its initial stable configuration.
9. “Do Agile Right” and “Agile for
Dummies” are just two of the
innumerable attacks on the English
language featuring the word. They are
meaningless. Agile is not a noun, it’s
an adjective, and it must qualify
something else. “Do Agile Right” is like
saying “Do Orange Right.”
Dave Thomas
Source: https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html
Agility
11. Agile Software Development is an
umbrella term for a set of values,
principles, methods and
frameworks, all of which adhere to
the Manifesto for Agile Software
Development.
What is Agile Software Development?
16. Things to do before scaling
• Executive leadership support
• It is the most fundamental factor in transformation.
• Knowledge acquisition
• A systematic training and coaching program on agile values and
processes is required.
17. Things to do before scaling
• Integrating non software team
• Include more teams and functions in the transformation journey
• Tools and infrastructure
• Invest in modern tools and infrastructure to support fast and
frequent deliveries
18. Things to do before scaling
• Engineering excellence
• A strong engineering culture is very important when scaling agile
• Agile champions and change agents
• Any successful change requires someone who can translate an
organization's vision into reality.
19. Things to make sure during scaling
• Linear scalability
• A corresponding percentage increase in delivery of working
product with an increase in the number of teams
• Business agility
• The ability of a business system to rapidly respond to change by
adapting its initial stable configuration
24. History
• Jeff Sutherland and Ken Schwaber founded Scrum 1995
• The first rollout of Scrum@Scale in 2014
• In 2017 Scrum Alliance leadership asked Scrum Inc. to work with
them on a formalized scrum scaling framework.
• Jeff Sutherland Stepped down as a CEO from scrum Inc. in Jan 2018
to focus on Scrum@Scale
25. History
• The purpose was creating a framework that would be as useful to the
business and executives as to the people on the scrum teams.
• In May 2018, the 1st iteration of the guide has been released
• Previously know as Scrum of Scrums
26. What is Scrum@Scale?
• Lightweight: The minimum viable bureaucracy
• Simple to understand: Consists of only Scrum Teams
• Difficult to master: Requires implementing a new operating model
• Framework that is radically simplifies scaling by using Scrum to scale
Scrum.
• The Scrum@Scale Guide defines and describes the framework.
27. A minimum viable bureaucracy is defined as having the least amount
of governing and processes without impeding the delivery of value.
It helps to achieve business agility by reducing decision latency.
28. Why Scrum@Scale
• Most organizations are hierarchical, with authority centered at the
top.
• Having many levels resulting in long decision cycles and frequent
status updates to keep leadership informed.
• This structure reduces agility and responsiveness
• This also reduce the autonomy of the workforce and the engagement
of the teams delivering value.
32. Why Scrum@Scale
• Product Owners at all levels have the authority over the content of
their area aligned through the Product Owner Cycle.
• Scrum Masters are the owners of the process and work together to
improve flow and effectiveness of the organization.
• The Development teams have authority over delivery.
• This authority distribution model enables agility and engagement.
33. In order to begin implementing Scrum@Scale, it is essential to
be familiar with the Agile Manifesto and the Scrum Guide. If an
organization cannot Scrum, it cannot scale.
37. How to implement Scrum@Scale
• Scrum of Scrums Master (SoSM): The SoSM is accountable for the
release of the joint teams’ effort.
38. How to implement Scrum@Scale
Sample Diagram showing an EAT coordinating 5 groupings of 25 teams
39. How to implement Scrum@Scale
• The Executive Action Team (EAT) is accountable for the quality of
Scrum within the organization, the entire Scrum Master organization
reports into them.
44. How to implement Scrum@Scale
• Executive MetaScrum Team (EMS): The EMS owns the organizational
vision and sets the strategic priorities, aligning all the teams around
common goals.
48. How to implement Scrum@Scale
• Scrum Master cycle:
• Cross-team coordination – How do we coordinate between
different Scrum teams so we’re not both doing the same thing or
tripping over each other?
• Continuous improvement and impediment removal – How do we
ensure that all teams are aware of their skills and constantly try to
improve them? How do we ensure that whatever a team comes
upon will be resolved even if it falls outside their area of
competency?
49. How to implement Scrum@Scale
• Product Owner cycle:
• Strategic Vision – Where are we heading with the company and
our products?
• Backlog prioritization – What is most important for us at the
company level, the portfolio level, and within the project?
• Backlog decomposition and refinement – How do we allocate the
tasks among the teams, and how do we conduct sessions in
preparation for them?
50. How to implement Scrum@Scale
• Product Owner cycle:
• Release Planning – How do we plan for our deliveries? What comes
when?
• Release Management – How do we synchronize between teams to
get painless launches?
• Product and release feedback – How do we get feedback about the
latest launched features from the user, and how do we get that
information out to the teams?
51. How to implement Scrum@Scale
• Outside of these two cycles are also:
• Metrics and transparency – How do we measure that we build the
right things and how do we make sure that everyone has access to
these readings?