SAFe® Product Owner/Product Manager workbook v4.5.0.1 4.5 SAFe POPM

Citation preview

With SAFe® 4 Product Owner / Product Manager Certification

Md. §AFe

PROVIDED BY

SCALED AGILE” © Scaled Agile, Inc.

Digitized by the Internet Archive in 2023 with funding from Kahle/Austin Foundation

https://archive.org/details/safeproductownerO000unse

; &&

00:

a

A

Access the SAFe Community Platform Manage your member profile, join communities of practice, and access the member directory

Prepare Yourself Prepare for certification with your learning plan: access your course workbook, study materials, and practice test prior to taking your certification exam

Get SAFe Certified Get certified to achieve recognition of your skills and open the door to new career opportunities

O)

Showcase SAFe Credentials Use your digital badge to view global job insights, track market labor data, and see where your skills are in demand

community.scaledagile.com id

§AFe’

PROVIDED BY

SCALED AGILE”

od

Oe

5

|

:

hdd

d0dn

S8dIAIaS

paseyg

"et ues7Xn

ivy

wed]

wa}sks

rr’) = /.

UOISIA F

=

nag

MH

M

Ne

dewpeoy |

ay

\

|

sua,

49}SEIN

wns9g

alby

.

*

i

Lea) uM—

=

ater Pas yOnpold

2°

5

ALY

r+

3

rm ee

:

|

yonpold

Bug/usuy 2s jw6w

wajshs

ALS

i

=

Buyauy SC jw6,w

in

=

=

aram

— Loe ee aa a

€ = uequey

L_}

me a}noexq MOIAO 40 mee)

ght

Id

:

Bojyoeg

SYHAN

tesa

= =

x

=

go

pen! G

ey aw

eS

BS

=

aunyea4

es

=

rey

G

ae [¢|

aduapeg

eatin,

dojaneg uo

“

G

Ce? MOR -

G

aunjea4

~

RON

G

gs

~

= : a

77NA

LL02-B002 PeleoS ‘eUBy‘oul

Cv

is. uy-ying Ayyend

=I

WVSL

jeanjyoayiyouy

KI@A0DSY

+

Aemuny

UuOHeWONY

UBd7] MO|-{ jUaWai

« «

BINYND

sdgaeq

WVu

UOI}NjOS }X9JU0

«

«

@

NOI

o0

uone

s2wojsno FY

39uV1

ord s

WY” OVS

‘I}eMBUYOT 9 "1e @

|MEE

oo G

|

>

f=

ByDCcr[Es ES ss

1]qeu3

puewag

eseajay

uoKNjos

SWed‘}S

ee

Lope

juawAojdaq uo

eeeoo

devant

IFeu

ceva

Ga F

Suol}e49}|

=

2

B= ainjee Gi SS=

wa}sks sowaq

uonesbaju]

uoljei0jdxy

ois

6]

ae a?

abe ala 2

mee

See

“as

owoguoHNnjos

anjep

Snonurju09 Aiaaijag auljadig

NOILNTOS NIVEL=

erates sjo6png

snonuljuog

See io

40|qeU3

“

4

Boyyoeg

eudN

—

eo

S8AI}99/G0

“a,

S19UMO =I

ge

=_

Bopjoerg

=|‘|

Brel Be uea

SUAN =

wry

WIS H+ way

cas

{

Bojyoeg

“iin

—

ie

aoueldwoy

qsaw oe

F

x

© 3.

ylomawel4

uee7]

O1ojs0g}WBW

3

Dierag zs

poyYy.y

Nee a,

°

21W0u02"

‘9

ome ad | Sn}

o16a}e3g

sowey,

uOHIN|OG

AS)

0

aint Lice

——: =:

UOl}N|OS =

BS

@

|

SOUO}SOIIN

eae Ao

ae

woe

—

;

eae

id

“ee

ed

ie

4 ne my SOME uoleuipsoo

ey

“2

si9uUMO

o1dg

Siepeo] pay ajby-uecl w@

|

an

SenieA — aop '_!|

asiudiajuy

J@SPUIN == oallby-uee7 MT

Z

sojdioud =. esvS =]

= |

deuipeoy ===> uoneuewejduy C=

Saslidia}yuy

#@

ued]

24S

-O4WS 10j

JAMSV Ga1VIS

Ga0|A0’d Ad

:

es

a

a

ie

Ee

-

}

sy

“i

(ee

ae ar

efeae

ae

a t,

=

SOM}IW

.

wee

wa}skg

a

UOISIA,

;

MH

M4

ine

Aeg

dewpeoy.

:

fs)

| aby

e

e

wea

sues

49}SeW

ie

3

Bagy

all

ronmp

Teer ny

WLM

Ss

JONPOld

) wy

Buayyouy | yw6yw rae

we

wajsks

are

oe

2

10s

uonnjog

ues]

Busyyosy ywb\

|A

uonnjog

ww

@ Seuc}senii Sg

ag

eo

Tar

dole

Sedlnles

peeys

wy

Seoe

Be,Ma m”

a gy

|

@

84S 10}

«

~y

Se

”

{—

2990X3mes)

e109 senea ==

=

a

3.

e

=

49)qeu3

any-ueey =

=

By-ue > JOSPUIN —

=

*s

|

; :

dojaaaq uo Can.

49\qeu3

| d}

ra

Aimersa mi

einjee4

uones6azu]

s

r

_

fog

dewpeoy os nas

3

Aiaaooey

UsWsINSe

UONeWONY UBS] MO|-|

WY”

‘WeMBuye 38 ‘Ie©

OVS

Cv 210Z-800Z Pe|29S ‘lB‘ou

=~

=

ai

Wal

jeanyoayyouy

2

SIn}jnNO

sdoaesq

WVa

UOIIN|OS }X9}U

Lionnios

Aemuny

«

«

« «

.

NOI

39yV1

s2wojsna FY

uolze

NOILNIOS

]]Q|Q|/Q\/Cm] eae uj-yin Ayyeny

]Q)}Q;Q 7 | di4]

aa

Fe

BXDUEY[—&

puewag

wos

T]qeuy

aduaped vonejvowsiduy =@

Ps

es

aunjea4

om

XN

uoNNjog

eseajay

39NV1

juawojdeg uo

wth

: fl

uoNNjos

snonulijuod eget

=

ae eed

Nwolintos _

ee sojdiouug 5 ===

edvS

mor rv

Suonesa}|

ainjea4

wajshs sowaq

uonesojdxy

snonuijuog

Eo

Qa xe 1 at

(

BHojyoeg

SUIN

—| |

—

a

SaAt}291qG0

a?

:

BHojyoeg OM

SUAN

—

=

ver SYN

Cold

ayiBy-uee '_' _S/9P801 17,

ou

Id

=I

ssouisng SJ9UMO

we

eo”

Bojyoeg

uequey Stet iid

sl

a5

wind A

se

s

paseg-y2s

asaw

-Bse d

L__}

bac

ats

ina ._

Xx rd

L__]

NOLLNI

—

=

:

ae

eouelduog

viomeurert

91WOU0D

ts}

sasidisjuq

GS0IA0’d Ad

Ga1VIS AMSV

£@

dewpeoy

°=“=—5

vonewowsiduy CA

puewag

‘emBuyeq ‘Ie © 2107-8002 pajeog ‘allBy ‘oul 38

uonejuewej du)od$S Pat

aouapeg

randy

‘

“a

=®

s8woisny FY

TWILNASS3 uonei

E

Jajqeuy

uo juawAojdaq

peste

aunjee4

CLRae tees

snonunuoy Aiaailjag auljadig

apes tines:rouse deers peasgs ee

re

eh

ae

49|QeUu5

S8AI}93/4O

ee :

=I

Bojyoeg

SU4N

i

E=

MOIAOY 40 ee) 01}0y wik

SS—

Urids

Id

caus

ve

sasiidiajug

§ Bojyoeg einyoayyouy a & Njeo4

c jUswWainseay -

=

-B4W JO}S ued]

\ ww

G30IA0’d Aa

G31VIS ANMSV

jis

e4VS seapiamaaast |dewipeoy sejdisuid

si9peey aiGy-uee}

Contents

LessOnmeApelyiindisd Ge initine: bean

eriter [email protected].,.. ys

Lesson 2: Relating a Lean-Agile Mindset to the PO/PM

Roles............. 22

Lesson 3: Collaborating with Lean Portfolio ManageMeNt voeecccccccccccecece 42 Lesson 4: Continuously Explore Customer ECSS Olea xectitingsthe

Program

Lesson 6: Defining the PO/PM PessOUr

e Seating VoUr

PO

N@e@dS vecccccccccccecccceccccecccccce. Ve

Increamentiw.usiweeeaudeitescencn.Oy

Roles and Responsibilities ....ccccccccc. ive:

PM ACtiOn FIAM scl Scceisvleececsccossehssechecdeleecc,, 188

fadelorelcraiye AC FeVeyo\whe ale: ledsadeecey 4) ere Geen meter eee Appendix

B: Management

meee ee a

198

30 Delegation Card horccecccccccccccccccssccececcccccecees JAGY:

A SAFe Glossary can be found at the back of the workbook

1 | ©SCALEDAGILE, INC.

SEE WORKBOOK PAGE

> Find someone you don’t know or haven’t connected with in a long time > Introduce yourself and share with them: — Two things you already know about the Product Owner and Product Manager roles

~ Two things you hope to learn about the role during this course

;

> After five minutes, team up with another pair and take turns introducing the person you just met

. q ©) j i

SCALED

AGILE™

© scales Aaile, inc

XN

!

7

-©- Thought organizer

ae

ee

eee 2

| ©SCALED AGILE, INC.

ee ee ee

ee

es

ee

To perform the role of a SAFe® Product Owner/ Product Manager, you should be able to: » Apply SAFe in the Lean enterprise |

» Connect SAFe Lean-Agile principles and values to the PO/PM roles

> Collaborate with Lean Portfolio Management > Explore Continuous Value with Program Increment Planning

» Execute the Program Increment and Deliver Continuous Value > Articulate the Product Owner and Product Manager Roles

> Create your Role Action Plan

|

i. SCALED AGILE”

Notes

Z © Scale: Aaile. inc

1.3

|

SAFe* Product Owner / Product Manager topics 1. Applying SAFe in the Lean Enterprise

5. Executing the Program Increment

2. Relating

6.

a Lean-Agile Mindset to the

PO/PM Roles

Defining the PO/PM Roles and

Responsibilities

3. Collaborating with Lean Portfolio Management

7.

Creating your PO/PM Action Plan

4. Continuously Explore Customer Needs

SCALED AGILE”

Notes

©@Scslec Aaile. inc

1.4

|

3

| ©SCALED AGILE, INC.

Logistics

|

> Pairing Method » Class times

> Breaks

|

> Lunch

Elephant

|

Penguin

|

Giraffe

>» Restrooms

> Other

Dolphin

West

Zebra

(Back to top)

SCALED AGILE® ©s

ms

&

Learner to

sO

Sore

LY \

a

Games

fo e=% Making

Connections

Key Learning & Insights

Pyar

;

=

rain-

Cabcael

based

onclusions

|

Graphic & Thought Organizers

A

} Exploring

= learning /Concepts

a

Concrete

Ball Toss

Practice

Interactive

Reporting

Pe

Learnin:

\-

Hho

J

—

|

—

«

:

it

“2% s

yee

ae

ae

|

SCALED

AGILE™

Ey

—

»

ae q

Training from the Back of the

"2

Room,

Serres

’

.

Sharon L. Bowman :

Seelec Asie. inc

©

[24

me)

Demonstrations

|

sa

E

|| @-e-0

Notes

Introducing the course workbook “O- Tho JQht organizer IP Iteration is

‘TWoting be

02 ton"

aa

‘Whe on extra

Cadence

| |

}

eres dictabie | eventsinto

erica cement

be Seecestul ‘transtormations

—

KP Successful transformations depend onthe beaderthip being treined fret.

= 99 Thought organizer 1, Cadence transforms

unpredictable events into

2.wr

le Uke“en

3. Successful transformations depend on the leadership

belng trelned tiret.

4.Tooling is « critical element

extra O2 tank"!

SCALED

Notes

AGILE”

©@Scalec Aaile, Inc

1.8

|

5

| © SCALED AGILE, INC.

lesson #1 Applying SAFe in the Lean Enterprise Learning objectives: 1.1 Recognize the problem to be solved

1.2 Explore SAFe foundations

SAFe® Course: Attending this course gives students access to the SAFe Product Owner / Product Manager exam and related preparation materials.

6

| ©SCALED AGILE, INC.

1.1 Recognize the problem to be solved

We thought we’d be developing like this.

SCALED AGILE® © s=!: Asie 0 Notes

we

|

But sometimes it feels like this.

| Notes

SCALED AGILE®

@ See: Asie. io

|

7

| ©SCALED AGILE, INC.

1.1 Recognize the problem to be solved

». —

» Atyour table, review the following slide (also shown in your workbook on page 8) » In your workbook, mark the problems you recognize in your organization that you would like to solve

|

» Add other issues you have to the empty sticky notes » Discuss common problems at your table

SCALED AGILE™

PREPARE | SHARE

on

© scatec Agile. inc

Late

|

U

improve ™ systematically

Problems

OO Too early

visibility

| ~~commitment

discovered

| to a design

too late

that didn’t work

--——— ]

———~ Massive

O

eRe

dependencies

delivery

-T]

Too little ne WELAL

estimated

a

LO

g

|

|

Phase gate SDLC isn't

eo | eee

paade

reduce ris

al neibuted

———

eams

8

| ©SCALEDAGILE, INC.

O Poor morale

1.1 Recognize the problem to be solved

|

Knowledge for people building the world's most important systems

SAFe? is a freely revealed knowledge base of integrated, proven patterns for enterprise Lean-Agile development.

€ scaledagileframework.com

SCALED AGILE®

© Seaiec Agile. in

1.16

Notes

The Scaled Agile Framework® (SAFe*) Synchronizes alignment, collaboration, and delivery for large numbers of teams.

Core Values

1. Built-In Quality 2. Program execution 3. Alignment 4. Transparency

|

Notes

SCALED

AGILE”

© Scaled Auile, inc

1.17

|

9

| ©SCALED AGILE, INC.

1.2 Explore SAFe Foundations

Essential SAFe provides the basis for success

>

Continuous Delivery Biesling

—————

4 e@ 2

é@

System apa

Product Mgmt

|

Business

S

@ :

PROGRAM

Customer MA

-

Solution

Owners a5.

(one)

Vision

ae

e

eA

A

a

|

ee

RTE

DevOps = [=|

5=

Continuous Integration

Release on Demand

+ Culture * Automation

Pl Objectives

3

@

System Demos

+ Lean Flow

Q

hess

+ Measurement

bad

+ Recovery

NERS

Backlog

a‘a

J

|Feature | 2 |Feature |

1

ahs Le Dev Team

Sw EW

fb

XP

= Plan

v

+

Product Owner

—

Scrum

Scrum aeccee

Execute

* Review

Ss

a

=

is ha

—_* Retro

at See

‘oy

NFRS

E D pe On Oe

=

D

harPE

hs

Backlog

f

_ SCALED AGILE

7

COR €

Z

Core ~

a

ve

iS)

am = me

—

i

Kerations )

=) Architectural

.

oo €

fool

a

=

Lean UX

Notes

Continuous Deployment

caro

|

—_|—

e

Continuous Exploration

ie

53

[>| E 16) 19) =

iD)

2 LO Me pe[>| - (25Oye a

Runway

=

TEAM

=

1s

|p| — £

KS ye

[>| e 3

z &

Se

) = = —_Built-In Quality

Develop on Cadence

ALean-Agile

‘AMM Leaders — a Values 2s © Mindset

z = Laislos

=

a)

Principles CLL,

Z implementation

Roadmap

45

fase =

Leffingwell, et al © 2008-2017 Scaled Agile. Inc.

ae 5PC

© Scaled Agile, Inc

1.19

|

Nothing beats an Agile Team > Cross-functional, self-organizing entities that can define, build and test a thing of value > Applies basic scientific practice: Plan—Do—Check—Adjust

> Delivers value every two weeks

Team 1

tT PDCA Team

|

Notes

Adjust

,

| | SCALED

AGILE”

y Check —

@Scalca Aaile, inc

|

10

| ©SCALEDAGILE,

INC.

1.2 Explore SAFe Foundations

That integrates frequently Integration points control product development. — Dantar Oosterwal, :

The Lean Machine System Team

;

» Avoid physical branching

sel io

for software » Frequently hardware

b

oe

fue

, integrate

Check out most

branches

current

Use development by

a

functionality

."

Full system integration at least

System

once per iteration

demo

system

é

Check newest changes back in

Check i Soe tl

\

intention in for inter-team

dependencies

y a!

=

cn alan program velocity

Sada oo ™ he Agile Team 2

SCALED AGILE® Notes

©s=2 AoW |

|

Applies test automation Test automation supports rapid regression testing. .

:

> Implemented in the same Iteration » Maintained under version control

eet 4 v

Test 2

v Test3

Y

Test3

©e lest Test 45

Y

Test4 pigs

i"

» Passing vs. not-yet-passing and

P

:

broken automated tests are the rea/

=

5

Iteration progress indicator

a

SCALED AGILE™ Notes

f Test @ Test 2

©seaice Axe

|

11

| © SCALED AGILE, INC.

Except a team of Agile Teams » Align 50-125 practitioners to a common mission » Apply cadence and synchronization, Program Increments every 8-12 weeks > Provide Vision, Roadmap, architectural guidance Continuous Delivery Pipeline

baineed

os

Fame

ae

9

a

AG

P~D | P™D| P™D! P7D/) P70) p=p| t a8t s8t 38t 18 4 i pa

=

ASCE

SCALED AGILE™

ACR

ATC

aC

P7™D BA ot

1

© Scales Aaile. In

Notes

With some Architectural Runway Architectural Runway—existing code, hardware components, etc. that technically enable near-term business features. > Enablers build up the runway >» Features consume it

> Architectural Runway must be continuously maintained >» Enablers extend the runway

Implemented now ... Enabler

... to support future features

biggie

| |

Notes

Architectural Runway SCALED

AGILE”

@ Scaled Aaile, inc

1.24

|

12

| ©SCALED AGILE, INC.

1.2 Explore SAFe Foundations

Bringing together the necessary people

Business

Product

Arch/

Mgmt

Sys Eng.

Program

Hardware

Software

Testing

Deployment

Perr

Oy

(ees

5

=a 3

woe 26

All stakeholders face-to-face (but typically multiple locations) » Management sets the mission, with minimum possible constraints »

Requirements and design emerge

»

Important stakeholder decisions are accelerated

» Teams create—and take responsibility for—plans

SCALED AGILE® © Scsies Aan

1.26

Notes

13

| © SCALED AGILE,

INC.

1.2 Explore SAFe Foundations

Demonstrates the full system every two weeks > An integrated solution demo

» Objective milestone » Demo from the staging environment, or the nearest proxy

SCALED AGILE™

Notes

|

©scelec Asie, inc

1.27

|

Continuously delivers value to customers with DevOps Release on Demand i

@

@

e-

@

” eit “. seeis-aiefoeleiaee

=

Continuous

's

7g

Exploration

;

A

%

GENIC AEera via emsiete maa ‘

Culture

pg

Continuous

‘

Integration

j

of shared

@

if

responsiblity

WJ j

Recovery

Automation

enables low risk releases

of Continuous Delivery Pipeline

x

b BORG ary

esi . A

“it

tynce ah tee Owns pricing, licensing, and ROI

> Accepts Iteration increments

» Collaborates on Enablers

» Includes refactors and

» Contribute to intentional architecture, one owns

emergent

design

> ane ee eae implementation

and

of value

SCALED

redesigns in backlog

AGILE® © scaled aaite, |

Notes

25

| ©SCALEDAGILE,

INC.

> Integrate with other teams

2.1 Connect the Product Owner and Product Manager Roles

In pairs, create a 140-character description about the relationship between the Product Owner and Product Manager. » Discuss the relationship between the roles of the Product Owner and Product Manager > Be prepared to share your potential tweet

PREPARE

SCALED AGILE® ©seaicc Asie nc

| SHARE

29

4 “A

SS

Thought organizer

Create your 140 character description here:

26

| ©SCALED AGILE, INC.

2.1 Connect the Product Owner and Product eee! |

:

eae

| Product Onnere

Bee

2 es

Roles

.

erode Moreners and distributed teams

Product Owners and Product Managers can be located in the primary location, creating additional responsibilities.

Guiding team

Remote/outsourced team

Local, product, and technology ownership

na

& ——

Product

Product Owner

Management

(requirements analyst)

=}

2

System

Oe Release Train

=iTe]TA -1-| SCALED AGILE*

| eee’

P roduct Owner or proxy

Ss

ES

Team

;

ystem Architect or

es)

proxy

llRERIRNEEEeEee

|I|

ae Scrum Master

© Scaled Agile, inc

2.10

Notes

Other ART roles &

Release Train Engineer acts as the Chief Scrum Master for the train.

as

Product Management owns, defines, and prioritizes the program backlog.

RA

System Architect-Engineering provides architectural guidance and technical enablement to the teams on the train.

@ |

The System Team provides processes and tools to integrate and evaluate assets early and often.

ke 6 Business Owners are the key stakeholders on the ‘7 ia Agile Release Train. |

Notes

SCALED AGILEZ

@scaied Aaile, inc

244

|

27

| © SCALED AGILE, INC.

2.1 Connect the Product Owner and Product Manager Roles

» Are your Product Owners and Product Managers effectively communicating? — What is going well? ~ What is going not so well?

> Be prepared to discuss PREPARE

| SHARE

® ® RP

SCALED

AGILE

*

6 Scaled Agile,

Inc.

Are your Product Owner and Product Managers effectively communicating?

What is going well?

What is NOT going well?

28

| ©SCALED AGILE, INC.

2.2 Embrace aa San AUNMindset

|

Embrace Hoan Adie values House of Lean

i

| |

i

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

@ || =o =F

ees

~

|

= Bi] i

Agile Manifesto

:

Oi}

Bade

fried

o

|g a | oe

|

|| © [e) a)

|

||

a} |

es,

iS

esa]

B2 | =

aad

@

bos

e

9g |}

~

a

.

.

Individuals and interactions over processes and tools

;

Working software over comprehensive documentation

&

—_

Customer collaboration over contract negotiation

LEADERSHIP

Responding to change over following a plan

Value in the shortest

That is, while there is value in the items on the right, we value the items on the left more.

sustainable lead time

SCALED AGILE

© Scaled Agite, inc

214

Rall Manifesto x 1.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2.

Welcome er requirements, even late in development. Agile processes harness change for the customer's potnpeunye Auvarilage:

3.

Deliver ardna: software frequently, from a epeeof weeks to a nee of months, with a LPIPIBT OnE? for the shorter timescale.

*

Business enpiat and adevsloneranmust Work fonattise dally hronchett 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 eitigent and effective Teton aeconveying Ftoqnation to and within a devolonment team is face-to-face conversation. &

SCALED AGILE® ©s=le¢ Ale.nc

agilemanifesto.org/principles.html

2.15

Notes

29

| ©SCALED AGILE,

INC.

2.2 Embrace a Lean-Agile Mindset

©

Agile Manifesto 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.

RR agilemanifesto.org/principles.html

SCALED AGILE™

216

©Scisc Aaite |

Notes

30

| ©SCALED AGILE, INC.

2.2 Embrace a Lean-Agile Mindset

_ Exercise: Countdown 3, 2, 1! acy

ae

: i

~—.

aS

ROS Mies

Be

» Discuss the three most important Agile Manifesto principles to the PO and PM roles, write them on a flip chart or whiteboard

» On the index card, write down two other Agile Manifesto Principles that you find important to practice for success in your organization > Share the one Agile Manifesto Principle that will help you the most right now back in your organization, explain why PREPARE

SCALED AGILE®

© sae: Aa inc

3

!

7

AOE Thought organizer

31

| ©SCALEDAGILE, INC.

| SHARE

ee

2.2 Embrace a Lean-Agile Mindset

SAFe Lean-Agile 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

SCALED AGILE%

© Scales Aaite, inc

Notes

SAFe Lean-Agile Principles detail #1

#2

#3

Take an

Apply Systems Thinking

Assume variability;

Systems thinking takes a holistic approach to solution development; one that incorporates design, development, deployment, and maintenance of the system itself.

Variability is not inherently bad or good. Rather, it is the economics associated with the timing and type of variability that determines the outcomes.

Economic View If the solution doesn’t meet the customer’s or systems builder's economic goals, then the long-term viability of the solution is suspect.

SCALED AGILE”

©Scaied Aaile, inc

32

| ©SCALED AGILE, INC.

preserve options

2.2 Embrace a Scene nals. Mindset

| SAFe Weer

Principlesdetail (cont.

#4

#5

#6

Build incrementally with fast, integrated learning cycles

Base milestones on objective evaluation of working systems

Visualize and limit

Cadence-based integration points become the primary focus of the systems builder via a development process and a solution architecture that is designed in part for that specific purpose.

The system can be measured and assessed, and evaluated by the relevant stakeholders frequently, and throughout the solution development life cycle.

WIP, reduce batch sizes, and manage

queue lengths To achieve the sustainably shortest lead time, Lean systems builders strive to achieve a state of continuous flow, whereby new system capabilities move quickly from concept to cash.

SCALED AGILE?

SAFe Nespeeris PrnenleacdetailCont ) #/

#8

#9

Apply cadence, synchronize with cross-domain planning

Unlock the intrinsic

Decentralize decision-making

Cadence makes routine that which can be routine, so the intellectual capacity of knowledge workers can be devoted to managing the variable parameters.

motivation of

knowledge workers Lean-Agile Leaders operate within a relatively new, fundamental truth— the “management” of knowledge workers is an oxymoron.

SCALED AGILE™ ©seaics Asie. nc Notes

|

33

| © SCALED AGILE, INC.

Decentralized decisionmaking reduces delays, improves product development flow and throughput, and enables faster feedback and more innovative solutions.

2.2 Embrace a Lean-Agile Mindset

In groups, learn about three SAFe Principles together, and then teach it back. 7

#41-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

Risse

#9-Decentralize decision-making

©

|

eke

|

on SCALED

AGILE™

© Scales Agile. inc

See article on next page >>>

SS

Thought organizer

34

| ©SCALED AGILE, INC.

|

2.2 Embrace a Lean-Agile Mindset

Why the Focus on Principles? SAFe’s goal is to synthesize some of this body of knowledge and the lessons learned from hundreds of deployments into a single framework—a system of integrated, proven practices that has been demonstrated to bring substantial improvements in employee engagement, time to market, solution quality, and team productivity. SAFe’s practices are grounded on nine fundamental principles that have evolved from Agile principles and methods, Lean product development, systems thinking, and observation of successful enterprises. Each principle is described in detail in an article of that name. In addition, the embodiment of the principles appears throughout the framework. As a further aid to understanding, they are summarized below. #1 - Take an economic view Achieving the best value and quality to people and society in the sustainably shortest lead time requires a fundamental understanding of the economics of the system builder’s mission. Lean systems builders endeavor to make sure that every day decisions are made in a proper economic context. The

primary aspects include developing and communicating the strategy for incremental value delivery, and the creation of the value stream economic framework, which defines the tradeoffs between risk, cost of delay, operational and development costs, and supports decentralized decision-making. #2- Apply systems thinking

Deming, one of the world’s foremost systems thinkers, constantly focused on the larger view of problems and challenges faced by people building and deploying systems of all types—manufacturing systems, social systems, management systems, even government systems. One central conclusion was the understating that the problems faced in the workplace were a result of a series of complex interactions that occurred within the systems the workers used to do their work. In other words, it’s a system problem not a people problem, and that requires systems thinking. This principle describes how systems thinking can be applied to the system you are building, the organization that builds the system, and to the entire value stream that produces the system. #3 —- Assume variability; preserve options

Traditional design and lifecycle practices drive picking a single requirements and design option early in the development process (early in the “cone of uncertainty). However, if the starting point is wrong, then future adjustments take too long and can lead to a suboptimal long-term design. Alternatively, lean systems developers maintain multiple requirements and design options for a longer period in the development cycle. Empirical data is then used to narrow focus, resulting in a design that creates better economic

outcomes.

#4 — Build incrementally with fast, integrated learning cycles

Lean systems builders build solutions incrementally in a series of short iterations. Each iteration results in an integrated increment of a working system. Subsequent iterations build upon the previous ones. Increments provide the opportunity for fast customer feedback and risk mitigation, and also serve as minimum viable solutions or prototypes for market testing and validation.

35

| ©SCALEDAGILE,

INC.

2.2 Embrace a Lean-Agile Mindset In addition these early, fast feedback points allow the systems builder to “pivot” where necessary to an alternate course of action

#5 — Base milestones on objective evaluation of working systems

Builders and customers have a shared responsibility to assure that investment in new solutions will deliver economic benefit. The sequential, phase-gate development model was designed to meet this challenge, but experience has shown that it does not mitigate risk as intended. In Lean-Agile development, each integration point provides an opportunity to evaluate the solution, frequently and throughout the development life cycle. This objective evaluation provides the financial, technical and fitness-for-purpose governance needed to assure that a continuing investment will produce a commensurate

return.

#6 — Visualize and limit WIP, reduce batch sizes, and manage queue lengths

Lean systems builders strive to achieve a state of continuous flow, whereby new system capabilities move quickly and visibly from concept to cash. Three primary keys to implementing flow are to: 1. Visualize and limit the amount of work-in-process so as to limit demand to actual capacity, 2. Reduce the batch sizes of work items to facilitate reliable flow through the system, and 3. Manage queue lengths so as to reduce the wait times for new capabilities. #7 — Apply cadence, synchronize with cross-domain planning

Cadence transforms unpredictable events into predictable ones, and provides a rhythm for development. Synchronization causes multiple perspectives to be understood, resolved and integrated at the same time. Applying development cadence and synchronization, coupled with periodic cross-domain planning, provides Lean systems builders with the tools they need to operate effectively in the presence of product development uncertainty. #8 — Unlock the intrinsic motivation of knowledge workers

Lean-Agile leaders understand that ideation, innovation, and engagement of knowledge workers can't generally be motivated by, incentive compensation, as individual MBOs (Management by Objectives), cause internal competition and destruction of the cooperation necessary to achieve the larger system aim. Providing autonomy, mission and purpose, and minimizing constraints, leads to higher levels of employee engagement, and results in better outcomes for customers and the enterprise. #9 — Decentralize decision-making

Achieving fast value delivery requires fast, decentralized decision-making, as any decision escalated introduces delay. In addition, escalation can lead to lower fidelity decisions, due to the lack of local context, plus changes in fact patterns that occur during the wait time. Decentralized decision-making reduces delays, improves product development flow and enables faster feedback and more innovative solutions. However, some decisions are strategic, global in nature, and have economies of scale sufficient enough to warrant centralize decision-making. Since both types of decisions occur, the creation of an effective decision-making framework is a critical step in ensuring fast flow of value.

36

| ©SCALED AGILE, INC.

2.2 Embrace a Lean-Agile Mindset

_. Exercise: Focus on #9 -

Centralize decisions that have economies of scale, decentralize all others. Use this

game to learn how to decentralize. |

> Delivers value in the shortest sustainable lead time

>» Reduces delays

> Improves product development flow and throughput > Enables faster feedback and more innovative solutions

See Appendix B for Delegation Poker cards you can cut out and use 1%

3

Tell

CSTR

6 88 es

> Increases empowerment

|

Me

Sell

Consult

Agree

PREPARE | SHARE

Source: https://management30.com/product/delegation-poker/

SCALED AGILE™

© s Work with stakeholders and subject matter experts to define the Epic and its hypothesis statement, establish the cost of delay, and identify business sponsors » Work with development teams to size the Epic and provide input for economic prioritization » Define Epic outcomes hypothesis and MVP

» Guide the Epics through the Portfolio Kanban system and create the Lean Business Case > Present the Epic, including the business case, to the LPM for go/no-go decision SCALED AGILE® ©5:iec Avi Notes

The collaborative nature of the Epic Owner role , &@

Lean Portfolio Management pays Synchronize

business priorities

&

€

(/@a

Owner of a

Business Epic

Product Management

Split epics prioritize features Synchronize functionality with architectural runway

x4

Provide guidance for planning and execution by ARTs

RTE

& Owner of an ea Enabler Epic Coordinate research activities

SCALED AGILE®

©@Scalec Agile, inc

3.17

Notes

49

| ©SCALED AGILE, INC.

3.2 Detail the role of the Epic Owner

» With your group, use a white board or flip chart to identify your key collaborators

Solution Architect

Lean Portfolio

POag Oo»ck as CS

» Using the previous slides on pages 47-49 in your

workbook as a guide, identify key roles that need

to collaborate with the Epic Owner

ae

>>

N

|

4

-©)- Thought organizer

50

| ©SCALEDAGILE, INC.

3.2 Detail the role of the Epic Owner Draw your Mind Map here:

51

| © SCALED AGILE, INC.

3.2 Detail the role of the Epic Owner

Foster innovation with the Lean Startup Cycle Big-Up-Front Design (BUFD), along with big-up-front financial commitment, is a poor way to foster innovation. ---------~ Lean Startup Cycle -------------------: waa

EE faa we

|Epic | meme

| Bilid MVP

sa

Dues

wax

Stop Work

Pivot

zzz Approved Lean business

Besewene

case and hypothesis

|

¥ Implement additional Features

t

_

Auto-complete

|

Continue until

Local features and other epic Inputs ===> |mamas

EE

Germann,

WSJF determines otherwise

E

——— ® Scaled Agile, Inc

SCALED AGILE™

© Seslec Aatte. inc

What’s your collaboration model?

How you would engage your stakeholders?

52

| ©SCALEDAGILE, INC.

3.3 Use Lean Startup Cycles to foster innovation

__

Foster innovation with the Lean Startup Cycle Big-Up-Front Design (BUFD), along with big-up-front financial commitment, is a poor way to foster innovation. rinse

Ea

EE

fem

cnerecente erent me nse Lean Startup Cycle -------------------,

|Epic

>

Build MVP

*

Brouate

>

Be

Stop Work

Pivot Approved Lean business

Perseyere

case and hypothesis Implement additional Features

Auto-complete Continue until

Local features and other epic Inputs ==>

WSJF determines eee

SCALED AGILE® © s

Build MVP

——>

Arad

— |mums EER

Auto-complete Continue until

WSJF determines otherwise

© Scaled Agile, Inc

SCALED AGILE® © 5eiec Asie. ne

3.22

Notes

53

| © SCALED AGILE, INC.

3.3 Use Lean Startup Cycles to foster innovation

» Compare the Lean Startup Cycle with your current Epic process =»

In your workbook, detail the patterns and habits that may need to change in your enterprise

7

> Share the one pattern or habit that you would propose changing first

© ®

|

PREPARE

SCALED

AGILE™

©

3.23

Scale Aaiie, inc

Detail the patterns and habits that may need to change in your enterprise:

a

| SHARE

a

a

54

| ©SCALED AGILE, INC.

3.4 Develop Epic hypothesis statements

| Epic Hypothesis Statement example template |

|

Epic Hypothesis Statement For our community of banking consumers, who often login to our site through multiple devices or partner web sites, the Single Sign On Epic is amechanism for the consumer that allows a secure login through partner websites and mobile devices and provides seamless integration through our valuable partner network. Unlike our competitors who redirect consumers to their site for separate logins, our single sign on experience will provide an integrated solution for our customers that will allow a unified banking experience.

Outcomes

Consumers will use single sign-on through our top three partner browser and mobile app

capabilities

hypothesis: Leading

Multiple device access per user account increases, patterns of top devices become visible,

indicators:

separate login per account decreases. Baseline created

NFRs:

No more than 2 seconds latency, tested with all current SSO protocols

SCALED AGILE

Notes

©scalec Agile, inc

3.25

|

__NFRs are key architecture concerns Nonfunctional Requirements (NFRs) are system qualities that support end-user functionality and system goals.

NFRs » Nonfunctional requirements are associated with backlogs at all four configurations of SAFe » Sometimes known as the “ilities’— reliability, usability, scalability, maintainability, etc. > You may need to create backlog items to implement or evolve an NFR

|

SCALED

AGILE”

©

Scales Anite. inc

Notes

55

| © SCALED AGILE, INC.

3.4 Develop Epic hypothesis statements

NFR types Accessibility

Documentation

Operability

Audit and Control

Disaster Recovery

Performance

Availability

Efficiency

Reliability

Backup

Environmental Protection

Response Time

Capacity, Current and Forecast

Escrow

Robustness

Certification

Extensibility

Safety

Compliance

Failure Management

Scalability

Config. Management

Fault Tolerance

Supportability

Dependency on Third Party

Interoperability

Testability

Deployment

Maintainability

Usability Source: Wikipedia

SCALED AGILE™

Notes

56

| ©SCALED AGILE, INC.

3.4 Develop Epic hypothesis statements

> In your context, think about something that is of truly Epic nature, a large

itt SG eerie the

project, with possible multiple ARTs .

.

.

isa

Unlike

>» Share a statement with the class

SCALED AGILE~

Outcomes hypothesis:

Leading indicators:

57

| ©SCALED AGILE, INC.

ta proven isvoice

.

>» Articulate the Epic using the Epic Hypothesis Statement format

|

our solution

ee? rasroee



Preliminary data sheet

> Rolling-wave briefings

|

| > Draft press release on

SCALED AGILE®

Notes

©sczlec Aaite, inc

—_

—

|

| 4

49

|

75

| ©SCALED AGILE, INC.

||

4.2 Synthesize information for the Vision and Roadmap

;

5 2

© CEA

Bz

—

© CIE

EZ

8 8

—

© CRA

Solution

Saline

Strategic

Context

Intent

Ee

NFRs

Themes

|

@ 2 @

Architects, , S system

ftiipae Team, Other ©

i

6A

G

Customer feedback

aa

|

Solution/Product

4 Program ~

Management

Vision

;

a I I Team inputs

Oy)

ae Agile

@

V|

Product Owner

Teams

4.10

SCALED AGILE™ ©: ale. Notes

|

The Vision inspires action It provides a longer-term context: > How will our future Solution solve the larger Customer problems? >» How will it differentiate us?

» What is the future context in which our Solutions will

~ Aspirational, yet realistic and achievable

operate?

- Motivational enough to engage

A

;

>» What is our current business context, and how must we evolve to meet this future state?

others on the journey Result: The teams start thinking about how to apply their strengths in

For a fun John Deere Vision video,

order to get there

see http://tinyurl.com/p5ulocS

Switch: How to Change Things When Change Is Hard, Chip Heath and Dan Heath, Broadway Books, 2010

ae |

Notes

SCALED AGILE”

©Scaled Aaile, Inc

|

76

| ©SCALED AGILE, INC.

4.2 Synthesize information for the Vision and Roadmap

> In your group, pick one product or service that is currently being developed

|

> Imagine you are the customer. You have just received the product or service and are excited about using it! > As the customer, write a postcard to the team describing:

~ What Features you like and why they are important to you — The quality of the product or service PREPARE | SHARE

» Share your postcard during a ‘gallery walk’

SCALED AGILE®

© scatec Agile, inc

Exercise continues on next page >>

What Features you like and why they are important to you:

77

| ©SCALEDAGILE, INC.

/ ©)

YS

4.2 Synthesize information for the Vision and Roadmap

Describe the quality of the product or service:

78

| ©SCALED AGILE, INC.

4.2 Synthesize information for the Vision and Roadmap

The SAFe Roadmap and its attributes » Often derived from the Vision > Created by the Product Manager » Exists on the Spanning Palette in the SAFe Big Picture — and so can exist at all levels of the framework

» General plan of when Business and Enabler Features will be delivered over the next 3 Pls

» Only the first Pl is committed; the others are a forecast which will be adjusted based on the learning from initial P|

SCALED AGILE®

©scaiec Agite, |

4.13

Notes

Example Program Increment Roadmap The Roadmap guides the delivery of Features over time.

@ v1.0 May

E3 Expo (7/23) July

@

PI3 »

Road Rage ported (part I) i

> Brickyard port started >

Distributed platform demo

»

ALL GUls for both games demoable

»

Multiuser architecture

»

New Road Rage Features (see objectives for details)

+

New Brickyard Features (see objectives for details)

©

we v2.0 Sep

@

} 5 /18

PI4

PI5

> E3 Expo Tradeshow!

» Road Rage (multiuser) first |

» Road Rage completed (single

ea

user) >

» Brickyard ported multiuser demo

Brickyard Ported (single user)

»

§

She

New Features for both games

(see backlog)

» Road Rage multiuser d

@

trabl ES fd

» First multiuser game Feature for Road Rage

— Stretch Objectives — »

Demo of Beemer game

Commuted

Forecast [SS

SCALED AGILE® ©5302 Aaie.ve Notes

79

| ©SCALEDAGILE,

INC.

eee

4.14

Vision and Roadmap

4.2 Synthesize information f

> At your table, use the template in your workbook to create a Roadmap of Features based on the Epic you previously created: ff

—

Pullin MVP Features

—

Identify additional Features from local context

|k

— Arrange them in the Roadmap

>» Discuss how you will communicate your Roadmap to your customers and

stakeholders » Explore this question: Are Features always derived from Epics?

PREPARE | SHARE |

» Be prepared to share your Roadmap and communication plan

tia nc SCALED AGILE® i © sexi Aste. :

=

“=

See

| i

Committed

Forecast

How will you communicate your Roadmap to your customers and stakeholders?

Are Features always derived from Epics?

Neen

een eee een eee

eee

eee

ee

eee

eee

eee

80

| ©SCALEDAGILE, INC.

4.15

i

4.3 Visualize Feature and Enabler flow using a Program Kanban

‘ Analyzing

Funnel

SCALED AGILE” Notes

: ; : Implementing

Backlog

Validatingon Staging

: :

Deploying to Production

ee: Aoie

4.47

|

Continuous Delivery Pipeline Learning Cycle

Continuous Delivery Pipeline

LEER: vv.

SR.

EEE

p

en

iy

*

.

e

“8

Ss

aeee

s

© *

je

-

’

;

ete

pin

nes

hy

Continuous

Continuous

Continuous

Release

Exploration

Integration

Deployment

on Demand © Scaled Agile, Inc

pr SCALED

AGILE

”

© Scaled Agile,

Inc

Notes

81

| ©SCALEDAGILE, INC.

4.3 Visualize Feature and Enabler flow using a Program Kanban

The Program Kanban facilitates flow through the Pipeline All big Benefit ideas are hypothesis and welcome acceptance here! criteria Calculate WSJF

WIP timitea

Analyzing

Features approved by Product Management Continuous Prioritization jing W!

USi9@

Features decomposed into stories

Features integrated and deployed to a staging environment

Teams define, build and test the solution

Features demoed in the system demo and approved by Product Management

WSYF

Backlog

Implementing

Validating on Staging

Features finish

Features

deployment testing

released to customers,

Featured deployed to a production environment sometimes toggled off

incrementally or all at once

Benefit hypothesis evaluated

Deploying to Production

5

Continuous Exploration

Continuous Integration

Continuous Deployment Relese on Demand

SCALED AGILE™

4.19

©Seiec*

Notes

82| © SCALED AGILE, INC.

4.3 Visualize Feature and Enabler flow using a Program Kanban

Program and Solution Kanban Article from the Scaled Agile Framework It is said that improvement is eternal and infinite. It should be the duty of those working with Kanban to keep improving it with creativity and resourcefulness without allowing it to become fixed at any stage. —Taichi Ohno

The Program and Solution Kanban systems are methods used to visualize and manage the flow of value from ideation to analysis, implementation, and release. They support the flow of features and capabilities through the full Continuous Delivery Pipeline of Continuous Exploration, Continuous Integration, Continuous Deployment, and Release on Demand. The Kanban systems allow Agile Release Trains (ARTs) and Solution Trains to manage capacity based on the Work in Process (WIP) limits of the different states of the process. This helps prevent the system from operating with large handoffs, and identifies bottlenecks and opportunities for improvement. It provides clear guidelines for the policies governing each state, as well as the criteria for moving to the next state. This combination of visualization, WIP limits, and policies fosters collaboration and effective decision-making, which facilitates a faster flow of value through the system.

Details Kanban systems visualize the flow of value through a value stream by showing the location of all work items moving through the system. Enhancing a pull mentality by using WIP limits and explicit policies, Kanbans are the primary mechanism to achieve SAFe Principle # 6, Visualize and limit WIP, reduce batch sizes, and manage queue length, as well as the Lean concept of “flow.” Program and Solution Kanban systems help teams:

¢

Increase visibility into existing and upcoming work, and better understand the flow of work.

¢

Ensure continuous refinement of new value definition and acceptance criteria.

e

Foster role collaboration across disciplines, functions, and levels.

¢

Instantiate economic decision-making by setting the priorities for the pull-based mechanism.

e

Establish connections between the Portfolio, solution train, and ARTs.

The Program Kanban The Program Kanban is used by the ART to facilitate the flow of features through the Continuous Delivery Pipeline. A typical program Kanban is illustrated in Figure 1. The policies applied to each state, and some example WIP limits, are highlighted.

83

| ©SCALEDAGLILE, INC.

4.3 Visualize Feature and Enabler flow using a Program Kanban

All big ideas are welcome

Benefit hypothesis and acceptance

criteria

Management

Calculate WSJF hse, WIP limited

Continuous prioritization using WSJF

Analyzing

Backlog

here!

Funnel

Features approved by Product

Nh

(o>)

;

Teams define, build and test the solution

eatured

i

Validatingon Staging

orallatonce

+:

Benefit hypothesis evaluated

: « Releasing

Deployingto Production

(o>)

oO

i

incrementally

deploye

to a production environment sometimes toggled off

| Features demoed in the system demo and approved by Product Management

: : Implementing

Features released to customers,

Features finish deployment testing Taenleved F

Features integrated and deployed toa staging environment

Features decomposed into stories

TTT

SUCCES HT CUES

Continuous Exploration

. E, wesc padgenetee

oe he

ie

|

Continuous Integration

ee Ee

daha

eee

hs :

IN

Continuous Deployment

Ts:

ee Aan Sear

:

"

ee p

Relese on Demand

Figure 1. A typical Program Kanban

Features originate in Continuous Exploration, and may begin locally or come from an upstream Kanban. Local content authority, Product Management and System Architects manage the Kanban. The following states describe Kanban feature flow: Funnel - All new features are welcome in the “Funnel.” They may include new functionality, or enhancement of the existing system functions, or Enabler features.

Analyzing - When capacity is freed up to analyze features, those that align with the Vision and support Strategic Themes are pulled into the “Analyzing” state for further exploration. This state requires refinement of the key attributes of a feature: the description, business benefit hypothesis, and acceptance criteria.

General sizing of features also occurs at this state, estimated in normalized Story points. The purpose is to support economic estimating and forecasting of value delivery over a longer period of time based on scope. Some features under analysis may require prototyping or other forms of exploration that involve Agile Teams. Typically, such exploration is included in the PI plan. The WIP limit at the analyzing state is based on overall availability of Product Management, other subject matter experts, and the capacity of

teams dedicated to exploration activities. Program Backlog — The highest-priority features that were sufficiently elaborated and approved by Product Management move to this state. Then they're prioritized with Weighted Shortest Job First (WSJF) relative to the rest of the backlog to await implementation.

84

| ©SCALED AGILE, INC.

4.3 Visualize Feature and Enabler flow using a Program Kanban Implementing - At every Program Increment (PI) boundary the ART pulls the top features from the program backlog and moves them into the Implementing state. Through the PI Planning process, these selected features get broken down into stories and subsequently implemented by teams during the PI.

Validating on Staging - At the end of every iteration, while the ART prepares for the System Demo, features that are ready for feedback get pulled into the validating-on-staging state. At this point they’re integrated with the rest of the system on a staging environment (or its closest proxy), tested, and presented for approval at the system demo to Product Management and other stakeholders. Approved features move to the ready part of this state, where they're prioritized again using WSJF to await deployment. Deploying to production - When capacity becomes available for deployment activities (or immediately in a fully-automated environment) the feature gets deployed to production. If it’s deployed but turned off (see Release on Demand for more details), then it moves to the ready part of the state to await release. Otherwise, it moves directly into the releasing step. To avoid the buildup of features that are deployed but not yet released, this state is WIP-limited.

Releasing - When there's sufficient value, market need, and opportunity, features are released to some or all of the customers. In addition, the benefit hypothesis is evaluated and this state moves to done. The evaluation, however, might spawn new features in the funnel state. The above Kanban is prototypical—a good starting point for most ARTs, as are the policies we've described. ARTs, however, can customize this system to fit their process, defining their own WIP limits based on the available capacity for the work, and their specific policies for movement from state to state.

Program Epic Kanban Some initiatives are too big to be completed in a single Program Increment. These are Program Epics, identified and managed in a separate Kanban system, as shown in Figure 2. The goal is to analyze and approve program epics, splitting them into features that will be further explored and implemented in the program Kanban. Depending on how frequently program epics occur in the local context of the ART, this Kanban system is not always used.

Funnel

Reviewing

Analyzing

To Program Kanban Funnel

Figure 2. A typical Program Epic Kanban

85

| ©SCALEDAGILE, INC.

4.3 Visualize Feature and Enabler flow using a Program Kanban For this Kanban system to succeed, it must engage a higher level of stakeholders to explore and approve program epics—typically those at the solution train or portfolio level. The flow generally mirrors the states in the Portfolio Kanban:

Funnel - All big initiatives are welcome in the Funnel state. There is no WIP limit.

Reviewing - This state allows the assigned analysts to perform initial exploration of epics and rank them roughly using WSJE to determine which ones should move on for deeper exploration. Again, WIP limits apply. Analyzing - At this diagnostic and exploration state, stakeholders are encouraged to:

«

Refine size and WSJF compared to other epics.

e

Consider solution alternatives.

«

Identify possible Minimum Viable Products (MVPs).

«

Determine the costs involved, technology and architectural enablement, infrastructure, CLC

Guided by analysis and insights, Business Owners (and typically Lean portfolio Management personnel) approve or reject the epics. Approved epics then get split into features and transitioned to the funnel of the program Kanban, where they will be prioritized based on WSJF against other features. WIP limits apply. Similar to portfolio epics, program epics may require Epic Owners to help with the definition, exploration, and implementation.

Managing the Program Kanban with the ART sync One significant ART event is the “ART sync meeting,’ which is attended by Scrum Masters and Product owners. During the ART sync, participants review the program Kanban system from right to left, pulling in more work based on the available capacity at each state. Participants, discuss new work, prioritize, schedule meet-after’s, and make deployment and release decisions as necessary. Further, the Program Board (see PI Planning) serves as a ‘zoom-in’ for the implementing state, allowing more in-depth discussion of dependencies and execution.

Solution Kanban The above describes the program Kanban in depth. For Large Solutions, the Solution Kanban generally repeats this structure. It operates with Capabilities instead of Features, however, and is managed by Solution Management and Solution Architects.

In addition, where useful, teams apply a Solution Epic Kanban section that parallels the Program Epic Kanban.

86

| ©SCALEDAGILE, INC.

4.3 Visualize Feature and Enabler flow using a Program Kanban

» Organize into groups of 2 to 4 people i.

» Choose one person's context and Features. Using the Kanban board in the workbook, fill in the initial WIP Limits in the circles

RTT

> Be prepared to present your thought process

|

PREPARE | SHARE

SCALED AGILEZ © Scaled Agile,

Inc

f

ee

.

—

——

Pa

Prioritize the Program Backlog using WSJF Portfolio Backlog

Program Backlog

Bez

|a |

i

=

ics

=o=

WSJF

= ae

=

Team's part of a Feature / Enabler

SCALED AGILE”

Notes

© Seiec Agile

4.22

inc

|

Non-economic-based prioritization Product Owners and Product Managers will often face non-economic-based prioritization. HiPPo — Highest-paid person makes the decision.

“The Senior VP said we should do this project.”

Anti-pattern

© ©

Squeaky Wheel — The person who yells the loudest or makes the biggest promise of revenue.

“Fund my project and we will make a billion dollars!”

© |

ROI — Making a decision based exclusively on an ROI metric (e.g., NPV, payback, etc.). Requires a sensitivity analysis to be relevant. “The NPV indicates we will make a 30% profit.”

SCALED AGILE” @seIe0 Aaile. nc Notes

4.23

|

88

| ©SCALEDAGILE, INC.

4.4 Prioritize the Program Backlog

Prioritize Features for optimal ROI esas

In a flow system, job sequencing by Product Owners and Product Managers are key to economic outcomes.

To prioritize based on Lean economics, you need to know two things:

1. What is the Cost of Delay (CoD) in delivering value? 2. What is the cost to implement the valuable thing?

a

oe

ee

=

ee

Sane

PenabierBi\

‘ es \mmmEs

[

a

|mm23

\.\NFRs =

If you only quantify one thing, quantify the cost of delay.

ae

|

Pa ee

/

ae

—Donald G. Reinertsen, Principles of Product Development Flow

SCALED AGILE™ © Scales Aaile, in

4.24

Notes

Example with equal Cost of Delay: Which job first? B $$, 3 days

ee $$, 10 days

POPOL Tie

SCALED AGILE?

Notes

Aen cor if

a

@5scalec Aaile, inc

425

|

89

| ©SCALED AGILE, INC.

4.4 Prioritize theoo oreny besoin

E

Evaninlee withRecrendduration: Which iobfirst? A.

388. Sea

i

$8,3 days

Ae =

SCALED AGILES

? Scaled Agile, Inc

4.26

Notes

General case: Any CoD and duration In the general case, give preference to jobs with shorter duration and higher CoD, using Weighted Shortest Job First (WSJF):

CoD

WSJF = Duration

A B

Cc

EA — Dark area: Total cost of delay Time

|

SCALED AGILE? l

Adapted from The Principles of Product Development Flow, Donald G. Reinertsen

calcd Acie nc --

-

90

| ©SCALED AGILE, INC.

=

—

4.27 ~

4.4 Prioritize the Program Backlog [ | |

Components of Cost of Delay

|

User and

Relative value to the customer or business

business value

» They prefer this over that > Revenue impact?

> Potential penalty or other negative impact?

Time criticality

How user/business value decays over time > Is there a fixed deadline?

> Will they wait for us or move to another solution? > What is the current effect on customer satisfaction? Risk reduction and

What else does this do for our business

opportunity enablement (RR & OE)

> Reduce the risk of this or future delivery? > Is there value in the information we will receive? » Enable new business opportunities?

Notes

Calculate WSJF with relative estimating > In order to calculate WSJF, teams need to estimate cost of delay and duration » For duration, use job size as a quick proxy for duration

» Relative estimating is a quick technique to estimate job size and relative value » WSJF stakeholders: Business Owners, Product Managers, Product Owners, System Architects

WSJF

=

CoD

__

User business value + Time criticality + RR |OE value

Job size

SCALED AGILE?

Notes

Job size

@scaies Agile, inc

4.29

|

91

| ©SCALEDAGILE, INC.

4.4 Prioritize the Program Backlog ibe

y,

Rae

» Select three Features from the “Create Features with benefits hypothesis” exercise and prioritize them using the WSJF template in your workbook

» Do one column at a time. Start by picking the smallest item and giving it a “1.” There must be at least one number “1” in each column of the template. > Be prepared to share your WSJF prioritization

PREPARE

| SHARE

SCALED AGILE® © sacs Asi. inc

Feature

4.30

User business value

Time criticality

+

+ +

+ a

+

= =

Fe

Scale for each parameter: 1, 2, 3, 5, 8, 13, 20 Note: Do one column at a time, start by picking the smallest item and giving it a “1.” There must be at least one “1” in each column!

—_ e hh ee

92

| ©SCALED AGILE, INC.

|

4.4 Prioritize the Program Backlog

Exercise: Duration discussion

—_

ae

ee

_ oe |

Le

te

As aclass, consider and discuss these three questions:

: so

1. Is job size always a good proxy for duration? 2. When might it NOT be the case?

3. How would you adjust duration based on that case?

SCALED AGILE®

@ scziec Agile. inc

4.31

Is job size always a good proxy for duration?

When might it NOT be the case?

How would you adjust duration based on that case?

a

93

| ©SCALED AGILE, INC.

es

a)

4.4 Prioritize the Program Backlog

Partner with System Architect/Engineering

|

» Support Enabler items that provide sufficient Architectural Runway » Work with System and Solution Architects/ Engineering to sequence technical infrastructures that will enable delivery of new business functionality

Implemented now...

... to support future Features

We

©Sscslec Asile, tn

SCALED AGILE®

Notes

How much architecture? Product Management collaborates with System Architects to build Architectural Runway. If we let the Architects have

If we let Product and Solution

their way, they'll re-architect

Management have their way,

this thing until hell freezes over, and then we'll all be out of a job

they'll make us band-aid this thing until hell freezes over, and then we'll all be out of a job

?

?

@

va

Ln

System and Solution

Product and Solution

Architect/Engineering Program Backlog

|Feature | |

SCALED AGILE”

a

Notes

©sesle< Asie nc

4.33

—

|

94

| ©SCALED AGILE,

INC.

4.5 Prioritize the Program Backlog

Define Features by type of service Types of service provide a way to separate concerns, such that we can deliver the right mix of new Features and architecture evolution. 1.

Determine how much service is to be allocated to each class

2.

Establish policies to determine how work is performed for each defined

class

Backlog

authority and prioritizes the work in that class.

Capacity allocation for this P|

eS

Avchitect (design authority), WSJF prioritization

@

to be devoted to new Feature development

vs. architecture at each boundary. 2. We agree that the architect has design

Program |)

Architecture policies 1. We agree on the percentage of resources

Ss

a New Features

VW

® Architecture

B4

3. We agree that content authority (Product peers rE Management) prioritizes work in that class.

4. We agree to jointly prioritize our work based on economics.

5. We agree to collaborate so as to sequence

Product Management

work in a way that maximizes Customer

(content authority)

value.

WSJF prioritization

SCALED AGILE™ ©se20 Aa\6 |

w |&

Notes

|

a 95

| ©SCALEDAGILE, INC.

4.4 Prioritize the Program Backlog

> Consider how you would use Capacity Allocation in your enterprise » In your workbook, draft a Capacity Allocation policy that you could bring back for discussion with your key collaborators > Share your policies with a person next to you

®@

PREPARE

SCALED AGILE™ © seaiee Asi nc

| SHARE

4.35

Capacity Allocation policy:

96

| ©SCALED AGILE, INC.

4.5 Estimate and forecast the backlog |

es

| |

—

.

——

SE

So4

ee

eee

Relative estimating Agile Teams use story points and relative estimating to quickly arrive at estimates for size and duration for user stories » Product Managers can use historical data to fairly quickly estimate the size of Features in story points as well > Feature estimates can then be rolled up into epic estimates in the portfolio backlog » Portfolio managers and other planners can use Capacity allocation to estimate how long a portfolio epic might take under various scenarios

SCALED AGILE™ © sei: Avie.

4.37

Notes

White Elephant sizing When you need to estimate a lot of Features fast: > Team members take turns putting Features under the size that they feel is appropriate or using their turn to move a Feature to a different estimate > When all Features are estimated, the team reviews the Feature sizes and

can make one final change

|

|8

|

Feature Feature _

Feature

Feature ” Feature |

Feature,

Feature

Feature , Feature,

Feature _

Feature Feature,

Feature Feature

Feature Feature ,

Feature_

Feature

Feature _

Feature _

Feature 7

SCALED AGILE™

Notes

|

© selec Asiie, inc

4.38

|

97

| ©SCALEDAGILE, INC.

|

4.5 Estimate and forecast the backlog

» Using the modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, 40, 100), build a sizing board so that your group can estimate a series of Features w

Choose 3 to 5 Features in your group, and each person writes the Features on a sticky note

|

> Team members take turns putting the Features under the size that they feel is appropriate or using their turn to move a Feature to a different estimate PREPARE

» When all Features are estimated, the team reviews the

f

Feature sizes and can make one final change aes

SS

=aaiacnnrr

—_—S

a

I “ 7

7

Thought organizer

98

NCI

| —

SCALED AGILE® ©saie< Asie.

N

| SHARE

| ©SCALED AGILE, INC.

a

a

arene

4.5 Estimate and forecast the backlog

|

Estimating Features effort Estimating the effort needed to implement a Feature typically goes through a series of successive refinements. & Product Manager

RA

PRELIMINARY (Relative) Size Estimate

A>B>C

Effort history data REFINED ; story points

é Cae & Pay

Peeks istorical Historical

ACTUAL

Bottom-up, team-based B =Y

story points

Estimate ——

$

Velocity

Aries;

mix

story point SCALED AGILE®

Notes

scaled Agile,

Cost

CO

estimate

estimate

|

©

Lf

™

f 6 & 2@ fetyae

2@

Ml a

Dev teams

$

Delivery history data

inc

4.40

|

Estimating cost Once the Feature has been estimated in story points, a cost estimate can be

quickly derived. > Calculate the burdened cost for a team in an Iteration length > Divide that by their P! velocity to get average cost per story point

Example: If a team has an average velocity of 40 points, and their cost is $40,000 per Iteration, then each story point costs ~$1,000

$

$

ART cost per story point SCALED AGILE”

Notes

___,

Cost

Delivery

estimate

estimate

© Seales Aaiee, inc

fu

Delivery history data 4.41

|

99

| ©SCALEDAGILE, INC.

4.5 Estimate and forecast the backlog

Using size to estimate duration Establish velocity by looking at the

average output of the last Iterations.

Velocity

Examples

miles

¢

Ss

hours

pn”

180 Story

points SCALED AGILE

Notes

examen

Sa)

ox RO

c—

©sciec Aaile.|

conmmasebign

6z

Iterations 4.42

|

The business needs to forecast » SAFe enhances enterprise adaptability, providing faster response to changing market opportunities » Yet, the enterprise, its partners, and customers need to plan some sense of the future

» Estimating must: — Be fast and efficient as possible to be reasonably accurate — Support “what if’ analysis of various implementation scenarios

> Traditional Work Breakdown Structure to task-level estimating binds the teams to waterfall practices

SCALED AGILE”

ae

© Scales Avie. Inc

100

| ©SCALED AGILE,

INC.

4.5 Estimate and forecast the backlog .

Estimating Epics in SAFe

|

1. Epics are broken down into potential Features during the Portfolio Kanban analysis stage 2. Potential Features are estimated in story points

he — Typically performed at the PM-System Architect level, é based on history and relative size

90

[

\ Feature

— Individual teams are engaged

120

as necessary

Feature

140

3. Feature estimates are aggregated back into the Epic estimate as part of the lightweight business case

SCALED AGILE®

© Scales Aaite, inc

4.44

Notes

101

| ©SCALED AGILE, INC.

4.5 Estimate and forecast the backlog Pees

ee

With your small group, look at the next slide (slide is also shown on page 102 in your workbook) and together, answer the following question: » ART 2 is capable of doing Epic 3 by themselves, but they can only dedicate half of their capacity to that initiative. In which PI would you reflect this Epic on the Roadmap?

6

PREPARE

SCALED AGILE™

|; SHARE

© Scie Aaite, inc

A5

ART 2 is capable of doing Epic 5 by themselves, but they can only dedicate half of their capacity to that initiative. In which PI would you reflect this Epic on the roadmap? (circle the Pl)

1

3200

fi

Bus. Epic

1

2300

f_

Ye

Bus. Epic

3

Enabler

Capacity allocation %

1000

F 5 6

3900 §

1200 pts/PI

Bus. Epic ff ;

Which trains can work on these,

3100

and what % of their capacity can be applied?

5000 Enabler

Bus. Epic

Portfolio Backlog

102

| ©SCALED AGILE, INC.

4.5 Estimate and forecast the backlog I

_

||

Forecasting from the Portfolio Backlog

| |

Given knowledge of Epic sizes and ART velocities, applying “what if’ capacity allocations informs decisions and forecasting. 3200

Capacity allocation %

Bus. Epic Ma

2300 Bus. Epic

3

1000 Enabler

ri

5

6

@D P

a

3900 Bus. Epic

Ee

1200 pts/PI

Which trains can work on these,

5000

and what % of

Enabler

their capacity can be applied?

3100 Bus. Epic

@ ART1

| | }

e@ ART2

Portfolio Backlog

ART3 SCALED AGILE™

Notes

© seaiec

>

4.46

|

Organizational readiness How can you effectively ensure organizational readiness? Ask yourself these questions! » Planning scope and context:

~ Is the scope (product, system, technology domain) of the planning process understood?

~ Do we know which teams need to plan together? > Business alignment: ~ Is there reasonable agreement on priorities among the

Business Owners? » Agile teams: — Do we have Agile Teams? ~— Does each have dedicated developer and test resources and an identified Scrum Master and Product Owner? SCALED AGILE® ©seaee Aaie inc Notes

447

|

103

| ©SCALED AGILE,

INC.

|

4.5 Estimate and forecast the backlog ———

The PM's responsibility is to enter PI Planning with a prioritized backlog. » What does a PM need to do to ensure org readiness and content readiness? » How could the PO support the PM in org readiness and content readiness?

PREPARE

SCALED AGILE

© scatec Aaile, inc

| SHARE

4.48

What does a PM need to do to ensure org readiness and content readiness?

How could the PO support the PM in org readiness and content readiness?

104

| ©SCALEDAGILE, INC.

Lesson summary

In this lesson, you: > Continuously explored customer needs » Synthesized information for the Vision and Roadmap

» Visualized Feature and Enabler flow using a Program Kanban

Prioritized the Program Backlog Estimated and forecasted the Backlog

Suggested Scaled Agile Framework reading: “Portfolio Backlog”, “Program and Solution Backlogs’, “Roadmap”, and “Features and Capabilities” articles

N

u

4

~©)- Thought organizer

ae 105

| ©SCALED AGILE, INC.

ee

Lesson #4

Key

Continuously explore

Learnings

Customer needs

:

& Insights

106

| ©SCALED AGILE, INC.

Lesson #5

Executing the Program Increment Learning objectives: 5.1 Create alignment with PI Planning 5.2 Decompose Features into Stories

5.3 Plan the Iteration 5.4 Execute the PI 5.5 Release on Demand

SAFe® Course: Attending this course gives students access to the SAFe Product Owner / Product Manager exam and related preparation materials.

107

| ©SCALEDAGILE,

INC.

5.1 Create alignment with PI Planning

Participate in PI planning

|

The Product Manager and Product Owners play key roles before, during, and after the PI Planning event.

Lod! nempyninti erp

|

ee

ee le ca

ot

a

a

Notes

Schroders PI Planning Event Kickoff https://vimeo.com/169066536 SCALED AGILEZ '*Sis: ol: FSF.

Notes

.-)

pS

See

|

108

| ©SCALED AGILE, INC.

a

|

5.1 Create alignment with PI Planning

,

| Inputs of PI Planning Inputs of PI Planning include:

> Business context

may otjectves

» Roadmap and Vision

Cc u \ n

> Top 10 Features from the single

ART Program Backlog

SCALED

Notes

AGILE™

©seiec

Pola

S

FEC

ce

6

=

z\-B &| a oe a|

ay

o

|

Successful PI Planning Outputs A successful PI planning event delivers two primary outputs: 1. Committed P!] Objectives (SMART)

Objectives for PI 1 Structured location and validation of locations

»

Build and demonstrate a proof of concept for context images

>

Implement negative triangulation by: tags, companies, and people Speed up indexing by 50% Index 1.2 B more web pages Extract and build URL abstracts

» » »

| |

| Notes

Business Value

»

Stretch Objectives for Pi 1 » Fuzzy search by full name » Improve tag quality to 80% relevance

SCALED

AGILE

”

Scaled Agile, inc

|

109

| ©SCALED AGILE,

INC.

"

|

=

Sees

cH

2. Program Board

Ip

~

=

|

=f

i|

|e 8

5.1 Create alignment with PI Planning

PI Planning preparation Prior to the PI Planning event, the PM should collaborate with POs to:

Create/update the Vision.

1 —

Prepare and estimate the top 10 Features list from the Program Backlog. Socialize the above artifacts with business, stakeholders, and architects to validate the Feature list and set

expectations for the PI Planning meeting. SCALED

AGILE”

©scalec Aaite, |

5.8

Notes

What POs and PMs do during PI Planning — Day 1 » Communicate:

we — Program Vision

DAY1

hat 9:00

— Present the top 10 Features

REE 10:30-

» Collaborate to decompose Features into Stories 4

Negotiate

scope

ae

» Review draft PI plans and provide feedback a

Notes

©@scalec Auite,inc

5:00-

°

yd

i 2 PrOduCUSoluton Vision [Meve

ee Vision and development practices

2

"ST

ae

Planning context

and junch

Team

breakouts

© 4:00-

f

> Participate in management review of draft PI plans

SCALED AGILE™

11:30 11:30 7 1:00

Business context

e

4

i

= Management reviewand

ha

Y

3

59

|

110

| ©SCALED AGILE,

INC.

5.1 Create alignment with PI Planning |

You

are here! Day 1 agenda

8:009:00

9:00-

j Business context

:

ES

ee

Y-

State of the business and upcoming objectives

10:30

Product/Solution Vision

O28)

Vision and prioritized Features

10:30-

Architecture Vision and

"7

> Architecture, common frameworks, etc.

11:30

development practices

iio

> Agile tooling, engineering practices, etc.

11:301:00

Planning context and lunch

a RE

1:004:00

Team breakouts Sos

We 3 4

rr é Facilitator explains planning process > Teams develop draft plans and identify risks and impediments » Break Features into Stories » Architects and Product Managers circulate

4:00-

me: : SCALED AGILE™

Draft

. plan revie

Teams present draft plans, risks, and : ,

ly

Management review and problem solving

Adjustments made based on challenges, risks, and impediments

© S» Where are the bottlenecks?

> What Features must be de-scoped? >» What decisions must we make between now and tomorrow to address these issues? Used with permission of Hybris Software

SCALED AGILE?

©@Scalec Aaile, inc

5.11

Notes

111

| © SCALEDAGILE, INC.

5.1 Create alignment with PI Planning

Think about the Management Review and Problem-Solving Workshop. » What activities are required for the PO? > What activities are required for the PM?

» Capture ideas and share with the class

PREPARE

SCALED AGILE™

© seaiec Agile.

inc

| SHARE

5.

What activities are required for the PO?

What activities are required for the PM?

112

| © SCALED AGILE,

INC.

9.1 Create alignment with PI Planning

| What POs and PMs do during PI Planning — Day 2 > Participate in final Pl plan review

DAY 2

» Establish business value with Business

a

Owners

a

fee

Team breakouts

» Accept Team Objectives

11:00-

“Final plan review

» Provide feedback on program risks

i.

=

A

2:00-

> Participate in confidence vote, rework

earn

(if applicable), and planning retrospective

areas

o

oe

34

After commitment

SCALED AGILE™

|

4

moving forward

©s=e< Avie. nc

5.13

Notes

Day 2 agenda Planning

8:00-

ie

adjust

ee 4

Planning

adjustments Tae!

made based on

day's management meeting

p previous

> Teams develop final plans and refine risks 9:00-

11:00

11:00-

Team breakouts

1:00-

ol i AU w fl us

1 2

Plan rework if necessa

22?

After commitment AGILE”

Teams present final plans, risks, and impediments

Remaining program-level risks are discussed and

PI confidence vote

2:15-

and impediments » Business Owners circulate and assign business value to team objectives

Bronte

j

2:002-15

Notes

=

and lunch

200

SCALED

3 4

Final plan review

1:00

|

12

3 4

Planning retrospective and moving forward

= 2 2

Team and program confidence vote

If necessary, ; planning continues until s

commitment is achieved

» Retrospective > Moving Forward > Final Instructions

© Scslce Aaite. inc

|

113.

| © SCALED AGILE, INC.

oe

|

|

5.1 Create alignment with PI Planning

Supporting the Team Objectives Based on new knowledge (and a good night’s sleep), teams work to create their final plans. > In the second team breakout, Business Owners circulate and assign business value to P| Objectives from low (1) to high (10)

> Teams finalize the Program Increment plan

Oe Ob ectives For PI41

» Teams also consolidate program risks, impediments, and dependencies » Stretch objectives provide the capacity and guard band needed to increase cadence-based delivery . “re reliability

~ Structured locations and

validation of locations ~ Build and demonstrate a proof of concept for context images - Implement negative triangulation by: tags, companies and people ~ Speed up indexing by 50% - Index 1.2 billion more web pages

~ Extract and bulld URL abstracts Seow sicchch Objector ee - Fuzzy search by full name

- Improve tag quality to 80% relevance

SCALED AGILE™ © Seaics agit

5.15

Notes

114

| © SCALED AGILE, INC.

5.1 Create alignment with PI Planning

» Read the Guidance Article on “The Role of P| Objectives” (page 116 in your workbook) |

|

and PMs will7 support the assignment of

/

Business Value

|

L

~ Build and demonstrate a proof of concept for context images

> In your workbook, reason about how the POs

= by: Implement negativetriangultio tags, companies andpeople

aay apaby50% eee

~-Speed up indexing

:

|

Teeblet eedee tS

> Be prepared to share your results

|

seee=Stretch Objectives >>

How the POs and PMs will support the assignment of Business Value?

————————— ee 11S

| © SCALED AGILE, INC.

5.1 Create alignment with PI Planning

The Role of PI Objectives Scaled Agile Framework Guidance Article by Eric Willeke, SAFe Program Consultant Trainer, Rally Software Introduction The role ofPIObjectives is often misunderstood by teams new to PI Planning. They struggle at first to understand the difference between Team PI objectives and Features. SAFe does not provide a lot of guidance on the intent behind the usage of PI Objectives and they are often misunderstood or misinterpreted. However, in my field practice I’ve come to really value them, so I wanted to take the time to document my perspective in this article. The main qualities of PI Objectives that I have come to value are their ability to:

¢

Validate understanding of intent

¢

Focus alignment on outcomes rather than process

«

Summarize data into meaningful and steerable information

¢

Without understanding the above qualities, it’s quite easy to view PI objectives as nothing more than a shorthand list of features to be delivered.

Validate Understanding of Intent Two of SAFe’s four core values are Program Execution and Alignment, and one of the key Lean principles underlying SAFe is decentralized decision-making. Most of the PI Planning event agenda is focused on supporting these values by conveying a clear understanding of the desired goals and outcomes for the agile release train, then getting out of the way and enabling practitioners to achieve these goals effectively. We place governing structures and other feedback loops into play through the product manager and product owner roles, but we generally support the teams’ ownership of the details in pursuit of the larger business outcomes. However, one of the key risks that has plagued every software development approach is ensuring that the initial intent (scope) was clearly understood and articulated by the stakeholder, transmitted effectively to the development team, and interpreted in the same way. In SAFe, this path also includes the extra steps of translating from the end users to the business owner (who requires this capability), then onward to the product manager (for the release train implementing the capability.) SAFe’s use of PI Objectives provides a unique tool to create an immediate feedback loop from the teams back to the business owners, allowing a quick validation of the teams’ grasp of the desired outcomes. In short, we give the teams the following challenge: “Can you concisely convey, in words the business owner understands, the essence ofthe value sought by implementing this set offeatures?” If a team cannot do this in a clear way by the end of planning, are we comfortable investing over $100,000 to pursue these goals over the next 10 weeks? By forcing the teams to summarize the intent and the outcomes they believe the business owner wants to achieve, we close the loop of understanding and drive crucial conversations that expose these misunderstandings.

116

| © SCALED AGILE, INC.

9.1 Create alignment with PI Planning This in turn enables a much tighter form of alignment that transcends the written language of the feature to be amplified by the tacit understanding gained between the team and the business owner. Focus on outcomes rather than process The second hidden value of PI Objectives is that they help the team shift focus off the feature language and onto the desired business outcomes. Features and acceptance criteria are amazing tools to help understand, capture, and collaborate around the work that needs to be done to iterate our solution to the next level, but it’s all too easy to get caught up in “finishing the features” and missing the overall goals hiding inside of them. The core question becomes:

“Is our goal to complete the listed features, or is our goal to provide the outcomes desired by those features? In other words, if we could provide the same value with half the amount of work, and without building all of the features, would this be acceptable?”

I've found that the language of features can frequently steer the team into overlooking creative, valid, and architecturally sound solutions because someone outside the team already provided a preconceived notion of how that value should be provided. The closer understanding of the intent offered by direct conversations with the business owner occasionally results in the teams offering new perspectives to the architects and product managers, and quickly finding ways to apply their expertise more effectively.

Summarize data into steerable information Finally, theres a simple “comprehension” aspect to PI Objectives that I find particularly valuable. ’'ve come to accept that no large group will reliably read every item in a list if that list exceeds 5-7 items. Given that I see small trains with only four teams consistently take on 10 features per PI, and large trains that have taken on as many as 40, I assume nobody except the product manager reads every single feature carefully—and certainly nobody outside the train has read every one. As a result, I deeply value the summary of intent that the Program PI Objectives provide, and the subsequent use of those objectives as a key for providing clear evidence of progress both within and beyond the train. I strongly encourage teams to fully and transparently share the features they intend to complete, and their progress against them in a percent of complete mindset. But I’ve also found it valuable to summarize the 5-7 key objectives per train and report on progress against those. This is especially true when you have four or more trains working against the same value stream, aggregating a shared system demo to a senior executive audience every two weeks. Quite simply, you need a more compact way to convey the same information to augment the quantitative reporting.

A bit of philosophy As I captured these thoughts I was reminded of a key difference between release trains, and it strongly impacts the degree of value placed on the “focus on outcomes,’ above. I tend to see release trains fall to one of two extremes: Either they drive the vast majority of their work (85-95%) through portfolio epics, and reduce the autonomy of the trains; or they drive the vast majority of their work as features, and reserve epics for the 5-10% of work that truly cuts across trains. While I don't view either of these approaches as fundamentally wrong, I do believe that we will see that a majority of companies solving the big “system of systems” engineering problems, encouraging a strongly epic-driven approach, will find that SAFe for Lean Software and Systems Engineering will be a more effective approach. At the same time, I fundamentally believe that the mindset of epic-driven development is serving the same role for steering at scale that “waterfalling iterations” served for teams: it provides a way for organizations to avoid learning those crucial lessons about how to work together in ways we never had to in the past. 117

| © SCALED AGILE,

INC.

5.1 Create alignment with PI Planning

:

Confidence vote: Team and Program Levels After dependencies are resolved and risks are addressed, a confidence

vote is taken at the Team and Program Levels. ‘Fist of five’ confidence vote A commitment with two parts:

>» Range of 1-5

1. Teams agree to do everything in their power to meet the agreed-to objectives

> 1 = No confidence > 5 = Very high confidence

2.In the event that fact patterns dictate that it is simply not achievable, teams agree to escalate immediately so that corrective action can be taken

SCALED AGILE™ ©see Aaie. Notes

118

| ©SCALEDAGILE,

INC.

5.1 Create alignment with PI Planning

119 ERLE

Refer to your workbook as needed and summarize the things you need

to be doing as a PO/PM:

v;

> Before PI Planning in preparation > During PI Planning on day 1

» During PI Planning on day 2

PREPARE | SHARE

SCALED

AGILE

=

[|

ae

© Scale Agile, inc.

Activities before PI Planning in preparation:

Enter activities you'll be doing as a PO/PM on the next two pages >>>

119

| ©SCALED AGILE, INC.

5.1 Create alignment with PI Planning

8:00 9:00

Business context

9:0010:30

Product/Solution Vision

i

Architecture Vision and development

Hy

Ue

11:30

practices

:

11:301:00

Planning context and lunch

_

During Planning PI Activities Day 1 1:004:00

Team breakouts SoS

4:00-

Draft plan review

e

9:00-

Management review

°

6:00

and problem solving

-

5-00

.

;

120

| ©SCALEDAGILE,

INC.

5.1 Create alignment with PI Planning

8:00 - 9:00

Planning

:

9:0041-00

Team breakouts

° ;

11:00-

Final plan review

.

1:00

and Junch

1:009-00

: Program risks

2:0015

‘ PI confidence vote

0-1 529?

Plan rework if necessary

" ;

After

retrospective and

Planning

P

moving forward

.

adjustments

commitment

[uring Planning PI ee Activities Day 2

121

| © SCALED AGILE, INC.

5.1 Create alignment with PI Planning

What POs and PMs do after PI Planning

Update the Roadmap

asia

Continue to collaborate with each other

eS

Prepare for the next PI!

SCALED AGILE” ©Sic Asie Notes

122

| ©SCALED AGILE, INC.

5.2 Decompose Features into Stories

| _

Feature decomposition Feature breakdown into User Stories happens prior to, during, and after the PI Planning event. Before, During, and After Team

Program

x

we SOY

oo exploded view

3

Program Backlog

SCALED AGILE™

@scesies Agite. inc

Notes

Features drive User Stories User Stories (from XP) replace traditional requirements expressions. > The Team Backlog consists of backlog items, many of which are elaborated as User Stories that express the needs of the stakeholders

Higher Priority

» User Stories are not requirements. They are negotiable expressions of intent.

Stories can be added, modified, removed, or reprioritized

Lower Priority

NERs

SCALED

Notes

AGILE”

“@ Sealed Aaile, inc

|

123

Fine-grained, detailed Stories, well-understood, ready for implementation in the next Iteration

| ©SCALEDAGILE, INC.

Coarse-grained Stories, less detailed and understood

!

5.2 Decompose Features into Stories

The Team Backlog > Contains all the work the team needs to work on » Contains User and Enabler Stories

— User Stories provide customers with value

— Enabler Stories build the infrastructure and architectures that makes User Stories possible » Stories in the backlog are prioritized » Stories for the next Iteration are more detailed than Stories for later Iterations

» Non-Functional Requirements (NFRs) are a constraint on the Backlog

SCALED AGILE™ ©sees Aoi |

5.23

Notes

Three primary sources of Team Backlog items

Program Backlog

Team context

Other stakeholders

f

~Re factors - Maintenance =

Backlogltem

1. Login portal

Size

5

2. Display minutes

j

.

OW @ i

Log

oh

3

~ Other team dependencies |3See - Other commitments 5. Update profile

|

6.Bi

@

Ba

gy

VY

" 4

——

:

gag)

¢ Stories

i

8

8. Log rotation 9 Timer display

5 3

41. Usage warning

2

10. Automatic logout

1

12. 300 logins/min

13

13. 17. 18. 19.

5 13 20 13

Location tracking Intrusion detection Update MySQL DB Update Web Stack

20. Update Linux Kernel

8

22. Support RADIUS Auth 23. Scan & Block Interface 24, AP Manager Interface

8 40 20

21. Support Novel Auth

Ee

@@@mza| Bikes have been

hung

Source: 3 Cs coined by Ron Jeffries

SCALED AGILE™ © selec Aaite, in |

Notes

|

|

|

|

5.27

|

|

INVEST

in a good Story I

Independent

Negotiable Valuable

Ts

|

Estimable

|

Testable

|

|

| |

Notes

SCALED AGILE

@Scated Aaile, inc

5.28

|

126

| ©SCALEDAGILE, INC.

|

5.2 Decompose Features into Stories

|

Enabler Stories Enabler Stories build the groundwork for future User Stories. There are generally four types of Enabler Stories: 1.

Infrastructure — Build development and testing frameworks that enable a faster and more efficient development process

2.

Architecture — Build the Architectural Runway, which enables smoother and faster development

3.

Exploration — Build understanding of what the customer needs to understand prospective Solutions and evaluate alternatives

4.

Compliance - Compliance enablers are used to schedule and manage specific compliance activities, including Verification and Validation (V&V), documentation and signoffs, and regulatory submissions and approvals. SCALED AGILE™ ©se2i00 Asie. nc

Notes

ae

Work flow steps

@ Data methods

@

Business rule variations

a Defer system qualities

&

Major effort

3) Operations

4)

Simple/complex

9) Use case scenarios

Ge

Variations in data

10) Break out a spike

SCALED AGILE”

Notes

©@Scaic¢ Aaile. inc

;

y

5.30

|

127

| ©SCALED AGILE, INC.

5.2 Decompose Features into Stories

1. Split by workflow steps Identify specific steps that a user takes to accomplish a work flow, then implement the work flow in increments. ...

As a utility, |want to

can publish pricing

programs to the

.

Customer’s in-home

update and publish pricing programs to my

Customer ...

aeplay

|

~~... |can send a message to the Customer’s web portal ... |Can publish the pricing table to a Customer’s smart thermostat

2. Split by business rule variations Business rule variations often provide a straightforward splitting scheme.

As a utility, |can sort Customers by different demographics ...

... sort by zip code

... sort by home demographics ... sort by energy consumption

3. Split by major effort Split into several parts, with the first requiring the most effort. More functionality can be added later on.

As a user, | want to be

_..

[want to use

able to select/change my pricing program with my utility through my web portal ...

time-of-use pricing ... |want to prepay for my energy

... |want to enroll in critical peak pricing

128

| ©SCALED AGILE, INC.

5.2 Decompose Features into Stories

4. Split by simple/complex Simplify! What's the simplest version that can possibly work?

As a user, | basically want

a fixed

price,

... respond to the time and

but | also want to

the duration of the critical

be notified of critical

He tlhe hada

peak pricing events ...

_.. fespond to emergency events

5. Split by variations in data Variations in data provide additional opportunities, such as those shown in this localization example.

As a utility, |can send messages to

Customers who want their messages in Spanish

Customers ... Customers who want their messages in Arabic Customers who want their

messages in ... etc.

6. Split by data methods Complexity can be in the interface rather than the functionality itself. Split these Stories to build the simplest interface first.

As a user, | can view my energy

... using bar charts that compare weekly consumption

consumption in

: various graphs ...

ei in a comparison i so | chart, rt, so can compare my usage to those who have the same or similar household demographics 4

129

| ©SCALEDAGILE, INC.

5.2 Decompose Features into Stories

7. Split by deferring system qualities Sometimes functionality isn’t that difficult. More effort may be required to make it faster ... or more precise ... or more scalable.

As a user, | want to Se

Seelallint:

... interpolate data from the

consumption from

ead

my meter ...

be

last known reading ... display real-time data from the meter

8. Split by operations Split by type of operation: Create Read Update Delete (CRUD)

... | Can sign up for an account

As a user, | can Inanage

my account

... |can edit my account settings

...

|can cancel my account

... |Can add more devices to my account

9. Use case scenarios lf use Cases are used to represent complex interaction, the Story can be split via the individual scenarios.

As a user, | can enroll

in the energy savings program through a retail distributor...

Use Case/Story #1 (happy path): Notify utility that consumer has equipment

Use Case/Story #2: Utility provisions equipment and data, notifies consumer

P z |

Use Case/Story #3 (alternate scenario): Handle data validation errors

130

| ©SCALEDAGILE, INC.

y

5.2 Decompose Features into Stories

10. Break out a spike » A Story or Feature may not be understood well enough to estimate. Build a technical or functional spike to figure it out, then split the Story based on that result. >» Sometimes the team needs to develop a design, or prototype an idea > Spikes are demonstrable, like any other Story

131

| © SCALED AGILE,

Functional

Technical

spike

spike

INC.

5.2 Decompose Features into Stories

Using the information in your workbook (pages 127-131), break your Features into Stories that are small enough to fit into an Iteration. > Break a Feature into at least five Stories > Try to create Stories that are less than a week in size > Identify spikes as needed

> You should have at least five Stories from your Feature

PREPARE | SHARE

> See your workbook for examples

eae

meee

Example Stories

acca

miaear eceamneunaed

My Feature

As a driver, I want to limit the amount

of money before I fuel so that I

As the Finance Department, we want

can control my

to print receipts only

expenditure.

for drivers who request them so we Can save on paper.

132

| ©SCALEDAGILE, INC.

meen

|

Te

5.2 Decompose Features into Stories

| |

Accepting User Stories A Story is complete when it satisfies the Definition of Done (DoD) and is accepted by the Product Owner. ;

Story

)

gee The DoD provides a common criteria for all backlog items.

DoD o

Story

AC ’

Teams create and adhere to the DoD.

Story

SCALED AGILE™

The Product Owner reviews each acceptance criteria and accepts Stories into the baseline.

AC

© $220 Avie. n«

Acceptance criteria » Acceptance criteria provide the details of the Story from a testing point of view » Acceptance criteria are created by the team and the PO As a driver, | want to limit the amount of money before | fuel so that | can control my expenditure.

As a driver, | want to get a receipt after fueling so that | can expense the purchase.

Acceptance criteria:

Acceptance criteria :

1. The fueling process stops automatically on the exact value

1. Receipt includes: Amount fueled, Amount paid, Tax, Vehicle

2. | can stop fueling before the limit

has been reached and will only

AUTO

ESP Mle

;

be charged for the amount fueled #7” SCALED AGILE™

Notes

5.33

© Seles Aaile. inc

|

133

| ©SCALEDAGILE,

INC.

5.2 Decompose Features into Stories

» Write acceptance criteria for 2 to 3 Stories you have identified » Make sure the acceptance criteria is testable

» Ensure that the Story meets the INVEST criteria to prepare for estimation

E

PREPARE | SHARE D |

example

example

As a driver, | want to limit the amount of money before | fuel so that | can control my expenditure.

As a driver, | want to get a receipt after fueling so that | can expense the purchase.

Acceptance criteria:

Acceptance criteria :

1. The fueling process stops automatically on the exact value

1. Receipt includes: Amount fueled, Amount paid, Tax, Vehicle number, Date, Time

2. | can stop fueling before the limit has been reached and will only

‘A

be charged for the amount fueled

7”

New acceptance criteria:

New acceptance criteria:

134

| © SCALED AGILE, INC.

5.2 Decompose Features into Stories

Estimation is a whole-team exercise |

| Agile Teams estimate Stories; POs provide clarification, but do not estimate the work

> Usually occurs during the backlog refinement event

> Increases accuracy by including all perspectives > Builds understanding > Creates shared commitment Estimation performed by a manager, architect, or select group negates these benefits.

SCALED AGILE®

Scaled Aaite. inc

Notes

» A Story point is a singular number that represents: —

Volume:

how much is there?

— Complexity: how difficult is it? —

Knowledge:

what do we know?

—

Uncertainty:

what is not known?

How big is it? Es

» Story points are relative. They are not connected to any specific unit

of measure. |

| Notes

oP;

>» Compare with other stories (an 8-point story should take 4X longer than a 2-point story) SCALED AGILE?

©scaled Aaite, inc

my

| | 5.36

|

135

| ©SCALEDAGILE, INC.

|

5.2 pecompose Fi Features into Stories

Apply Ainethe Poker for fast, relative estimates

|

» Estimating Poker combines expert opinion, analogy, and disagg regation for quick but reliable estimates > All team members participate

Each

estimator gets a deck

Estimators ;

of cards

SCALED AGILE™

@sc2iec Aaiie,

i ae

|

Cards are tumed over

Discuss differences

j Re-estimate

cards

inc 5.37

Notes

|

136

| ©SCALEDAGILE, INC.

|

5.2 Decompose Features into Stories

_.

Use Estimating Poker to relatively estimate a group of Stories. > Use one set of Stories from your team > Identify the smallest Story that takes about a day to develop and mark it as 1 > Estimate the remaining Story using the values 1, 2, 3, 5, 8, 13, 20, 40, 100 PREPARE

SCALED AGILE® © se2i0° Asie. nc

| SHARE

5.38

N

!

7

-©- Thought organizer

a

137

| © SCALED AGILE, INC.

5.3 Plan the Iteration

Plan and commit Define and commit to what will be built in

Purpose

;

the Iteration » The Product Owner defines what

Process

» The team defines how and how much » Four hours max

Iteration Goals and backlog of the team’s

Result

|

commitment » Team commits to delivering specific value

Reciprocal commitment

SCALED AGILE™

» Business commits to leaving priorities unchanged during the Iteration

© Seale Aaile. in

5.40

Notes

lteration Goals Iteration Goals provide clarity, commitment, and management information. They serve three purposes: Iteration Goals example 1. Align team members to a common purpose 1. Finalize and push last-name

2. Align Program Teams to common PI! Objectives 3.

and manage dependencies

search and firstname morphology 2. Index 80% of remaining data

Provide continuous management information

3. Other Stories: Establish search replication validation protocol

Refactor artifact dictionary

|

schema

SCALED

Notes

AGILE”

©

Sealed Aaile. inc

5;

5.41

|

138

| ©SCALED

AGILE, INC.

|

|

(3)GC) 3

=} + O poe

D

=P>) — iq) =iad)lemO =) ‘epi O

a

A Team

id)

meets its commitment:

By doing everything they said they would do. ~

or

=

In the event that it is not feasible, they must immediately raise a red flag.

Adept Too much holding to a

eo

commitment can lead to burnout,

Too little commitment can lead to unpredictability and lack of focus on results.

inflexibility, and quality problems.

Team commitments are not just to the work. They are committed to other teams, the program, and the stakeholders. SCALED AGILE™

Notes

©5seie1 Asie. inc

5.42

|

139

| ©SCALEDAGILE,

INC.

5.3 Plan the Iteration

Iteration Planning > What activities are required for the PO? > What activities are required for the PM? » Capture ideas and share with the class PREPARE

en

SCALED AGILE™

_

CR

CT

@s

Test 1

¥

Test 1

Test 2

Y

Test 2

Y Test 3

¥

Test3

Test 4

Y

Test4

* Test 5

¥

Test 5

Build functionality Build and automate tests © Scaled Agile, Inc

Figure 5. Teams build and automate tests for each new story

153.

| ©SCALEDAGILE, INC.

5.4 Execute the PI Integrate and Test the System

While critical, such local story integration and testing isn’t enough. In order to fully test the features, system-level integration and testing is required. With the support of the System Team, the work of all teams on the Agile Release Train must be frequently integrated to assure that the system is evolving as anticipated, as Figure 6 illustrates.

Full system

» Avoid physical branching for software

Leo

onien

Check out most

Check newest

changes back in

» Frequently integrate hardware branches

Check in each story

Always current

Agile Team 2

© Scaled Agile. Inc

Figure 6. Integrating the work of all teams on the ART System-level testing happens as frequently as possible during the iteration, ideally daily. However, whatever the circumstances, such full-system integration must be accomplished at least once per iteration. Otherwise, the late discovery of defects and issues reflects all the way back to earlier iterations, causing substantial rework and delays. All this work comes together in the System Demo, which demonstrates the accumulated features, and is the true indicator of ART progress. Automate Feature Tests As with user stories, features must be continuously tested against their acceptance criteria, to assure that they work not just once, but continuously into the future as new functionality is developed. Again, the philosophy of test-first is applied, in this case by automating as many of the feature tests as possible. Integrate and Test the Solution

Finally, building “Large Solutions”—those that require multiple ARTs and Suppliers to develop them—requires an additional level of integration to pull all the work together. Full or partial integration happens over the course of the PI, with a full solution integration occurring at least once per PI, as illustrated in Figure 7.

154

| © SCALED AGILE, INC.

5.4 Execute the Pl Full solution integration Full or partial integration during the Pl

System Teams

is

=

2

AGILE

AGILE ALE

NOM

COCR

OYE

RELEASE

TRAIN.

RELEASE

TRAIN

LILP AMIDE

8H

LOLA

IE LOLNG PDL

o

is

aul I

2

: S

DL PSIG ARAL

OD I YUE,

IER

=

Le

:

:

pesky

|

5

2

: ‘a

os |

EE,

© Scaled Agile, Inc

Figure 7. Full solution level integration at least once per PI The solution integration and demo are the joint responsibility of the ART and solution system teams. The Solution Demo event is where the aggregated results are made visible to the Customer and other stakeholders.

In order to be able to demonstrate the full solution routinely, ARTs typically make additional investments in integration, testing, and supporting infrastructure. In many cases, the extent of integration

and testing may be less than 100 percent, and may need to vary across multiple early integration points. To assist, teams can leverage virtualization, environment emulation, mocks, stubs, reduced test suites, etc. Time and effort for such extensive integration and demonstration may need to be explicitly allocated during PI Planning. Synchronize with Suppliers

Suppliers bring unique contributions that can have a large impact on lead-time and value delivery. Their work must be continuously integrated as well. Tips for accomplishing this integration include: ¢ Plan the integration points together. «

Adopt an integration cadence; establish objective evaluation milestones.

¢

Foster collaboration between the System Teams of ARTs and suppliers.

e

Participate in Pre- and Post-PI Planning and solution demos.

¢

Foster collaboration and synchronization between ART and Supplier Architecture/Engineering

and Systems teams. Optimizing Integration Trade-offs

Each ART’s goal is to fully integrate features across all teams in each iteration. As we described, however, that can be difficult due to solution complexity and heterogeneity, availability of specialty testers, laboratories, equipment, third party components, and so on.

155

| © SCALED AGILE, INC.

5.4 Execute the PI

Given these challenges, teams may feel that the goal of integrated iteration is not realistic—at least initially. But that can’t be an excuse for accepting late-in-the cycle integration and testing. Below are some suggestions for how to achieve most of the benefits, even when full, fast CI isn’t immediately practical.

«

Integrate different aspects of the solution at different intervals.

«

Integrate all assets, but run only a subset of tests.

*

Use virtual or emulated environments, stubs, and mocks, until the actual functionality is available.

Enabling Continuous Integration

Continuously integrating large and complex systems is a journey that takes time. The following section provides some suggestions for building a successful CI culture and practice. + Integrate often - The more frequently teams integrate, the quicker they find problems. The harder it is to do, the more often they need to do it—eliminating impediments and adding automation along the way. This results in faster learning cycles and less rework.

¢

Make integration results visible - When the integration process breaks, everybody should know how and why it broke. And when it’s fixed, new tests should be added to detect the problem earlier and prevent it from happening again.

-

Fixing failed integrations are top priority - If teams just keep working during an integration failure, it doesn’t create the right sense of urgency and importance to fix the problem. To highlight the problem, teams often use flashing lights to draw attention to a broken build, and visible indicators displaying the percentage of the time the system remains broken.

¢

Establish common cadence - Integration points are easier when all the teams are moving at the same consistent rhythm. That's why all iterations and PIs use the same cadence within an ART and/or Solution Train. If full CI can’t be accomplished during the course of an iteration, teams can make near-term tradeoffs on what can be integrated, while continuously improving their techniques and infrastructure toward this goal.

¢

Develop and maintain proper infrastructure - Effective continuous integration depends on the availability of test and staging environments (see Continuous Deployment). Infrastructure is, of course, an investment. But Lean-Agile Leaders take the long view, and make the investments necessary today to increase velocity for the marathon ahead.

¢

Apply supportive engineering practices - Continuous Integration is easier when the system is

designed with those concerns in mind. Test-First development and designing for testability calls for better modularity and separation of concerns, as well as the use of primary interfaces and physical test points.

Start Now! It's also important to note that continuous system integration and frequent solution integration represents a special challenge for groups early in their transition to SAFe. They just haven't done it previously, nor have they built the necessary infrastructure.

156

| © SCALED AGILE, INC.

5.4 Execute the PI

But the current state cannot be an excuse to simply reduce the scope of integration. Most of these challenges will disappear in a better, future state, but only if the teams start now.

Learn More [1] Dantar P. Oosterwal. The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development. Kindle Edition. [2] Lefhingwell, Dean. Scaling Software Agility: Best Practices forLarge Enterprises (Agile Software Development Series). Pearson Education. Kindle Edition. [3] Kim, Gene and Jez Humble, Patrick Debois, John Willis. The DevOps Handbook: How to Create

World-Class Agility, Reliability, and Security in Technology Organizations. IT Revolution Press. Kindle Edition.

157

| ©SCALED

AGILE, INC.

5.4 Execute the Pl

Continuous Deployment Scaled Agile Framework Article “In order for you to keep up with customer demand, you need to create a deployment pipeline. You need to get everything in version control. You need to automate the entire environment creation process. You

need a deployment pipeline where you can create test and production environments, and then deploy code into them, entirely on demand.” —Erik to Grasshopper, The Phoenix Project [1]

Continuous Deployment (CD) is the process that takes validated features from Continuous Integration and deploys them into the production environment, where they are tested and readied for release. It is the third element in the four-part Continuous Delivery Pipeline of Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment and Release on Demand.

Continuous Delivery Pipeline ®

eC

abe

CH

rte

©

wee

WSC CIAL

RCI ICTaco gE

a

CS

ch

RC

Tt

AGILE RELEASE TRAIN Continuous Exploration

Continuous Integration

Continuous Deployment

e

Me

p Release on Demand © Scaled Agile, Inc

Figure 1. Continuous Deployment in the context of the Continuous Delivery Pipeline Since tangible value occurs only when end users are successfully operating the Solution in their environment, CD is a critical capability for each Agile Release Train (ART) and Solution Train. This demands that the complex routine of “deploying to production” receives early and meaningful attention during development. By calling out specific mechanisms for continuously maintaining “deployment readiness” throughout the feature development timeline, the continuous exploration and continuous integration articles led us directly to this point. The result is smaller batches of features, some of which are always ready for deployment and release. Now we just need to continuously deploy these valuable assets so that they can be available immediately in production. This gives the business the ability to Release more frequently, and thereby lead its industry with the shortest sustainable lead time.

Details The goal is always the same, to deliver increasingly valuable Solutions to the end users as frequently

158

| ©SCALED AGILE, INC.

5.4 Execute the PI as possible. A leaner and more Agile approach to the development process, as SAFe describes, helps establish faster development flow by systematically reducing time in the development cycle and introducing “Built-in Quality” approaches.

However, in many cases development teams still deliver solutions to deployment or production in large batches. There, the actual deployment and release of the new solution is likely to be manual, error prone, and unpredictable, adversely affecting release-date commitments and delivered quality. To address this, the development and operations teams must focus their attention collectively on the downstream, deployment process. By reducing the transaction cost and risk at that point, the business can move to a more continuous deployment process, tuned to deliver smaller batch sizes more economically. That is the final key to unlocking a more continuous delivery process. Six Recommended

Practices for Continuous Deployment

SAFe recommends six specific practices to help establish a more efficient and continuous deployment process, as highlighted in Figure 2.

Decouple deployment from release

Automate deployment

and

Maintain a staging environment 27 that emulates production

@umumm

~~

Wa

Automate testing of features

Maintain development and test environments to better match production

Deploy

nonfunctional

to staging

every

Iter ration

requirements © Scaled Ag!

Ligure

42.

OLX

FTECUriMTrnerntu

PIACLILes

JUT

CUMLINuvuus

UCPLUVITLETLL

Each is described in the sections below.

Maintain Development and Test Environments to Better Match Production

Often teams discover that what seemed to work well in development does NOT work in production. This results in much time spent frantically fixing new defects directly in the production environment, typically in emergency mode.

One root cause: Development environments often don’t match production environments. For example, as Em Campbell-Pretty notes from her experience in adopting SAFe at Telstra [2], “the team quickly made a surprising discovery: Only 50% of the source code in their development and test environments matched what was running in production.” Part of the reason for this is practicality and cost. For example, it may not be feasible to have a separate load balancer, or production-equivalent data set for every development team.

159

| ©SCALEDAGILE, INC.

5.4 Execute the Pl However, most software configurations can be affordably replicated across all environments. Therefore, all changes in the production environment (such as component or supporting application upgrades, new development-initiated configuration/environment changes, changes in system metadata, etc.) must be replicated back to all development environments. This can be accomplished with the same workflow and pipeline that’s used for continuous delivery of the production solution. To support this, all configuration changes need to be captured in version control, and all new actions required to enable the deployment process should be documented in scripts and automated wherever possible. Maintain a Staging Environment that Emulates Production

This leads to a second issue. For many reasons, development environments will never match production environments identically. In production, for example, the application server is behind a firewall, which is preceded by a load balancer. The much larger-scale production database is clustered, and media content lives on separate servers. And on, and on. Once again, Murphy’s Law will take effect: Deployment will fail, and debugging and resolution will demand an unpredictable amount of time. This typically creates the need for a staging environment that bridges the gap. Even though pursuing production equivalency may never be financially prudent—for example replicating the hundreds or thousands of servers required—there are numerous ways to achieve the functional equivalent without such an investment.

For example, it may be sufficient to have only two instances of the application server instead of twenty, and a cheaper load balancer from the same vendor. In a cyber-physical system example—that of a crop harvesting combine, for instance—all the electronics subsystems, drive motors, and hardware actuators that operate the machine can be practically provisioned as a staging environment, without the fifteen tons of iron. Deploy to Staging Every Iteration

It’s impossible to understand the true state of any system increment unless it can be operated and tested in a production-like environment. So, one suggestion seems obvious: Do all System Demos from the staging environment. That way, deployability becomes part of the Definition of Done (DoD).

And while continuous deployment readiness is critical to establishing a reliable delivery process, the real benefits of shortening lead time come from actually deploying to production more frequently. This also helps eliminate long-lived production support branches, and the resulting extra effort needed to merge and synchronize all instances where changes are needed. Automate Testing of Features and Nonfunctional Requirements

But when you deploy more frequently, you have to test more frequently. And that calls for testing automation, including the ability to run automated regression tests on all the unit tests associated with the stories that implement the feature. 160

| ©SCALED AGILE, INC.

5.4 Execute the PI

Running automated acceptance tests at the feature level is also required.

Deploying incrementally also means that teams will be deploying partial functionality—individual stories, parts of features, features that depend on other yet-to-be-developed features, and features that depend on external applications and the like. Therefore, some of what teams need to test against will not be present in the system at the time they need to test it. Fortunately, there are many evolving techniques for addressing this, including applying mocks, stubs, service virtualization, and more. And finally, while automating 100% of nonfunctional tests may not be practical, what can be automated should be automated—especially in those areas where new functionality might affect system performance. Otherwise, some change could have an unanticipated and detrimental effect on performance, reliability, compliance, or any other system quality. Automate Deployment

By now it should be clear that the actual deployment process itself also requires automation. This includes all the steps in the flow, including building the system, creating the test environments, executing the automated tests, and deploying and validating the verified code and associated systems and utilities in the target environment. This final, critical automation step is achievable only via an incremental process, one that requires the organization's full commitment and support, as well as creativity and pragmatism, as the teams prioritize target areas for automation. The end result is an automated deployment process, as Figure 3 illustrates.

Fetch

es Build the environments,

consistent artifacts

Tests

ba

ee

build the system, deploy and configure the system, and run tests

Biocon

—

wee

(3) Deploy and configure, validated build, modify the data, and verify the deployment

Automated Deployment

:

Test

vis

framework

cM

System

se

framework

Figure 3. Automated deployment process

161

| © SCALED AGILE, INC.

© Scaled Agile, Inc.

5.4 Execute the Pl We can see from Figure 3 that there are three main processes that must be automated: 1. Automatically fetching version-controlled development artifacts - The first step is to automatically fetch all necessary artifacts from the CI process, including code, scripts, tests, supporting configuration items, and metadata—all of which must be maintained under version control. This includes the new code, all required data (dictionaries, scripts, look-ups, mappings, etc.), all libraries and external assemblies, configuration files, and databases. Test data must also be version controlled and manageable enough for the teams to update every time they introduce, create, or test a new Scenario.

2. Automatically build the system and its environments — Many deployment problems arise from the error-prone, manually-intensive routines needed to build the actual run-time system and its environments. They include preparing the operating environment, applications, and data; configuring the artifacts; and initiating the required jobs in the system and its supporting systems. To establish a reliable deployment process, the environment setup process itself needs to be fully automated. This can be facilitated largely by virtualization, using Infrastructure as a Service (IaaS) and applying special frameworks for automating configuration management jobs. 3. Automatically deploy to production - Finally, the process of deploying to production and validating all the deployed assets in that environment must also be automated. This has to be done in such a way that it doesn't interfere with production operation. Techniques are discussed in further detail in Release on Demand. Decouple Deployment from Release

Finally, one myth about continuous delivery is exactly that: the myth that you must deliver continuously to the end user, whether you—or they—like it or not. But that exaggerates the case and ignores the basic economic and market factors, which is that the act of releasing a solution is dependent on more than just the state of the system. There are many factors that affect the timing of releasing, including precedent events, customer readiness, channel and supplier support, trade shows and market events, compliance demands, and more. This is also discussed further in Release on Demand.

Learn More [1] Kim, Gene, et al. The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. IT Revolution Press, 2013. [2] Kim, Gene and Jez Humble, Patrick Debois, John Willis. The DevOps Handbook: How to Create

World-Class Agility, Reliability, and Security in Technology Organizations. IT Revolution Press. Kindle Edition. [3] Humble, Jez and David Farley. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley, 2010 [4] Gregory, Janet and Lisa Crispin. More Agile Testing: Learning Journeys for the Whole Team. Addison-Wesley Signature Series (Cohn). Pearson Education. Kindle Edition.

162

| ©SCALEDAGILE,

INC.

5.4 Execute the Pl

DevOps Scaled Agile Framework Article “Imagine a world where product owners, Development, QA, IT Operations, and Infosec work together, not only to help each other, but also to ensure that the overall organization succeeds. By working toward a common goal, they enable the fast flow of planned work into production, while achieving world-class stability, reliability, availability, and security.” —The DevOps Handbook [1]

DevOps is a mindset, a culture, and a set of technical practices. It provides communication, integration, automation, and close cooperation among all the people needed to plan, develop, test, deploy, release, and maintain a Solution. SAFe enterprises implement DevOps to break down silos and empower each Agile Release Train (ART) and Solution Train to continuously deliver new features to their end users. Over time, the separation between development and operations is significantly reduced and trains operate with an automated, continuous delivery pipeline. This mechanism seamlessly defines, implements and delivers solution elements to the end user, without handoffs or excessive external production or operations support.

The goal is simple: Deliver value more frequently. This is indeed achievable, as “high-performing IT organizations deploy 30x more frequently with 200x shorter lead times. ... 60x fewer failures and recover 168x faster.’ [1]

Details DevOps is a combination of two words, ‘development’ and ‘operations. Without a DevOps approach, there's often significant tension between those who create new features and those maintaining the stability of the production environment. The ‘development team’ is measured on the business value they deliver to end-users, while ‘IT service management is measured on the health and stability of the production environment. When each group has seemingly opposing business objectives, delivery inefficiency and organizational friction may rule the day.

But DevOps ends the silo approach, providing an enterprise with the ability to develop and release small batches of functionality to the business or customer in a flow process called the Continuous Delivery Pipeline. DevOps is integral to every Value Stream, and, by definition, is integral to SAFe. Many SAFe concepts and principles—systems thinking, small batch sizes, short iterations, fast feedback, and more—directly support DevOps principles. In addition, the SAFe practices of Continuous Exploration, Continuous Integration, Continuous Deployment, and Release on Demand directly support this business need.

163

| © SCALED AGILE, INC.

5.4 Execute the Pl

The Goal of DevOps

From planning through delivery, the goal of DevOps is to improve collaboration between Development and IT Operations by developing and automating a continuous delivery pipeline. In doing so, DevOps:

¢

Increases the frequency and quality of deployments

¢

Improves innovation and risk taking by making it safer to experiment

¢

Realizes faster time to market

-

Improves solution quality and shortens the lead time for fixes

«

Reduces the severity and frequency of release failures

¢

Improves the Mean Time to Recovery (MTTR)

SAFe’s ‘CALMeR approach to DevOps covers the five main aspects, as illustrated in Figure 1.

© Scaled Agile, Inc.

Figure 1. SAFe’s CALMeR approach to DevOps Each aspect is described in the sections below. Culture of Shared Responsibility

In SAFe, DevOps leverages the culture created by adopting the Lean-Agile practices of the entire framework. Just about every principle of SAFe, from View” to “#9 Decentralize Decision Making,’ applies to DevOps. It enables responsibilities upstream, while following development work downstream operating and monitoring the solution in production. 164

| O©SCALEDAGILE, INC.

values, principles and “#1 Take an Economic shifting some operating into deployment, and

5.4 Execute the PI Such a culture includes:

Collaboration and organization —- DevOps relies on the ability of Agile Teams and IT Operations teams to collaborate effectively in an ongoing manner, ensuring that solutions are developed and delivered faster and more reliably. This is implemented, in part, by including operations personnel and capabilities on every ART. Risk tolerance - DevOps requires a tolerance for failure and rapid recovery, and rewards risk taking.

Self-service infrastructures - Infrastructure empowers development and operations to act independently without blocking each other. Knowledge sharing - Sharing discoveries, practices, tools, and learning across silos is encouraged. “Automate everything” mindset - DevOps relies heavily on automation to provide speed, consistency, and repeatable processes and environment creation, as we describe below. Automate Everything

DevOps simply recognizes that manual processes are the enemy of fast value delivery, high productivity and safety. But automation is not just about saving time. It also enables the creation of repeatable environments and processes, which are self-documenting and, therefore, easier to understand, improve, secure, and audit. The entire continuous delivery pipeline is automated to achieve a fast, Lean flow. Automation facilitates faster learning and response to market demand and customer feedback. Builds, testing, deployments, and packaging that are automated improve the reliability of processes that can be made routine. This is accomplished, in part, by building and applying an integrated and automated ‘tool chain; shown in Figure 2, which typically contains the following categories of tools: ———— .*

i

:

5 ee

Continuous Delivery Pipeline oe oar

FEE ee

we

EEE eee

Ate

Cr 30 — 60 minutes > Pick 1 — 2 things that can be done better, target for next Iteration >» Enter improvement items into the Team Backlog

56

SCALED AGILE™ © Scies Ante.nc Notes

|

-

=

The Innovation and Planning (IP) Iteration Sunday

c Monday

31

e

Tuesday

Wednesday

1

2

Thursday

3

Friday

4

Saturday

2

Validation (if shipping)

Innovation / hackathon / spikes for next Pl

PI Planning readiness

PI Planning Continuing education

12

13

%

Inspect and Adapt

|

workshop

|

SCALED AGILE?

@Sceled Aaile, inc

5.62

i

Notes

|

169

| ©SCALEDAGILE, INC.

5.4 Execute the Pl

Inspect and Adapt Three parts:

1. The PI System Demo

» Attendees: Teams and stakeholders

2. Quantitative measurement

> Timebox: 3 — 4 hours per PI

3. The problem-solving workshop

ay

SCALED AGILE”

© Scio Asie |

5.63

Notes

170

| ©SCALED AGILE, INC.

5.4 Execute the PI

> Map out your program events on a calendar, and socialize with

ee

another team » Think about the PO and PM roles, and place the program events in the column in which that role would add the most value for them to attend/participate.

> Prepare to share with the class |

PREPARE | SHARE

|

|

|

SCALED AGILE” © scales Aa, inc

5.64

For POs:

For PMs:

My Program Increment events:

a

a

.

i

My Program Increment events:

a 171

| ©SCALED AGILE, INC.

5.5 Release on Demand

LE Stories satisfy acceptance criteria Acceptance tests passed (automated where practical) Unit and component tests coded, passed, and included in the BVT

Cumulative unit tests passed Assets are under version control

Engineering standards followed

Ly)

es

Capabilities completed by all teams in the ART and integrated

trains and meet acceptance criteria

Completed features meet acceptance criteria

Deployed/installed in the staging environment

NFRs met

NFRs met

No must-fix defects

System end-to-end integration, verification, and validation done

Verification and

validation of key

End-to-end integration and solution V&V done

Regression testing done NFRs met

scenarios

No must-fix defects

Included in build definition and deployment process

Included in build definition and deployment/transition

* Increment

All capabilities done and meet acceptance criteria

process

No must-fix defects Release documentation complete All standards met Approved by Solution and Release Management

+ Documentation updated

sable et

pomegested

* No must-fix defects

feedback scleveg

* Solution demonstrated, feedback achieved

* Stories accepted by Product Owner

‘ nalecinee Sek

* Accepted by Solution Management

© Scaled Agile, Inc.

gile, |

SCALED AGILE”

5.66

Notes

Demand Continuous Delivery Pipeline

v

rc

Continuous Exploration

Continuous Integration

Continuous Deployment

Release on Demand

| |

© Scaled Agile. Inc

|

For more on the Continuous Delivery Pipeline, watch the “Introduction to Continuous Delivery Pipeline” video on the SAFe Community Platform

|

SCALED AGILE’

©

Scaled Agile, Inc

| |

5.67

Notes

172

| © SCALED AGILE, INC.

5.5 Release on Demand

_

:

Decouple Cadence. Release on Demand Major release Subsystem

Customer |

preview

release

|

|

Pl

Pl

Major release

New feature [ Release on Demand

Pl

Pl

Pl Develop on Cadence © Scaled Agile, inc

men

SCALED AGILE™ ©s:0 Asie inc Notes

|

Architect the Solution for Incremental Release

Canary Release | Feature toggles

Dark launches

End-user funowonality (released every 2 weeks)

Streamlet 1 ee Streamlet 2

as

6s ee. Security updates

re

{released on demand)

Streamlet 3 ——--____—__—-(y-—_—_}_——_ 9 > Continuous Exploration

Continuous Integration

Streamiet 4 2

Continuous Deployment

Back-office functionality every month) Entire solution

Solution

(major release

every quarter)

| Pl

Pl

Pl

@ Scaled Agile, Inc.

| |

|

| |

Notes

SCALED AGILE®

©scaled Agile, inc

5.69

|

173

| © SCALED AGILE, INC.

5.5 Release on Demand

» Your Release on Demand strategies: - What can you do to evolve your Definition of Done? - What can you do to better foster architecting the solution for incremental release? - What might you change in the future?

PREPARE

SCALED AGILE™

© Sales

Aaile, inc

Your Release on Demand strategies: - How are you doing it now? - How could you apply these strategies in your enterprise?

- What might you change in the future?

174

| ©SCALED AGILE, INC.

| SHARE

Lesson summary

In this lesson, you: > Created alignment with PI Planning » Decomposed Features into stories > Explored planning the Iteration

» Discussed events to execute the Pl > Integrated Release on Demand strategies Suggested Scaled Agile Framework reading: “Scrum Master’, “Agile Teams”, “Product Owner’, “Continuous Delivery Pipeline”, and “Release on Demand” articles 4

© Scaled Agile, inc

NS

!

4

20K Thought organizer

EEE

175

| © SCALED AGILE, INC.

EES

Lesson #5

Executing the

Key Learnings

Program Increment

:

& Insights

176

| © SCALED AGILE, INC.

| eSSON #6 Defining the Product Owner and Product Manager Responsibilities Learning objectives: 6.1 Characterize the roles of the Product Owner and Product Manager 6.2 Examine other key program collaboration roles

SAFe® Course: Attending this course gives students access to the SAFe Product Owner / Product Manager exam and related preparation materials.

177

| ©SCALED AGILE, INC.

6.1 Characterize the roles of the Product Owner and Product Manager

Product Owner responsibilities » Ensures Stories and Enablers meet the acceptance criteria — Stories are aligned to Vision, Features, and PI Objectives — Has content authority for the Team Backlog

» Represents customers and stakeholders » Participates in Iteration ceremonies as a team member > Helps decompose Features into Stories and prioritizes the Team Backlog — Works with the System Architect and the Team to understand and prioritize Enablers

> Is open to negotiations that will occur

» Accepts the Stories as done ©Seaiec Agile Inc

SCALED AGILE™

Notes

> Business Analysts (BAs)

|

> Subject Matter Experts (SMEs) » Project Managers » Domain Experts » Architects

|

|

Notes

SCALED

AGILE”

©@ Scaled Aaile. inc

|

178

| ©SCALED AGILE, INC.

6.1 Characterize the roles of the Product Owner and Product Manager

Focused on delivering stories and enablers to the train, tasked with helping the team build the right things at the right time. > Ability to communicate

> Trust

> Good business sense

>» Courage

> Technical foundation

> Content authority

SCALED AGILE™

\scaomscanad?

©s Establishes the sequence of backlog items based on program priorities, events, and dependencies with other teams

> Operates as part of an extended Product Management Team » Understands how to operate with Epics, Capabilities, Features, and Stories

ve

> Uses PI Objectives and Iteration Goals to communicate with management > Coordinates with other Product Owners, the System Team, and shared resources in the ART PI Planning meetings > Works with other Product Owners and Product Management throughout each Iteration and PI

SCALED AGILE”

Scaled Aaite, inc

67

Notes

179

| ©SCALED AGILE, INC.

6.1 Characterize the roles of the Product Owner and Product Manager

Product Manager responsibilities Collaborates and sets expectations with Product Owners, stakeholders, customers, architects

» Can say ‘no’ in multiple directions: Stakeholders, Managers, LPM,

vV

and Product Owners » Prioritizes Features and negotiates Enablers in the Program Backlog using WSJF » Sets the Vision and Roadmap for the train > Has significant people skills and the innate ability to navigate the political landscape > Collaborates with the train to set scope

ww

» Accepts the Features as done SCALED AGILE™

Notes

© Sc2is¢ Agile, inc

6.8

|

Product Manager attributes Focused on the business aspects and the market at large, tasked with building the right Features at the right time. > Sense of balance

» Solid understanding of

current Solution

> Forward thinking > Continuous exploration and

pLIUst

understanding the customer's needs

SCALED AGILE?

Notes

scales Aaile, inc

69

|

180

| ©SCALED AGILE,

INC.

6.1 Characterize the roles of the Product Owner and Product Manager

| PO and PM governance: Content authority Product Manager — Program Backlog :

wm! PORTFOLIO

;

zm)

» Has Product Backlog content authority. Works with the System Architect and Team to prioritize Enablers.

y

» Has content authority for Vision and Roadmap ;

= SOLUTION

Spy.

==

> Helps drive PI Objectives » Establishes Features and acceptance criteria

= See Product Manager

» Drives Iteration Goals and content via prioritized Stories

@

» Establishes Story acceptance criteria

Bia

» Has authority for accepting Stories and Team increments

BACKLOG

gy

Product Owner — Team Backlog » Has Team Backlog content authority. Works with the System : Ese Architect to prioritize Enablers.

BACKLOG

gy

| TEAM

=e

inte

Product Owner

» Helps drive PI Objectives at the Team Level SCALED AGILE™ © Svatec Aaile, Inc

Notes

6.10

|

ee ee eS Se

181

| © SCALED AGILE, INC.

6.1 Characterize the roles of the Product Owner and Product Manager

» Half the room will take the role of the PO, then the other half will take the role of the PM | |Eb

» In your teams, use your flip chart to brainstorm the typical activities a PM or PO would be involved in. List a minimum of 10 things a PM or PO should do on a daily (or near-daily) basis.

:

» Add a time estimate to each item PREPARE

» What conclusion can you make about the PM and PO roles?

SCALED AGILE™

ee

© scales Aaiio. inc

Typical daily activities: (minimum of 10)

| SHARE

Estimated time:

Typical daily activities: (minimum of 10)

What conclusions can you make about the PO and PM role?

182

| © SCALED AGILE, INC.

Estimated time:

|

6.1 Characterize the roles of the Product Owner and Product Manager y

Z

WORKBOOK

PAGI

£183 LE

a

|

» Use the Framework image on page 184 in your workbook to draw connections

from the Product Owner and Product Manager to other framework elements, based on:

=

— Content authority and impact on the enterprise

im

— Collaboration

-E

Problem-solving

+ ee

> List the impacts and the challenges you may have in

performing the content authority aspect of your role

> Be ready to present

AGILE™

©

ee

a me

Inputs/Outputs — Other ideas you have

SCALED

22

PREPARE | SHARE

|

Scaicc Agile. Inc

Draw your connections on the next page>>>

List the challenges you might face in performing this aspect of your role:

List the impacts you might have in performing this aspect of your role:

OS

EE

——EE———EE—E——————————E

183

Sanne

| © SCALED AGILE, INC.

Cov

Eee

H

Ea

a

sas

=

ee

:

re)

Ayyeny uj-yIng

WV3SL

Aemuny

ET

ld

[¢|

ous

os

oa

~

£@

|Aiois |

(G}

ja

ey

ees

5

deupeoy peoy

a

=

@ evs

a

“

x

veiqeus|

(Si)

7

oS

7

Kors

‘Ss

=|

3

s

==

aio ) |_'

O1JOY

=

r

oe

« e

siapee 1

Pay

apGy-uee 6y-uee] W@

peneeeee

:

MH M4

MS

wes] Asq

mos

e

aime

¢

Xp

pan

ueeq

ree

a

wa}shs

eon

41

S21

[¢|

=)

a &

A

2

2

Bat

v

sjeog

S

Q suoijeia}|

e

0

a

ae

a :

nie

@

rt

~~

aouapes uo dojaneq

bashing vonewowedu; CSL,

Leiqeua | |

|aunyeed |

Souled) uieqaae

uonesojdxg

S1a2UMO

wry

“pase

eat Fate asa

UORNIOS

aoueldwo5

yiomauiel 4

yw6y = Bug/youy 3

A

;

asiudseyug Leed

6

g1w0u02g

21d asiidiajug

sowayl