Illuminating the potential of Scrum by comparing LeSS with SAFe

Illuminating the potential
of Scrum by comparing
LeSS with SAFe
with Rowan Bunning, CST and CLP

© 2016 Scrum WithStyle scrumwithstyle.com @rowanb
Please note
• Goal of this session:
awareness of the potential of ‘deep’ Scrum adoption at any scale.
• More about that than an comparison between SAFe and LeSS.
• There is lots to learn about Scrum by understanding the differences.
• This is not an introduction to Scaled Agile Framework (SAFe) and Large-
Scale Scrum (LeSS).
• Appreciating the importance of some concepts may require deeper
exploration than we have time for.

Session outline
• Unrealised potential
• Key things to know about SAFe and LeSS
• Business - Development relationship
• Team structure and batching
• Organisational control
• Co-ordination
• Where Scrum’s potential can be found

@rowanb© 2016 Scrum WithStyle scrumwithstyle.com
Payoff vs Extent of Scrum Adoption
Overall Payoff
Extent of Scrum Adoption
Deep Scrum
including implications of
Scrum and Lean principles
Implementation as per what
is explicit Scrum Guide only
Superﬁcial Scrum
as typically
implemented

Scrum adoption iceberg
Scrum as typically
adoptedWhat is Explicit in Scrum Guide
The implications of Scrum
that are implicit Explicit in LeSS
The endless potential of
continuous improvement
Shallow
adoption
Deep adoption

Single-function job titles
No job titles or sub-teams
Individuals accountable outside of team
Team is accountable as a whole
Content and timing of releases decided
by committee
Content and timing of releases
decided by Product Owner
Sprint Review involves inspection
Sprint Review involves collaborative
adaptation
Shallow Scrum as typically adopted
WhatisExplicitintheScrumGuide
The Tip of the Adoption Iceberg…

adaptation
Pseudo / Potential Team
Real / Exceptional Team
Undone work each Sprint
Potentially Shippable
Product Increment
Team work focus
Whole Product focus
Managers decide what,
how and do tracking
Managers support and
build capability
Co-ordination mostly centralised
Co-ordination mostly
decentralised
Contract Game
Co-operative Game
Single-function specialists
People with T-Shaped skills
Temporary Projects
Long-lived Product
Development
Component teams
Feature Teams
Bureaucratic control
Market + Clan control
Steep hierarchy
Minimum viable hierarchy
Team membership changes to fill skills gaps
Stable teamsCentralised specifier roles
Decentralised specification
Multiple localised process
improvement efforts
Whole of organisational
system process improvement
ScrumMaster focussed on team
ScrumMaster focussed on
organisational system
WDeepScrum-ImplicitinScrum
Organisation as Factory
Learning Organisation
Deep Adoption…

Key things to know
about SAFe and LeSS

150 people
Applicability Thousands of
people
>8 teams
LeSS
LeSS Huge
SAFe - single ART
Value Stream
of ARTs
2 teams
12 people
50 people
ART sweet spot: “100 or so”
Who is working with a group of between 12 and 50?

Different framings of the problem
Customer-centric LearningProgram Execution

© 2014 Scrum WithStyle scrumwithstyle.com
Not agile
Thanks to: Joseph Pelrine

Becoming agile…

Not like this though…

Scrum
Space for context-specific
elements to emerge
Prescriptiveness
How detailed, complicated and
fully-defined a framework is
High
• Not contextual enough
• Over-specification makes it
difficult for org. learning
• In practice, leads to
method bloat
Example:
Learning Organisations
(Peter Senge, Chris Argyris etc.)
Low
• Just a few principles
• Not enough that is concrete
to know what to do
• Easy to ‘fake-it’
Intent:
• Sufficient enabling structure
• Plenty of freedom for Empirical
Process Control & learning
Thanks to: Craig Larman

SAFe contains Scrum
Scrum Scrum
Team
Program
Value Stream
Portfolio

LeSS is Scrum
Team
Program
Value Stream
Portfolio
Scrum
➡

LeSS takes a different approach
Rather than having Scrum as a building block for a scaled framework, we
need to look at Scrum and for each element ask “Why is it there?” followed
by “If we have more than one team, how can we achieve the same
purpose on a larger scale?”
- Craig Larman

💡Insight…
Scrum need not be limited to the ‘team level’.
It scales vertically.

Business-Development
relationship

External contracts spawn internal contracts
Business
External
customers
Development / I.T.
External
contract
Internal
contract

We want a solution.
How much is it going to cost?
How long is it going to take?
Product
Management
R&Dstart end
(release)
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
All rights reserved.
Business Development

Product
Management
R&Dstart end
(release)
content freeze
(release contract agreed)
more,
more,
more!
1
The Milestone point
is arbitrary
The Contract
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
Business
Date & Scope
Development

Product
Management
R&Dstart end
(release)
content freeze
The Milestone point
is arbitrary
more,
more,
more!
less,
less,
less!
1 2
The Contract
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
The date and scope contract
point represents the time that
both parties have maximised the
ability to shift blame when
something goes wrong.
Date & Scope

Product
Management
R&Dstart end
(release)
content freeze
The Milestone point is arbitrary
The Contract
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
Date & Scope

Product
Management
R&Dstart end
(release)
content freeze
The Contract
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
Date & Scope
Responsibility
low control
low ﬂexibility
low transparency
big batches
cannot release early
not “done” until the end
Business
have
completed
date and
scope move
Development
shifts

Who has seen something
like this going on?
Who is working to an scope
& date agreement now?
Show of hands "

Product
Management
R&Dstart end
(release)
content freeze
* Development Phase for The Contract is controlled by R&D.
* The order of work is decided by R&D.
* Product Management does not have control, and there is low
visibility into the status of true progress.
The Contract
ineffective bonus schemes and "tracking
to plan" behaviors are injected, since
there is no real control or visibility
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
Business
• Development Phase for The Contract is controlled by the
development group
• The order of work is decided by the development group
• The Business does not have control, and there is low
visibility into the status of true progress.
Development

Shifting blame
Product
Management
R&Dstart end
(release)
content freeze
The Contract
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
DevelopmentBusiness
There’s been a
surprise!
But you
committed!
Date & Scope
sign-off

We have a two party competitive game
your faultyour fault
Product
Management
R&Dstart end
(release)
your fault your fault
The Contract
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde

Now development pulls out the ‘Secret Toolbox’ including…
• Stopping testing
• Crappy code
• No longer thinking about the design
• No longer taking time to learn
• Not ﬁxing weakness in organisation
• Overtime leading to attrition of the best people

On the SAFe PI Planning game
“This planning process has history with Nokia Phones, where the upper
management decided the schedule and content for the next model. Even
when at the talk level this is assumed to communicate realism upwards, the
process is really commitment game. Even, if the management culture
accepts the spirit of realism, the process itself assumes that you are able to
commit locally for the common good.
The teams are "staying in the room" until they vote yes or no for the plan.
They quickly learn to vote yes, because no means re-planning :)”
- Ari Tikka (formerly at Nokia Mobile where SAFe began)

Business
stakeholders
External
customers
Agile Release
Train
PI scope and
date commitment
External
demand

Business
stakeholders
External
customers
Teams
External
demand
✘ No Scope and Date contract
✔ Business steers directly
☸PO
📖

Scrum has the potential…
To eliminate the win-lose contract game
between Business and Development and
shift to a win-win co-operative game.
To end the blame game.
To begin rebuilding trust.

What does the Agile Manifesto have to say about this?

Two simple but critical questions…
Who is the customer to focus on?
What is the product to focus on?

Insurance company
What is our Product really?
Insurance
Sales
Underwriting
Solution
Premium
Billing
Claims
System
Quoting engine
Leads and
Opportunities
Policy provider
application
Rules engine
Premium
system
Insurance
booking system
Premium
payment
system
Claim checker
Pay back
engine
Underwriting
workﬂow
manager
Thanks to: Viktor Grgić for the example
The Market I see a Get Insurance
system
…and a Handle Claim
system
‘System of systems’ (SAFe)
or
‘Product’ (LeSS)
Insured Customer
Head of
Department
No, This is
a product
Architect
No, This is
a product
Project Manager
This is a
product

Whole Product Focus
- Bas Vodde
“It is really really hard to get teams to always
consider the whole product instead of just “their
tasks”. And in the LeSS Framework we do
everything we can to avoid sandboxing, such as
not preselecting items to teams, not having
separate backlogs, not having separate POs, etc.”
Lean Principle: Optimise the Whole

to help the organisation focus on the end
customer by deﬁning your product in terms
of what creates value for the customer.

Component teams lead to planning complexity
Item 1
Item 2
Item 3
...
Item 20
…
Item 42
current release:
need more people
next release:
need more people
System
next release
current release
Comp A
Team
Comp B
Team
Comp C
Team
Component
A
Component
B
Component
C
www.craiglarman.com
www.odd-e.com
Copyright © 2009
C.Larman & B. Vodde
How to manage these
dependencies?

Planning around component teams
Image credit: boost.co.nz

LeSS emphasises Feature-teams that are multi-component
Item 1
Item 2
Item 3
Item 4
…
…
Comp A
Team
Comp B
Team
Comp C
Team
Component
A
Component
B
Component
C
Product
Owner
Feature
Team
Red
tasks for A
tasks for B
tasks for A
tasks for B
tasks for A
tasks for C
contains ex-members
from component
teams A, B, and C,
and from analysis,
architecture, and
testing groups
system
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde

Dependencies are pushed from planning to integration
Item 1
Item 2
Item 3
Item 4
...
…
system
comp
C
Team
comp
A
Work from multiple teams is required
to finish a customer-centric feature.
These dependencies cause waste
such as additional planning and
coordination work, hand-offs
between teams, and delivery of
low-value items.
Work scope is narrow.
Product
Owner
comp
B
Team
comp
A
Team
comp
B
comp
C
Item 1
Item 2
Item 3
Item 4
...
…
Team
Wu
Product
Owner
Team
Shu
Team
Wei
system
comp
A
comp
B
comp
C
Every team completes customer-
centric items. The dependencies
between teams are related to shared
code. This simplifies planning but
causes a need for frequent
integration, modern engineering
practices, and additional learning.
Work scope is broad.
Component teams Feature teams
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde

Co-ordination is in shared code
Item 1
Item 2
Item 3
...
Item 8
…
Item 12
Team
Wei
Team
Shu
Team
Wu
Component
A
Component
B
Component
C
With feature teams, teams can always work on the highest-value features, there is less delay for
delivering value, and coordination issues shift toward the shared code rather than coordination
through upfront planning, delayed work, and handoff. In the 1960s and 70s this code coordination
was awkward due to weak tools and practices. Modern open-source tools and practices such as
TDD and continuous integration make this coordination relatively simple.
system
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde

Feature teams are customer-centric
Team has the necessary knowledge and skills to complete
an end-to-end customer-centric feature. If not, the team is
expected to learn or acquire the needed knowledge and skill.
Feature team:
- stable and long-lived
- cross-functional
- cross-component
customer-
centric
feature
potentially
shippable
product
increment
Product
Backlog
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde

SAFe Batch Size
Thanks to: Ran Nyman and Ari Tikka, Xp2015 Scaling
Agility explored - LeSS SAFe comparison
Development System
Work pre-allocated to Sprints for 8-12 weeks
Large batches to reduce cost
due to component teams
Program
Increment
Backlog

The trade-off
Pre-allocating items to Sprints ahead of
time closes off options and diminishes
Sprint-to-Sprint agility.

LeSS Batch Size
Thanks to Ran Nyman and Ari Tikka, Xp2015 Scaling
Agility explored - LeSS SAFe comparison
Development
System
2 weeks
Small batches that enable
fast feedback
Backlog
Product Increment
SPRINT REVIEW
RETROSPECTIVE
OVERALL RETROSPECTIVE
SPRINT
PLANNING 1PREVIOUS
SPRINT
NEXT
SPRINT
PRODUCT
BACKLOG
PRODUCT
OWNER
SPRINT
BACKLOG
SCRUMMASTER
& FEATURE TEAM
PRODUCT
BACKLOG
REFINEMENT
DAILY SCRUM
COORDINATION
POTENTIALLY SHIPPABLE
PRODUCT INCREMENT
SPRINT
PLANNING 2

to produce a Potentially Shippable Product
Increment every fortnight…
no matter how many teams… as long as they
are feature teams integrating continuously.
Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5

Program
Value Stream
Program control abstraction
Value Stream control abstraction
SAFe introduces control abstractions
Teams
Customer focused
Product
Customer

Control systems in organisations
Market system
Bureaucratic
system
Clan system
• Prices drive very efﬁcient decision making
• Measure Input and Output
• Formal rules, roles, processes, compliance
• Supervision, direction and hierarchy
• Specialisations enable clearer comparison with
like workers
• Informal value based rules
• Allows innovation and collaboration
• Most suitable for unique, interdependent or
ambiguous work e.g. software development
Reference: A Conceptual Framework for the Design of Organizational Control Mechanisms, William G. Ouchi, Management Science, Vol. 25, No. 9. 1979.

Control mechanisms in SAFe
Market control
many roles, processes,
written rules to
manage execution
within PI
Scope & Date contract
Clan control

Who would like less Bureaucratic control?
Market control
Clan control
You Ain’t Gonna Need It (YAGNI)
Try… direct business - development collaboration
using the simplicity of Scrum patterns
for Minimum Viable Bureaucracy (MVB)

Control mechanisms in LeSS
Market system
Clan control
self-managing
teams
self co-ordination
decisions at level of
richest information
PO
≪component≫
Publishing
≪component≫
Scheduling
≪component≫
Expenses
≪component≫
KPI Dashboards
Direct co-ordination
Communities for knowledge sharing and agreements Architecture, UX, Testing etc.
💡 $
😀 ☸

LeSS is about Descaling…
• Descaling roles and organisational hierarchy
• Descaling organisational structures, policies, etc.
• Descaling architectural complexity
LeSS is More!

to decrease bureaucracy
and increase business-development
collaboration
For more on this see:

The heart of Scrum
Thanks to: Simon Bennett.
Vision Product
Inspect &
Adapt
People Capability
Inspect &
Adapt

Frequency of Demos vs Sprint Reviews
Sprint Reviews - Inspect & Adapt Whole Product (2hrs max)
Team Demos
Solution Demo
(After all PI System demos,
1-2 hour)
System Demos

Frequency of overall reﬂection
Value Stream Retrospective
and Problem-solving workshop
PI Retrospective and
Problem-solving workshop
Overall Retrospectives - Inspect & Adapt Organisational System

Demos vs Sprint Reviews
Sprint Review
Purpose: “inspect the
Increment and adapt
the Product Backlog”
Intent: “optimise value”
Solution Demo
Purpose: “stakeholder
and customer
feedback” “celebrate
the accomplishments”
“harbinger of near-
term… decisions”
Mostly Value
Stream and
senior ART
people
PI System Demo
Purpose: “to test and
evaluate the full system”
Intent: “stay on course or
take corrective action”
Mostly PMs, POs
and senior people
One or more team
members there to
stage demo
Team Demo
Purpose: “closure” “to
show” “feedback”
“measure the team’s
progress”
Mostly teams and
POs
Senior people
likely not interested
“The Sprint Review is an
opportunity for everyone to
collaborate about the product.”
- less.works
😃
$

Business and development collaborate face-
to-face on the direction of the product…
every Sprint.
To focus everyone on the Whole Product.
To “turn on a time, for a time”
📖

Product Owner: Team or Product focused?
Team
Business Owner
Customer
Product Manager
2..4
Product Owner
1..2
The Product Owner
The Product Owner is responsible for
maximizing the value of the product
The person with the external (market)
contract problem steers directly
PO
☸

Product Owner can work with up to 8
teams when clariﬁcation is delegated
PO
Requesters Users Market / domain experts
Decisions
Content and order of
Product Backlog
Detail
Clariﬁcation - splitting,
acceptance criteria etc.
💡 $
😀
“Yes”
“No”
“A little now, rest later”
“Sooner”
“Later”
☸

💡Insight…
Scrum facilitates direct interaction between
business people and development teams…
…and not just with the Product Owner.

www.nature.com/scientificreports
Hierarchy is Detrimental for Human
Cooperation
KatherineA.Cronin1,2
, Daniel J.Acheson3
, Penélope Hernández4
&Angel Sánchez5,6
Studies of animal behavior consistently demonstrate that the social environment impacts cooperation,
yet the effect of social dynamics has been largely excluded from studies of human cooperation.
Here, we introduce a novel approach inspired by nonhuman primate research to address how social
hierarchies impact human cooperation. Participants competed to earn hierarchy positions and then
could cooperate with another individual in the hierarchy by investing in a common effort.Cooperation
was achieved if the combined investments exceeded a threshold, and the higher ranked individual
distributed the spoils unless control was contested by the partner.Compared to a condition lacking
hierarchy, cooperation declined in the presence of a hierarchy due to a decrease in investment by lower
ranked individuals. Furthermore, hierarchy was detrimental to cooperation regardless of whether it
was earned or arbitrary.These findings mirror results from nonhuman primates and demonstrate that
hierarchies are detrimental to cooperation. However, these results deviate from nonhuman primate
findings by demonstrating that human behavior is responsive to changing hierarchical structures and
suggests partnership dynamics that may improve cooperation.This work introduces a controlled way to
investigate the social influences on human behavior, and demonstrates the evolutionary continuity of
human behavior with other primate species.
recei e : 30 a 015
accepte : 0 o em er 015
Pu is e : Decem er 015
OPEN

CPJ inspired by Jeﬀ Bezos' most recent annual letter.
https://medium.com/21st-century-organizational-development/type-2-organizations-df3f1f53c66c
Which is Scrum enabling?

The responsive organisation
“The future of work is...
an organisation — a decision system — built to break down big decisions
and jobs into smaller pieces that can be processed much more rapidly,
replacing the illusion of top-down control over the future with realtime, active
control over the present. It’s an organisation where very few decisions are
made for others, but many more decisions are being made in the open.”
From CPJ inspired by Jeﬀ Bezos' most recent annual letter.
https://medium.com/21st-century-organizational-development/type-2-organizations-df3f1f53c66c
Who would prefer something like this?

Scrum of Scrums: ScrumMaster vs Team representative
“The ScrumMaster is typically the
representative in the Scrum of Scrums
meeting, and he passes information
from that meeting back to the team.”
“ScrumMasters… meet to update their
progress toward Milestones, program
PI objectives and internal
dependencies…”
“A healthy Scrum of Scrums meeting
is attended by team members who do
actual development work and not
ScrumMasters or the Product Owner.”
Intermediation Point-to-point connection

Co-ordination overheads can be reduced
Source: less.works/resources/graphics.html

Co-ordination mechanisms
Centralised mechanisms
Scheduled meetings
Disadvantages:
• bottlenecks
• handoffs
• delays
• inhibit emergent behaviour
• teams owning these processes
• inhibit empirical process control
Decentralised mechanisms
Networks of people interacting
Disadvantages:
• more difﬁcult to get an overview
• less broad and consistent info

Co-ordination: Centralised vs Decentralised
• Just talk
• Communicate in Code
• Integration
Continuously
• Communities
• Cross-Team Meetings
• Multi-Team Design
Workshops
• Current-Architecture
Workshops
• Component Mentors
• Open Space
• Travellers
• Scouts
• Maybe don’t do Scrum
of Scrums
• Leading Team
• PI Planning
• Pre-PI Planning
• Post-PI Planning
• Scrum of Scrums
• Weekly Release Management meetings
Mostly Centralised mechanisms Mostly Decentralised mechanisms

to radically simplify organisational structure
without the overheads of unnecessary
speciﬁcation, co-ordination and reporting
roles.

ScrumMaster: Part-time vs Full-time
“SAFe takes a pragmatic approach
and assumes, in general, that the
ScrumMaster is a part-time role”
Dedicated full-time role
In LeSS, the ScrumMaster role is vital. We’ve
seen many organizations try part-time
ScrumMasters, which usually leads to no
ScrumMasters at all. This then affects the
LeSS adoption enormously. In LeSS the
ScrumMaster is a dedicated, full-time role in
the same way that being a Scrum Team
member is a dedicated, full-time role. Having
said that, it is possible for one full-time
ScrumMaster ﬁll the role for up to three
teams, depending on any number of factors.

Where Scrum’s potential
can be found

No job titles or sub-teams
Team is accountable as a whole
by committee
adaptation
TipoftheIceberg-ExplicitinScrum
What SAFe explicitly encourages (1)
(See items in black)

Real / Exceptional Team
Product Increment
Team work focus
Whole Product focus
how and do tracking
Managers support and
build capability
Co-ordination mostly
decentralised
Contract Game
Co-operative Game
People with T-Shaped skills
Temporary Projects
✔ Long-lived Product
Development
Component teams
Feature Teams
Market + Clan control
Steep hierarchy
Minimum viable
hierarchy
✔ Stable teamsCentralised speciﬁer roles
Decentralised speciﬁcation
improvement efforts
Whole of organisational
ScrumMaster focussed on
DeepScrum-ImplicitinScrum
Learning Organisation
What SAFe explicitly encourages (2)

✔ No job titles or sub-teams
✔ Team is accountable as a whole
by committee
✔ Content and timing of releases
✔ Sprint Review involves collaborative
adaptation
TipoftheIceberg-ExplicitinScrum
What LeSS explicitly encourages (1)

✔ Real / Exceptional Team
✔ Potentially Shippable
Product Increment
Team work focus
✔ Whole Product focus
how and do tracking
✔ Managers support and
build capability
✔ Co-ordination mostly
decentralised
Contract Game
✔ Co-operative Game
✔ People with T-Shaped skills
Temporary Projects
✔ Long-lived Product
Development
Component teams
✔ Feature Teams
✔ Market + Clan control
Steep hierarchy
✔ Minimum viable
hierarchy
✔ Stable teamsCentralised speciﬁer roles
✔ Decentralised speciﬁcation
improvement efforts
✔ Whole of organisational
✔ ScrumMaster focussed on
DeepScrum-ImplicitinScrum
✔ Learning Organisation
What LeSS explicitly encourages (2)

Structure has a ﬁrst-order impact on Culture
Excerpt from Larman’s Laws of Organisational
Behaviour…

4. Culture follows structure.
Or, Culture/behavior/mindset follows system &
organisational design.

…systems such as Scrum (that have a strong focus
on structural change at the start) tend to more
quickly impact culture — if the structural change
implications of Scrum are actually realized.
Source: craiglarman.com

💡Insight…
Scrum is a catalyst for meaningful structural
change.
Structure has a ﬁrst-order impact
on Culture.
Process is a lower order inﬂuencer.

Review
1. Scale vertically, not just horizontally to help thousands pull together as one.
2. Reduce bureaucracy and increase business-development collaboration.
3. Transform the win-lose contract game between business and IT into a win-win
collaboration game.
4. Focus everyone on the end-customer and re-structure around this.
5. Produce a potentially shippable product increment every fortnight.
6. Enable the organisation to "turn on a dime, for a dime".
7. Enable resilient self-adapting of both What customer value is created and How it is
created.
8. Radically simplify organisational structure without the overheads of unnecessary
speciﬁcation, co-ordination and reporting roles.

Conclusions
• The implications of Scrum extend well beyond ‘team level’
• Few organisations have come close to realising the potential pay-offs from
Scrum’s implications in the large
• LeSS provides more explicit guidance on Scrum’s implications in the bigger
picture
• The biggest initial barriers to realising potential is understanding and buy-in

Where Scrum’s potential is articulated
less.works
Coming soon…

We’re@rowanb au.linkedin.com/in/rowanbunning
Rowan Bunning
rowan@scrumwithstyle.com scrumwithstyle.com

Illuminating the potential of Scrum by comparing LeSS with SAFe

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (8)

Similar to Illuminating the potential of Scrum by comparing LeSS with SAFe

Similar to Illuminating the potential of Scrum by comparing LeSS with SAFe (20)

More from Rowan Bunning

More from Rowan Bunning (11)

Recently uploaded

Recently uploaded (15)

Illuminating the potential of Scrum by comparing LeSS with SAFe