1

Lieber SAFe oder LeSS Vergleich

Scaled Agile Framework (SAFe) und

Large Scale Scrum (LeSS)

agile-scrum.de

Josef Scherer

josef.scherer@gmail.com

2

Services SPC, CSP, CSD, …

About Josef Scherer

Scrum/Agile Coach since 2007

Lead Agile Transitions @

Allianz DE, Telekom P&I, …

BMW: Senior Agile Coach @

IAP 2, BMWi USP

Coderetreats@BMW with Martin

Klose

josef.scherer@gmail.com

Leading SAFe training

SAFe Agilist (SA) certification

SAFe ScrumXP training

SAFe Practitioner (SP)

certification

Agile Release Train Quickstarts

Agile/Scrum Coaching

Solution Focused Coaching

Retrospectives & Innovation

Games Facilitator

I am a certified SAFe Program Consultant (SPC) , SAFe Trainer &

Scrum/Agile Coach

4

Framework Creator: Dean Leffingwell

4

5

SAFe Delivers Business Results

5

6

Roots of the Scaled Agile Framework

6

7

Lean Thinking

8

Systems Must be Managed

8

9

Lean Thinking House

9

10

Goal: Speed, Value, Quality

10

14

Product Development Flow

14

16 16

18 18

19 19

20

Agile Teams Produce Higher Quality Code

20

21

PSI / Release

timebox of 5 Sprints to synchronize release planning, inspection and adaption of an Agile Release Train

(50-125 people, 5-12 ScrumXP Teams)

22 22

23

Flow, Cadence & Synchronization

23

24 24

25

Develop on Cadence. Deliver on Demand.

25

27

Alignment

27

28

Key Program Level Roles

Product Management

Release Train Engineer (RTE)

System Architect

System Team

29

Product Management

Product Management is the „content authority“ for the Release Train

Continuously interacts with customers and

stakeholders for solution definition and

feedback

Owns the Vision

– Works with stakeholders to establish and

articulation Vision

– Defines statement, positioning, and solution

economic model

Drives the PSI/Release

– Defines and prioritizes Program Backlog

– Participates in Release Planning and I&A

Communicates the Roadmap

30

Release Train Engineer (RTE)

Facilitates release planning readiness and

the Release Planning Meeting

Assists program execution and tracking

Facilitates Scrum of Scrums

Ensures collaboration within and across

trains

Escalates impediments and helps manage

risk

Helps drives program-level continuous

improvement

The RTE is the „Chief Scrum Master“ for the Agile Release Train

31

System Architect

Helps to maintain a high level

understanding of system requirements and

NFRs

Evaluates design alternatives and performs

cost benefit Analysis

Presents the technological Vision during

Release Planning

Helps the teams make appropriate design

decisions during implementation

Establishes test automation strategies

Works with Enterprise Architects to

establish Architectural Runway

The System Architect plays a unique role in helping teams

efficiently implement stakeholder needs

32

System Team Integrates and Evaluates

Build/supports development infrastructure

and manage environments

Assist with test automation strategies and

adoption

Provide/support full system integration

Perform end-to-end system and system

quality (NFRs) testing

Stage and support System Sprint Demo

The System Team provides process and tools to integrate and

evaluate assets early and often

33

Program Level Artifacts

Roadmap

Program Backlog & Features

PSI/Release Objectives

Program Plan

34

Roadmap

The Roadmap guides the delivery of Features over time

35

Program Backlog & Features

36

Release Planning Team Deliverables

37

Program Plan, Milestones & Dependencies

38

Program Level Events

Release Planning

Scrum of Scrums

System Sprint Demo

Community of Practice (CoP)

HIP Sprints

Inspect & Adapt

39

Release Planning Meeting

Two days every 8-12 weeks

Everyone attends in person if at all possible

Product Management owns feature priorities

Development team owns story planning and high-level

estimates

Architects, UX folks work as intermediaries for

governance, interfaces and dependencies

Result: A committed set of program objectives for the

next PSI

40

Scrum of Scrums

The Scrum of Scrums is

a meeting for Scrum

Masters and the

Release Train Engineer

to gain visibility into

team progress and

program impediments

It is typically held twice

per week

It is timeboxed but is

followed by a “Meet

After” for problem-

solving

Programs continuously coordinate dependencies through

Scrum of Scrums

41

Continuous Inter-team Coordination

Agile team members

may visit other team’s…

Backlog grooming: to

see what’s coming next

sprint, request

adjustments

Sprint planning: request

adjustments

Daily standups: follow

up on execution

Team Demo: summarize

current stage

Agile Teams self-manage dependencies and resolve risks

42

Fortnightly System Sprint Demo

A demonstration of the

integrated software

assets.

For business owners

and other program

stakeholders (many of

whom could not attend

every team demo)

Happens after the team

sprint demos (may lag

by as much as a sprint,

maximum!)

Every sprint, the System Team/Product Management demonstrates

the solution increment to the program stakeholders

43

CoPs Support Continuous Learning

Typical CoPs:

– Architecture and Design

– Automated Testing

– Continuous Integration

– Etc. …

May meet multiple times per PSI/Release

Session example:

developer from ‘Transformers’ Team shows others how

to use mock objects in real examples

Agile Teams share new expertise and experience

via Communities of Practice (CoPs)

44

HIP Sprints

Hardening: Some system test, product and regulatory

validation, and documentation may not be practical

every sprint.

– BUT not an excuse to build up technical debt!

Innovation/Improvement:

– Opportunity for innovation spikes, heckathons, and

continuous education

– infrastructure improvements

– Inspect&Adapt Workshop

Planning: Readiness, Release Planning

Hardening/Innovation/Planning (HIP) sprints

enable cadence and delivery reliability

45

Inspect&Adapt

I&A has three parts:

Part 1.

The PSI demo of the solution’s current state to program

stakeholders

Part 2.

Quantitative measurement (Rel. Obj., Velocity, Quality)

Part 3.

The problem solving workshop

Attendees:

teams and stakeholders

Timebox:

3-4 hours per PSI

Inspect and Adapt (I&A) is to a Release Train what

the sprint demo and retrospective are to a team

46

Synchronizing

Waterfall & Agile Teams

Synch at key (PSI/Release)

milestones

Synch frequently (every Sprint)

47

Low Dependency Teams

48

High Dependency Teams

49

Large Scale Scrum

Principles

Organisations Design

Framework I (- 10 Team)

Team Coordination

50

Larman, Vodde 2008, 2010: LeSS bei Valtech & NSN

51

Komplexität, Einfachheit & Selbstorganisation

Simple, clear purpose and principles give rise to

complex, intelligent behavior.

Complex rules and regulations give rise to

simple, stupid behavior.

Dee Hock, Gründer und CEO VISA

Dee Hock.The Birth of the Chaordic Age

52

LeSS Principles & Themes

53

LeSS als Organisations-Design-Framework

Larman‘s Law: Cuture follows structure

beginnt damit Standard Scrum zu verstehen und

in einzelnen Teams anwenden zu können,

führt beim Skalieren zu tiefgreifenden

organisatorischen Veränderungen und

benötigt daher das volle Verständnis und die

Unterstützung des Senior Managements.

54

Die ideale Produktentwicklungs-Organisation

Scrum Feature Teams

Area Product Owner

Produkt Manager/Product

Owner

CXO CPMO

Produkt A

Area x Area y

Feature Team 1

Feature Team n

Feature Team 10

Service & Support

Produkt B

...

55

Von Spezialisten Teams zu interdisziplinären

Teams

IT Spezialisten Teams Interdisziplinäre PD Teams

Lead Designer

Designer

Designer

Lead Arch.

Architekt

Architekt

Lead Dev

Developer

Developer

Developer

Developer

Developer

Developer

Test Lead

Tester

Tester

Tester

56

Von Komponenten- zu Feature-Teams

Komponenten Design Fokus

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 oflow-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

All rights reserved.

Customer Feature Fokus

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 oflow-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

All rights reserved.

57

Von funktionalen Silos zu Communities of Practice

Funktionale Silos Communities of Practice

Leiter Design

Designer Team

Designer Team

Leiter Arch.

Architekten Team

Architekten Team

Leiter SWE

Developer Team

Developer Team

Developer Team

Developer Team

Developer Team

Developer Team

Leiter QS

QS Team

QS Team

QS Team

58

Von Verträgen zur direkten Zusammenarbeit

„Contract Game“ FB & IT Produkt Manager als PO

Product

Management

R&Dstart end

(release)content freeze

(release contract agreed)

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. V odde

All rights reserved.

59

LeSS Framework I für bis zu 10 Teams

60

Team Koordination

Durch gemeinsame Sprint Meetings mit Team

Vertretern

– Joint Product Backlog Refinement

– Joint Sprint Planning I

– Joint Retrospective

Interne Open Source, collective code ownership

Continuous Integration

Teamübergreifende Communities of Practice

(CoPs) z.B. für"

– Architektur

– User Experience

– …

61

SAFe Portfolio Level

62 62