Agile at Scale

Agile at
Scale
Tathagat Varma
Strategy & Operations, Walmart Global
Tech
Doctoral Scholar (EFPM), Indian School of
Business (ISB)

About me
• 30 years in software
industry: 5 years R&D,
25 years in software
products industry
• Involved in “big process
movement” from ’97
and “gave up” by ~’03
• Learning the “agile
way” through
practitioner
experiments since
’98…till date!
• Published
• Agile Product
Development (2015),
Apress
• Agile Software
Development (2017),
Self-published on Kindle

Agile Manifesto,
2001
• People-first:
Provided the first
major shift from
“process drives
people” to “people
drive processes”
• Four Values:
Described in four
core values
• Twelve Principles:
Supported by twelve
principles
http://agilemanifesto.org/

Principles behind Agile Manifesto
#1
Our highest priority is to
satisfy the customer through
early and continuous delivery
of valuable software.
#2
Welcome changing
requirements, even late in
development. Agile
processes harness change for
the customer's competitive
advantage.
#3
Deliver working software
frequently, from a couple of
weeks to a couple of months,
with a preference to the
shorter timescale.
#4
Business people and
developers must work
together daily throughout
the project.
#5
Build projects around
motivated individuals.
Give them the environment
and support they need,
and trust them to get the job
done.
#6
The most efficient and
effective method of
conveying information to and
within a development
team is face-to-face
conversation.
#7
Working software is the
primary measure of progress.
#8
Agile processes promote
sustainable development.
The sponsors, developers,
and users should be able
to maintain a constant pace
indefinitely.
#9
Continuous attention to
technical excellence
and good design enhances
agility.
#10
Simplicity--the art of
maximizing the amount
of work not done--is essential.
#11
The best architectures,
requirements, and designs
emerge from self-organizing
teams.
#12
At regular intervals, the team
reflects on how to become
more effective, then tunes
and adjusts its behavior
accordingly.
http://agilemanifesto.org/principles.html

Agile Manifesto defined agile killed
agility!
• “The word “agile” has been subverted to the point where it is effectively
meaningless, and what passes for an agile community seems to be
largely an arena for consultants and vendors to hawk services and
products. So I think it is time to retire the word “Agile.”
• Agile is not a noun, it’s an adjective, and it must qualify something else.
“Do Agile Right” is like saying “Do Orange Right.”
• But, beyond the grammar problem, there’s a bigger issue. Once the
Manifesto became popular, the word agile became a magnet for
anyone with points to espouse, hours to bill, or products to sell. It
became a marketing term, coopted to improve sales in the same way
that words such as eco and natural are. A word that is abused in this
way becomes useless—it stops having meaning as it transitions
into a brand.”
https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html

Agile from first principles…
• Those four lines and one practice encompass
everything there is to know about effective
software development. Of course, this involves a
fair amount of thinking, and the basic loop is
nested fractally inside itself many times as you
focus on everything from variable naming to
long-term delivery, but anyone who comes up
with something bigger or more complex is just
trying to sell you something.
• All of these sentences are imperative—they are
based on verbs telling us what to do and how to
do it.
• And that leads me to my suggestion.
• Let’s abandon the word agile to the people who
don’t do things.

Let’s develop with agility!
• “You aren’t an agile programmer—you’re a programmer who
programs with agility.
• You don’t work on an agile team—your team exhibits agility.
• You don’t use agile tools—you use tools that enhance your
agility.
• It’s easy to tack the word “agile” onto just about anything.
Agility is harder to misappropriate.
• And that’s important—you can buy and sell labels. Attend a
short course, and suddenly you can add a label to your job
title. But you can’t buy experience—you can only earn it.”

Pause and ponder!
• What is agile?
• Can I “buy” a bunch of “agile processes” and tools and
“do agile”?
• Does “doing agile” lead to “being agile”?
• How does agile differ from agility?
• How might be improve agility?
• What is agile all about?

Scaling agility
• Can agile scale?
• Scrum of Scrums (Jeff Sutherland)
• Nexus Guide (Ken Schwaber)
• Scrum@Scale (Jeff Sutherland)
• LeSS (Craig Larman, Bas Vodde)
• SaFe (Dean Leffingwell, 2011)
• Spotify Model
• What’s still the problem?

Can agile scale?
Agile Can Scale: Inventing
and Reinventing SCRUM in
Five Companies – Jeff
Sutherland, Cutter IT Journal,
Dec 2001

Scrum of Scrums (SoS)
• A technique to scale Scrum up to large groups (over a dozen people),
consisting of dividing the groups into Agile teams of 5-10. Each daily
scrum within a sub-team ends by designating one member as “ambassador” to
participate in a daily meeting with ambassadors from other teams, called the
Scrum of Scrums.
• Depending on the context, ambassadors may be technical contributors,
or each team’s Scrum Master, or even managers of each team.
• The Scrum of Scrums proceeds otherwise as a normal daily meeting, with
ambassadors reporting completions, next steps and impediments on behalf of
the teams they represent. Resolution of impediments is expected to focus on
the challenges of coordination between the teams; solutions may entail
agreeing to interfaces between teams, negotiating responsibility boundaries,
etc.
• The Scrum of Scrum will track these items via a backlog of its own, where each
item contributes to improving between-team coordination.
https://www.agilealliance.org/glossary/scrum-of-scrums

SoS: Scaling
structure
• The newly formed Scrum of
Scrums team applies nearly
the same practices,
participates in the same
events, and has the same
roles as a Scrum team. To
deliver an integrated,
potentially shippable product
at the end of every sprint,
additional roles might be
required, like architects or
quality assurance leaders.
• Organizations typically use
this approach as a first step to
scale agile and organize
delivery of larger and complex
products.
https://www.atlassian.com/agile/scrum/scrum-of-scrums

Scrum of Scrum of
Scrums (SoSoS)…
• Depending upon the size of an
implementation, more than
one Scrum of Scrums may be
needed to deliver a complex
product. In such cases, a Scrum
of Scrum of Scrums (SoSoS)
can be created out of multiple
Scrums of Scrums. Each of
these will have scaled versions
of each Scrum of Scrums’ roles,
artifacts, and events.
• Scaling the Scrum of Scrums
reduces the number of
communication pathways
within the organization so that
complexity of communication
overhead is limited. The SoSoS
interfaces with a Scrum of
Scrums in the exact same
manner that a Scrum of
Scrums interfaces with a single
Scrum Team, which allows for
linear scalability.
https://www.scrumatscale.com/scrum-at-scale-guide-online/#the-scrum-of-scrums

The Nexus Framework
• A Nexus is a group of approximately three to nine Scrum
Teams that work together to deliver a single product; it is a
connection between people and things. A Nexus has a single
Product Owner who manages a single Product Backlog from
which the Scrum Teams work.
• The Nexus framework defines the accountabilities, events,
and artifacts that bind and weave together the work of the
Scrum Teams in a Nexus. Nexus builds upon Scrum’s
foundation, and its parts will be familiar to those who have
used Scrum. It minimally extends the Scrum framework only
where absolutely necessary to enable multiple teams to
work from a single Product Backlog to build an Integrated
Increment that meets a goal.

Scrum@Scale
• Scrum, as originally outlined in the Scrum Guide, is focused on a single Scrum
Team being able to deliver optimal value while maintaining a sustainable pace.
Since its inception, the usage of Scrum has extended to the creation of
products, processes, and services that require the efforts of multiple teams.
• In the field, 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
• To counteract these issues, a 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 the initial stable
configuration
https://www.scrumatscale.com/scrum-at-scale-guide-online/

How S@S helps?
• Scrum@Scale helps an organization to focus multiple networks of Scrum Teams on
prioritized goals. It aims to achieve this by setting up a structure which naturally
extends the way a single Scrum Team functions across a network and whose
managerial function exists within a minimum viable bureaucracy (MVB).
• A network can achieve linear scalability when its characteristics are independent of its
size. Designing and coordinating a network of teams with this goal does not constrain
growth in a particular way; instead, it allows for the network to grow organically, based
on its unique needs, and at a sustainable pace of change that can be better accepted by
the individuals involved.
• A minimum viable bureaucracy is defined as having the least amount of governing
bodies and processes needed to carry out the function(s) of an organization without
impeding the delivery of customer value. It helps to achieve business agility by reducing
decision latency (time to make a decision), which has been noted as a primary driver of
success. In order to begin implementing Scrum@Scale, it is essential to be familiar with
the Agile Manifesto and the 2020 Scrum Guide. A failure to understand the nature of
agility will prevent it from being achieved. If an organization cannot Scrum, it cannot
scale.

The Hub of the SM
Cycle: The “EAT”
• The Executive Action Team (EAT)
fulfills the Scrum Master
accountabilities for an entire
agile organization. This
leadership team creates an agile
ecosystem that allows the
Reference Model to function
optimally, by:
• implementing the Scrum values
• assuring that Scrum roles are
created and supported
• Scrum events are held and
attended
• Scrum Artifacts and their
associated commitments are
generated, made transparent,
and updated throughout each
Sprint.
• formulating guidelines and
procedures that act as a
translation layer between the
Reference model and any part of
the organization that is not agile.

The Hub of the PO Cycle: The
“EMS”
• To fulfill the Product Owner role for the entire agile organization, the Chief Product
Owners meet with executives and key stakeholders at an Executive MetaScrum event.
This event is derived from the MetaScrum pattern. It is the forum for Leadership and
other stakeholders to express their preferences to the PO Team, negotiate priorities,
alter budgets, or realign teams to maximize the delivery of value. At no other time
during the Sprint should these decisions be made.
• At the Executive MetaScrum a dynamic group of leaders sets the organizational vision
and the strategic priorities, aligning all of the teams around common goals. In order to
be effective, the Chief Product Owner facilitates and each team’s Product Owner (or a
proxy) must attend. This event occurs as often as needed- at least once per Sprint- to
ensure an aligned backlog within the Scrum of Scrums. Optimally, this group of leaders
operates as a scrum team.
• In the case of larger implementations where there are multiple Scrum of Scrums, there
may be multiple MetaScrums which have their strategic backlog created and prioritized
at an Executive MetaScrum.

Organization Design
The goal of
organizational design
with Scrum@Scale is to
allow it to be
component-based, just
like the framework itself.
This permits for
rebalancing or
refactoring of teams in
response to the market.

LeSS: Large Scale Scrum
https://less.works/less/framework/introduction

Principles of LeSS
• Large-Scale Scrum is Scrum—It is not “new and improved Scrum.” LeSS is about applying the principles, elements, and
purpose of Scrum in a large-scale context. Multiple-team Scrum, not multiple Scrum teams.
• Empirical process control—Inspection and adaptation of the product, processes, organizational design, and practices to
craft a situational appropriate organization based on Scrum, rather than following a detailed formula. And empirical
process control requires and creates transparency.
• Transparency—Based on tangible ‘done’ items, short cycles, working together, common definitions, and driving out fear
in the workplace.
• More with less—(1) In empirical process control: more learning with less defined processes. (2) In lean thinking: more value
with less waste and overhead. (3) In scaling, more ownership, purpose, and joy with less roles, artifacts, and special groups.
• Whole-product focus—One Product Backlog, one Product Owner, one potentially shippable product increment, one
Sprint—regardless if there are 3 or 33 teams. Customers want the product, not a part.
• Customer-centric—Identify value and waste in the eyes of the paying customer. Reduce the cycle time from their
perspective. Increase feedback loops with real customers. Everyone understands how their work today directly relates to
paying customers.
• Continuous improvement towards perfection—Create and deliver a product all the time, without defects, that utterly
delights customers, improves the environment, and makes lives better. Do humble and radical improvement experiments
each Sprint towards that.
• Systems thinking—See, understand, and optimize the whole system (not parts), and explore system dynamics. Avoid the
local and sub-optimizations of focusing on the ‘efficiency’ or ‘productivity’ of individuals and individual teams. Customers
care about the overall concept-to-cash cycle time and flow, not individual steps.
• Lean thinking—Create an organizational system whose foundation is managers-as-teachers who apply and teach
systems thinking and lean thinking, manage to improve, and who practice Go See at gemba. Add the two pillars of
respect for people and continuous improvement. All towards the goal of perfection.
• Queuing theory—Understand how systems with queues behave in the R&D domain, and apply those insights to
managing queue sizes, work-in-progress limits, multitasking, work packages, and variability.
https://less.works/less/principles/overview

SAFe’s 10 Principles
1. Take an economic view
2. Apply systems thinking
3. Assume variability; preserve options
4. Build incrementally with fast, integrated learning cycles
5. Base milestones on objective evaluation of working systems
6. Visualize and limit WIP, reduce batch sizes, and manage queue lengths
7. Apply cadence, synchronize with cross-domain planning
8. Unlock the intrinsic motivation of knowledge workers
9. Decentralize decision-making
10. Organize around value
https://www.scaledagileframework.com/safe-lean-agile-principles/

SAFe 5.0
The latest version, SAFe 5, is built around the Seven Core Competencies of the Lean Enterprise that are critical to
achieving and sustaining a competitive advantage in an increasingly digital age:
• Lean-Agile Leadership – Advancing and applying Lean-Agile leadership skills that drive and sustain
organizational change by empowering individuals and teams to reach their highest potential
• Team and Technical Agility – Driving team Agile behaviors as well asl sound technical practices including Built-in
Quality, Behavior-Driven Development (BDD), Agile testing, Test-Driven Development (TDD), and more
• Agile Product Delivery – Building high-performing teams-of-teams that use design thinking and customer-
centricity to provide a continuous flow of valuable products using DevOps, the Continuous Delivery Pipeline, and
Release on Demand
• Enterprise Solution Delivery – Building and sustaining the world’s largest software applications, networks, and
cyber-physical solutions
• Lean Portfolio Management – Executing portfolio vision and strategy formulation, chartering portfolios, creating
the Vision, Lean budgets and Guardrails, as well as portfolio prioritization, and roadmapping
• Organizational Agility – Aligning strategy and execution by applying Lean and systems thinking approaches to
strategy and investment funding, Agile portfolio operations, and governance
• Continuous Learning Culture – Continually increasing knowledge, competence, and performance by becoming a
learning organization committed to relentless improvement and innovation
Mastery of these seven core competencies enables enterprises to achieve the agility needed to successfully respond
to volatile market conditions, changing customer needs, and emerging technologies.

https://www.scaledagileframework.com/

Variants of SAFe
• Full SAFe: Full SAFe represents the most comprehensive configuration.
It supports building large, integrated solutions that typically require
hundreds of people or more to develop and maintain.
• Portfolio SAFe: Portfolio SAFe is for enterprises building solutions that
require a modest number of Agile teams. It supports the development
of multiple solutions, which have minimal dependencies on one
another.
• Large Solution SAFe: Large Solution SAFe is for enterprises that are
building large and complex solutions, which do not require the
constructs of the portfolio level.
• Essential SAFe: Essential SAFe is most basic configuration of the
framework and it provides the minimal elements necessary to succeed
with SAFe.
https://www.scaledagileframework.com/posters/

Spotify
Model
https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

Pause and ponder!
• Where are we headed with creating all these larger,
bigger and fancier frameworks?
• Is the fundamental problem “how to scale an agile
team?” or “why to scale an agile team?”
• What is the hidden costs of creating all the overhead
roles, coordinating structures, and enabling
mechanisms?
• What might be alternate…and perhaps better ways to
scale a team without losing agility?

Open Source
Development Model
The open source
development model
presumes that
development is distributed
among multiple teams,
working in different
locations, in a fluid structure
that is resilient to new
arrivals or departures.
Successful open source
communities have
developed processes where
code can be submitted and
integrated asynchronously,
communication is well
documented, and features
are integrated in small
increments to catch issues
early in the development
cycle.
• Source: The Linux Foundation

Agile at Scale

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Agile at Scale

Similar a Agile at Scale (20)

Más de Tathagat Varma

Más de Tathagat Varma (20)

Último

Último (20)

Agile at Scale