0:00
Do you know how agile works when it
0:02
scales across multiple teams and
0:03
departments? In this video, we'll walk
0:06
through the most important scaled agile
0:09
frameworks you need to know. Lean, safe,
0:11
scrum of scrums, less disciplined,
0:13
agile, and crystal. We'll explain how
0:16
each one works, what makes it unique,
0:18
and when to use which framework. At the
0:21
end of each framework, we will go over a
0:24
practice question together to help
0:26
reinforce the learning.
0:28
Be sure to stick around to the end to
0:30
get a clear picture of how these
0:32
frameworks handle coordination,
0:34
alignment, and delivery across large
0:38
Let's get started. One, lean. Lean is
0:42
not a framework itself, but a
0:44
foundational mindset and philosophy that
0:46
influences many skilled agile
0:47
frameworks. Lean focuses on maximizing
0:50
value for the customer while eliminating
0:52
waste. This approach originated from the
0:54
Toyota production system and has become
0:57
central to agile and business agility
0:59
practices. Key concepts in lean include
1:03
the seven types of waste which refer to
1:05
overp production, waiting,
1:07
overprocessing, excess inventory,
1:09
unnecessary motion, transport and
1:12
defects. Value stream mapping which
1:14
helps visualize the flow of value and
1:16
identify inefficiencies in the process.
1:19
Just in time means work is created only
1:22
when needed reducing unnecessary effort
1:25
and inventory. Kazan is the practice of
1:28
continuous incremental improvement over
1:30
time. Built-in quality ensures that
1:32
quality is part of the process, not
1:34
something added at the end. Respect for
1:37
people means empowering teams,
1:39
encouraging collaboration, and fostering
1:41
a culture of ownership. For the PMP
1:44
exam, expect to see lean principles
1:45
appear in scenario-based questions about
1:48
identifying inefficiencies, removing
1:50
waste, and improving team or process
1:52
performance. Let's look at a lean
1:54
question together. A project team
1:57
supporting an internal operations tool
1:59
is struggling to meet delivery
2:01
timelines. Developers often wait for
2:03
clarification on business requirements
2:04
and completed work sits in cues waiting
2:07
for approval. The project manager
2:09
familiar with lean principles wants to
2:11
address these inefficiencies without
2:13
adding more resources.
2:15
What is the best course of action to
2:17
improve the team's performance using
2:19
lean thinking? A. Increase the team's
2:22
velocity by assigning parallel tasks to
2:24
all members and reducing idle time. B.
2:28
Implement a formal change request
2:30
process to document all clarifications
2:33
and decisions. C. Reduce batch sizes and
2:36
focus on limiting handoffs and wait
2:38
times to improve overall flow. B.
2:42
Schedule more meetings between the
2:44
developers and stakeholders to clarify
2:46
requirements early. You can pause the
2:48
video here if you need more time. All
2:50
right, let's walk through this together.
2:52
The correct choice is C. Lean principles
2:55
emphasize flow efficiency, reducing
2:57
waste, and delivering value quickly. In
2:59
this scenario, the delays are due to
3:01
waiting and handoffs, both considered
3:03
forms of waste in lean. By reducing
3:06
batch sizes and limiting handoffs, the
3:08
team can deliver smaller increments
3:10
faster, receive feedback sooner, and
3:12
improve performance without needing more
3:14
resources. Choice A is incorrect.
3:17
Increasing parallel work may seem
3:20
productive, but often leads to context
3:22
switching and more work in progress,
3:24
which decreases overall flow efficiency
3:27
and can create even longer delays.
3:30
Choice B is incorrect. Adding more
3:32
formal processes like a change request
3:34
system introduces bureaucracy and slows
3:37
down response times. Lean advocates
3:39
streamlining processes, not adding
3:41
overhead. Choice D is incorrect. While
3:44
improving communication is valuable,
3:46
simply increasing meeting frequency
3:48
doesn't directly address systemic flow
3:51
inefficiencies. The underlying problem
3:53
is how work moves, not just how it's
3:55
discussed. Okay, let's move on if you
3:58
are ready. Two, safe. SAFE, which stands
4:02
for scaled agile framework. SAFE is one
4:04
of the most widely adopted frameworks
4:06
for applying agile at scale in large
4:08
organizations. SAFE provides structure
4:11
at multiple levels from team to
4:13
portfolio and integrates lean, agile and
4:16
devops principles. Key concepts in safe
4:19
include agile release train which is a
4:22
long-living team of agile teams working
4:24
together toward a common goal. Each
4:27
agile release train typically delivers
4:29
value on a regular cadence. Program
4:32
increment planning which is a
4:33
large-scale planning event conducted
4:35
every 8 to 12 weeks to align multiple
4:37
teams and ensure shared priorities. Lean
4:40
portfolio management which connects
4:42
strategy to execution by aligning
4:44
budgets, road maps and governance. SAFE
4:47
also introduces roles like the release
4:49
train engineer who acts as the chief
4:51
scrum master for the agile release train
4:54
product management which owns the
4:56
program backlog and solution architects
4:58
who guide technical alignment. There are
5:01
four safe configurations to adapt to
5:03
different enterprise needs. Essential
5:06
safe covers the basics needed for teams
5:08
and agile release trains. Large solution
5:11
safe supports complex systems involving
5:13
multiple agile release trains. Portfolio
5:17
safe adds portfolio level strategy and
5:19
governance. Full safe combines all of
5:22
the above for enterprisewide agility.
5:25
SAFE's core values include alignment,
5:27
built-in quality, transparency, and
5:30
program execution. For the PMP exam,
5:33
make sure you're familiar with terms
5:34
like agile release train, program
5:37
increment planning, and lean portfolio
5:39
management, and understand how SAFE
5:41
enables multiple agile teams to deliver
5:44
value at scale. Let's look at a scaled
5:47
agile framework question together. A
5:50
large enterprise is implementing SAFE to
5:52
improve coordination across multiple
5:54
agile teams working on a shared product.
5:56
During a program increment PI planning
5:58
session, several teams express concern
6:00
about overlapping dependencies and
6:02
unclear priorities. As a result, some
6:05
teams are uncertain about their
6:06
objectives and delivery timelines. The
6:09
release train engineer escalates the
6:10
issue to the project manager. What is
6:12
the best action the project manager can
6:14
take to support alignment and successful
6:16
value delivery within the safe
6:18
framework? A. Direct each team to
6:21
finalize their own PI objectives
6:23
independently to maintain team autonomy.
6:26
B. Facilitate a rep prioritization of
6:29
features through the product management
6:30
team and realign the program backlog. C.
6:34
Ask teams to delay commitment until all
6:36
dependencies are resolved through
6:38
documentation. B. Escalate the issue to
6:41
the lean portfolio management team for
6:43
immediate resolution and resource
6:45
allocation. You can pause the video here
6:48
if you need more time. All right, let's
6:50
walk through this together. The correct
6:52
choice is B. In safe program increment
6:56
and PI planning is a critical event for
6:58
aligning teams, identifying
7:00
dependencies, and committing to shared
7:02
PI objectives. When dependencies or
7:04
priorities are unclear, the product
7:06
management team responsible for the
7:08
program backlog should work with teams
7:10
to rep prioritize features and provide
7:13
clarity. This ensures that the agile
7:15
release train can move forward in a
7:16
coordinated and valuedriven manner.
7:19
Choice A is incorrect. While team
7:22
autonomy is important in safe, teams
7:24
operate as part of a larger system, the
7:27
agile release train. Finalizing
7:29
objectives in isolation undermines cross
7:31
teamam alignment and risks delivery
7:34
failure due to unadressed dependencies.
7:37
Choice C is incorrect. Delaying
7:39
commitment until all dependencies are
7:41
documented is contrary to SAFE's inspect
7:44
and adapt philosophy. SAFE encourages
7:47
teams to surface and manage dependencies
7:49
collaboratively during PI planning, not
7:51
defer planning. Choice D is incorrect.
7:55
Escalating to lean portfolio management
7:58
is not appropriate for resolving PI
8:00
planning level concerns. LPM focuses on
8:03
strategic funding and portfolio level
8:04
initiatives, not immediate future level
8:07
prioritization or dependency resolution.
8:09
Okay, let's move on if you are ready.
8:12
Three, scrum of scrums. Scrum of scrums
8:16
is a lightweight coordination method
8:18
used when multiple scrum teams work on
8:20
the same product. The goal is to help
8:22
teams remain aligned, manage cross team
8:24
dependencies, and ensure consistent
8:26
progress toward a shared goal. Here's
8:29
how Scrum of Scrums works. Each Scrum
8:32
team continues to follow standard Scrum
8:34
practices, sprints, daily stand-ups, and
8:37
retrospectives. The representatives from
8:40
each team, often the Scrum Masters,
8:43
attend a Scrum of Scrums meeting to
8:45
share updates, raise issues, and
8:47
coordinate work. A facilitator,
8:50
sometimes called a chief scrum master,
8:52
helps guide the discussions and support
8:54
collaboration across teams. Scrum of
8:56
scrums keeps the simplicity of scrum
8:58
intact while adding a thin layer of
9:00
coordination, making it suitable for
9:01
teams that don't need the full structure
9:03
of safe. On the PMP exam, look for
9:06
scenarios where a small number of scrum
9:08
teams need lightweight synchronization.
9:10
Scrum of scrums may be the best fit when
9:12
you want minimal overhead but need to
9:14
manage shared backlogs or dependencies.
9:17
Let's look at a scrum of scrums question
9:19
together. A company has four scrum teams
9:23
working on different components of a
9:24
single product. Each team runs its own
9:26
sprint, but teams often face delays due
9:29
to unresolved interteam dependencies.
9:31
The product owner has suggested holding
9:33
a large daily meeting with all team
9:35
members to improve visibility. However,
9:37
this has led to long unproductive
9:39
sessions. As the project manager, you
9:42
want to improve synchronization without
9:44
increasing meeting overhead. What is the
9:47
best course of action to enable
9:49
coordination and manage dependencies
9:51
across teams using agile practices? A.
9:55
Introduce a scrum of scrums meeting with
9:56
designated representatives from each
9:58
team to identify and resolve cross team
10:03
B. Require all scrum teams to align
10:06
their sprint schedules and attend each
10:08
other's daily standups for transparency.
10:12
C. Replace individual team standups with
10:15
one consolidated standup attended by all
10:18
members of every team. D. Assign a
10:21
central project coordinator to track
10:23
dependencies and provide updates to all
10:25
teams through a weekly report. You can
10:27
pause the video here if you need more
10:29
time. All right, let's walk through this
10:32
together. The correct choice is A. The
10:35
Scrum of Scrums is a lightweight
10:36
coordination technique used when
10:38
multiple scrum teams work on a shared
10:40
product. It involves selecting
10:41
representatives, often scrum masters or
10:44
rotating team members to meet regularly
10:47
and address cross teamam dependencies,
10:49
blockers, and integration concerns
10:51
without disrupting each team's autonomy.
10:53
It allows for synchronization with
10:55
minimal overhead, making it ideal for
10:58
small to midscale agile programs.
11:01
Choice B is incorrect. While aligning
11:03
sprint schedules may help, attending
11:06
each other's daily stand-ups is
11:07
inefficient and increases overhead,
11:10
especially as team members grow, it also
11:13
doesn't scale well or respect each
11:15
team's focus. Choice C is incorrect.
11:18
Consolidating all daily standups defeats
11:20
the purpose of the short focused scrum
11:23
event and leads to information overload,
11:26
which the scenario already shows is
11:28
problematic. Choice D is incorrect.
11:31
Assigning a central coordinator to
11:33
manage communication contradicts the
11:35
agile principle of self-organizing
11:37
teams. It also introduces a single point
11:40
of failure and reduces team ownership of
11:43
dependencies and integration. Okay,
11:45
let's move on if you are ready or less.
11:50
Less which stands for large-scale scrum
11:53
is an extension of scrum designed for
11:55
two to eight teams working together on a
11:57
single product. The idea behind less is
12:00
to scale scrum while keeping it simple
12:02
rather than adding new roles or layers.
12:05
Less extends the core scrum principles
12:07
to larger teams. Key elements in less
12:10
include a single product owner who
12:13
manages one product backlog shared
12:15
across all teams. Teams operate on a
12:18
common sprint cadence starting and
12:20
ending sprints at the same time. A
12:22
shared definition of done applies across
12:24
all teams to ensure consistency and
12:27
alignment. Minimal additional roles are
12:30
introduced. Less emphasizes
12:32
transparency, learning, and empiricism.
12:35
There are two levels. Less for up to
12:37
eight teams. Less huge for scaling
12:40
beyond eight teams using an area-based
12:42
approach. For the PMP exam, expect less
12:46
to show up in questions about scaling
12:48
agile while maintaining scrum
12:50
principles. It's a great fit when your
12:52
organization wants to avoid excessive
12:54
complexity and stick closely to the
12:56
original Scrum structure. Let's look at
12:58
a large-scale Scrum question together.
13:01
An organization is scaling Scrum across
13:03
five teams working on a single product.
13:06
Leadership wants to maintain strong
13:07
alignment with core Scrum values while
13:09
avoiding the complexity of layered
13:11
governance or multiple roles. The teams
13:13
share a single product backlog and
13:15
product owner. But recently,
13:17
inconsistencies have emerged in how
13:19
features are implemented. Some teams
13:21
feel disconnected from customer needs
13:22
and unclear on priorities. As the
13:25
project manager, what is the best way to
13:27
strengthen alignment and maintain the
13:29
simplicity of scrum in this scaled
13:31
environment? A. Introduce team leads to
13:34
coordinate work between teams and
13:37
communicate with the product owner on
13:39
behalf of each team. B. Assign each team
13:42
its own product owner and product
13:44
backlog to reduce confusion and allow
13:46
more autonomy. C. Hold joint sprint
13:49
planning reviews and retrospectives with
13:51
all teams to ensure shared understanding
13:53
and alignment. D. Appoint a central
13:56
integration manager to oversee
13:58
consistency across the product and
14:00
approve all changes before release. You
14:03
can pause the video here if you need
14:04
more time. All right, let's walk through
14:07
this together. The correct choice is C.
14:10
Large-scale scrum is designed to scale
14:13
scrum while preserving its core
14:15
simplicity and principles. Unless teams
14:17
working on the same product share one
14:19
product owner and one product backlog to
14:22
maintain alignment and transparency.
14:24
Joint sprint planning, reviews and
14:26
retrospectives are held. This promotes
14:28
shared understanding, encourages cross
14:30
team collaboration and reinforces a
14:32
product level focus, not just team level
14:35
execution. Choice A is incorrect.
14:38
Introducing team leads adds a non-scrum
14:40
role and undermines the self-managing
14:43
nature of scrum teams. It also risks
14:45
creating a communication bottleneck
14:47
between teams and the product owner.
14:50
Choice B is incorrect. Less deliberately
14:53
uses one product owner and one product
14:55
backlog to maintain product level focus.
14:58
Splitting responsibilities dilutes
15:00
priorities and leads to local
15:01
optimization rather than whole product
15:03
thinking. Choice D is incorrect.
15:06
Appointing a central integration manager
15:08
introduces command and control
15:10
oversight, contradicting less
15:12
principles. Less encourages teams to
15:15
self-organize around integration and
15:17
coordination, not rely on hierarchical
15:21
Okay, let's move on if you are ready.
15:24
Five, discipline agile. Discipline agile
15:28
or DA is not a single framework but a
15:31
decisionmaking toolkit that helps
15:34
organizations and teams choose their
15:36
best way of working. Disciplined agile
15:39
integrates practices from scrum, conbon,
15:41
safe, lean, and more and helps teams
15:44
make better choices based on their
15:45
context. Key concepts in disciplined
15:48
agile include choose your way of working
15:50
which encourages teams to tailor
15:52
practices that fit their situation
15:54
rather than blindly following a specific
15:56
framework. Disciplined agile delivery is
15:59
the foundational layer that focuses on
16:02
value delivery from inception through
16:04
deployment process goals that guide
16:07
decision-m across areas like
16:09
architecture, quality, governance and
16:11
risk. Disciplined agile emphasizes being
16:16
goaloriented, and enterprise aware. For
16:19
the PMP exam, you may encounter
16:21
questions about tailoring agile to fit
16:23
organizational or team specific needs.
16:26
Remember that disciplined agile promotes
16:28
flexibility, pragmatism, and guided
16:31
choices rather than rigid adherence to
16:33
one method. Let's look at a disciplined
16:36
agile question together. A global
16:38
enterprise is launching a high-risk
16:40
compliance-driven project. The team has
16:43
experience with Scrum, but is concerned
16:45
it may not provide enough structure for
16:47
regulatory needs. Leadership wants to
16:50
use an agile approach, but also ensure
16:52
proper risk management and
16:53
documentation. As the project manager,
16:57
you recommend disciplined agile to guide
16:59
the team. What is the best reason to use
17:03
discipline agile in this scenario? A.
17:06
Disciplined agile offers a prescriptive
17:08
process model for delivering software in
17:10
regulated environments. B. Disciplined
17:13
agile allows teams to tailor their way
17:15
of working by choosing practices that
17:17
fit their unique context and
17:19
constraints. C. Disciplined agile
17:22
eliminates the need for documentation by
17:24
replacing it with working software and
17:26
rapid feedback. D. Using discipline
17:30
agile requires switching completely away
17:32
from scrum and adopting a new framework
17:34
based on lean governance. You can pause
17:38
the video here if you need more time.
17:40
All right, let's walk through this
17:42
together. The correct choice is B.
17:45
Disciplined agile is a process decision
17:47
toolkit, not a prescriptive framework.
17:49
It supports teams in tailoring their way
17:51
of working based on organizational
17:53
context, team maturity, compliance
17:55
needs, and more. This pragmatic,
17:58
flexible approach allows teams to choose
18:00
from various agile, lean or traditional
18:02
techniques to achieve desired outcomes,
18:04
making it ideal for complex, high-risk,
18:06
or highly governed environment. Choice A
18:09
is incorrect. Discipline agile is not a
18:12
prescriptive model. While it supports
18:14
working in regulated environments, it
18:16
does so by helping teams make guided
18:19
decisions, not by offering a fixed
18:21
process for compliance. Choice C is
18:24
incorrect. Disciplined agile values
18:27
appropriate documentation when needed.
18:29
Replacing documentation entirely is
18:32
contrary to disciplined agile's
18:33
contextsensitive approach, especially in
18:36
compliance-driven or enterprise scale
18:38
projects. Choice D is incorrect.
18:42
Disciplined agile does not require
18:44
abandoning scrum or any other method.
18:46
Instead, it encourages teams to build
18:48
upon what works, tailoring and evolving
18:51
their way of working using guided
18:52
choices, including elements from Scrum,
18:55
Conbon, XP, SAFE, and others. Okay,
18:59
let's move on if you are ready. Six.
19:02
Crystal. Crystal is a family of agile
19:05
methods that emphasizes people,
19:07
interactions, and context over strict
19:10
processes and heavy tools. It's highly
19:12
adaptable and designed to scale based on
19:15
team size and project criticality using
19:18
color-coded variance to indicate the
19:20
level of formality needed. Crystal Clear
19:23
is ideal for small teams of up to six
19:25
people working on lowrisk projects. It
19:27
focuses on close communication, quick
19:29
delivery, and minimal process. Crystal
19:32
yellow supports teams of 10 to 20 with
19:34
slightly more structure for moderately
19:36
critical work. Crystal Orange is used
19:39
for larger teams of 20 to 40,
19:41
introducing more roles, coordination,
19:43
and governance. For high-risk or
19:45
missionritical projects, Crystal Red and
19:48
Beyond, like blue or violet, offer
19:50
greater rigor, documentation, and
19:52
control. What unites all Crystal
19:55
variants is their shared values,
19:57
frequent delivery of working software,
20:01
reflective improvement, which encourages
20:03
teams to continuously learn and adapt.
20:07
cosmetic communication, meaning team
20:10
members should sit close together to
20:12
share information naturally and
20:14
efficiently. Tailoring to context
20:16
instead of enforcing one-sizefits-all
20:19
rules, Crystal adapts to the needs of
20:21
each team and project. On the PMP exam,
20:24
Crystal is often the right choice when
20:26
scenarios involve smaller teams,
20:29
trustbased environments, and a need for
20:31
flexibility and simplicity. Just
20:33
remember, the color tells you how much
20:35
structure is needed. based on team size
20:38
and risk. Let's look at a crystal
20:40
question together. A startup is building
20:43
a customer-f facing web application with
20:45
a small experienced team of six
20:47
developers who work closely in the same
20:48
office. The team values direct
20:50
communication, quick delivery, and
20:52
minimal documentation. Leadership wants
20:54
an agile approach that supports these
20:56
preferences while maintaining enough
20:58
discipline for effective delivery. The
21:00
project manager wants to recommend a
21:02
methodology that fits this environment.
21:04
Which agile approach is most appropriate
21:06
for this project? ASAFE because it
21:09
offers structured planning and
21:11
coordination for multi-team
21:12
environments. B Crystal because it
21:15
supports small teams, relies on high
21:17
trust and emphasizes low ceremony
21:21
CDSDM because it balances governance
21:24
with adaptive delivery in fixed time
21:26
fixed cost environments. exp because it
21:30
emphasizes engineering practices and
21:32
detailed process guidelines. You can
21:35
pause the video here if you need more
21:36
time. All right, let's walk through this
21:39
together. The correct choice is B.
21:42
Crystal is best suited for small
21:44
colllocated teams working in
21:46
environments where trust is high and
21:47
communication is fluid. It emphasizes
21:49
low ceremony, simplicity, and
21:51
adaptability, making it an excellent
21:53
choice for a startup environment where
21:55
speed and direct interaction are
21:57
prioritized over heavy processes and
21:59
documentation. Crystal encourages
22:02
tailoring based on team size and
22:03
criticality, which aligns well with
22:05
scenario. Choice A is incorrect. SAFE is
22:09
designed for large multi-tim programs
22:11
needing structured coordination. It
22:13
introduces significant overhead that is
22:15
unnecessary and counterproductive for a
22:18
small, tight-knit team. Choice C is
22:20
incorrect. DSDM is more appropriate for
22:23
projects requiring fixed constraints and
22:26
governance often seen in enterprise or
22:28
government settings. It brings more
22:30
structure than is needed in a startup
22:31
environment prioritizing speed and
22:34
simplicity. Choice D is incorrect. XP
22:38
does support small teams, but comes with
22:40
a high degree of discipline and
22:41
technical rigor, including engineering
22:43
practices like test-driven development
22:45
and pair programming. While powerful, it
22:48
may be more structured than this team is
22:50
looking for based on their low ceremony
22:53
preference. Before we wrap up, let's
22:55
quickly summarize the six scaled agile
22:58
frameworks we covered. Lean focuses on
23:01
delivering value by eliminating waste
23:03
and continuously improving.
23:06
SAFE offers a structured approach to
23:08
scaling agile across enterprise teams
23:10
with defined roles and planning events.
23:13
Scrum of scrums adds a coordination
23:15
layer for multiple scrum teams without
23:17
changing core practices. Less extends
23:20
scrum for larger groups while preserving
23:23
simplicity and empiricism.
23:25
Discipline agile helps teams choose
23:28
their way of working based on goals,
23:30
context, and organizational needs.
23:33
Crystal emphasizes human interaction,
23:36
team flexibility, and lightweight
23:40
Mastering these scaled agile frameworks
23:42
will not only help you on the PMP exam,
23:44
but also prepare you to apply agile
23:46
effectively in large and complex project
23:49
environments. If this video helped
23:51
clarify things, please give it a thumbs
23:53
up. If you haven't already, consider
23:55
subscribing to our channel for more
23:56
agile content and visit our website at
23:59
pmasprint.com for additional project
24:02
management resources. Thanks for
24:04
watching and I'll see you in the next