al shalloway · 2020-05-27 · founder and former ceo of net objectives co-founder of lean-systems...

May 20

MODULE NAME © Project Management Institute. All rights reserved. This material is being provided as part of a PMI Disciplined Agile Workshop. 1

© Copyright PMI. All Rights Reserved 1


Al ShallowayDirector, Thought Leadership for Agile at Scale Programs, PMI

Al.Shalloway @ pmi.org

@AlShalloway

Founder and former CEO of Net ObjectivesCo-founder of Lean-Systems SocietyCo-founder Lean-Kanban University Former contributor to SAFe and SPCT

1

2

May 20



AGENDAOur inherent challenge

What it takes to have effective value streams

Two key concepts

• Minimum Business Increments

• Dedicated Product Teams

Test-first as process

What SAFe provides us (good and bad)

The DA FLEX Playbook for SAFe

Excerpts from Disciplined Agile Value Stream Consultant & The DA FLEX Playbook for SAFe


UNDERSTANDING OUR INHERENT PROBLEM

3

4

https://portal.netobjectives.com/pages/books/davscworkshop/dedicated-product-teams/

https://portal.netobjectives.com/pages/books/the-disciplined-agile-value-stream-consultant/disciplined-agile-for-safe/

May 20



KEY CONCEPTSWe manage one way but our work flows another way.

Why we need to focus on the workflow we use to create value, not on peoples’ individual productivity.

We must attend to the qualities of our value streams.


Common Organizational Structure

inspired by Dan North, BSC/ADP 2012

Marketing Product Management

Development Support

Note how this has us look to

see if people are:

• properly utilized

• being productive

• doing quality work

• working on the right things

5

6

May 20



The Nature of Our Work


Development Support

Get approval

Get approval


even though value flows this way

We manage our people

this way

This is our inherent problem.

7

8

May 20



even though value flows this way


time-to-market

Our eco-system and the visibility of our work in it

a a

Make sure work

upstream from a

team is visible

Make sure a team’s

work is visible

downstream

9

10

May 20


© Copyright PMI. All Rights Reserved 11T H I N K I N G P O I N T

Lean Mindshift

Instead of focusing on how to manage people or

the work, focus on managing the flow of the

work.

Old style checks

that people are… Lean attends to …

• properly utilized

• being productive

• doing quality work

• working on the right

things

• time-to-market

• ecosystem / visibility

• effects of upstream

groups on their teams

• effects of their teams

on downstream groups


Time-to-Market


Development Support

11

12

May 20



The Value Stream


Development Support

© Copyright PMI. All Rights Reserved 14D E F I N I T I O N

The Value Stream

A value stream is the set of actions that take

place to add value to a customer from the initial

request through realization of value by the

customer. The value stream begins with the initial

concept, moves through various stages of

development and on through delivery and support.

A value stream always begins and ends with a

customer.

13

14

May 20



How Often Does Work Wait?

Adding Value

Waiting

Adding Value Adding Value

Adding Value

Adding ValueAdding Value

What percent of the time is our work moving forward?

How would you know?

No one is managing this in most companies.

Waiting

How much of the time is it waiting for something else to be done?

Wa

itin

g

Adding Value

Adding Value

Adding Value

Adding Value

Waiting


Development Support


• Between getting requirements and using them?

• Between writing a bug and it being detected?

• Between two groups getting out of sync?

• Just waiting for someone?

What happens when adding value is delayed?

15

16

May 20



We must expand our view of Agile to include the entire enterprise


Development Support

Dev Ops

Agile

budgeting &

portfolio

management

Agile

You are involved in Agile if you have something

(anything) to do with adding value to your

customers or supporting the people who do.

Who in your organization is this not true for?

Why are they in your organization?


Consider what makes value streams ineffective

Symptoms of ineffective value streams:

• Handbacks

• Handoffs

• Delays in workflow• Waiting for people on your team (an indication

of poor process)• Waiting for people on other teams (an indication

of poorly formed teams, poor management of dependencies or workload, or poor visibility of work between teams)

• In getting feedback

• Rework

• Integration errors

• Multi-tasking

• Poor code quality

17

18

May 20



Factors for Efficient Value Streams

WorkflowAvoid handoffsand handbacksManage QueuesTest-FirstAutomation

…

Work ItemsHigh value (MBIs)Discovery (MVPs)

Vertical slices to validate

…

People Allocation# of value streamsCross-functionalityProfessional ServicesBudgetingCollaborationHow measured…

WorkLevel

Stay below capacity

Otherwise takes too

long to deliver things

of lesser value

If done poorly get

delays and multi-

tasking

Poor workflow

causes delaysPoor quality causes

rework and delays

adding functionality

Working beyond capacity injects delays

and multi-tasking. Biggest cause of waste


Practices for Efficient Value Streams

WorkflowAvoid handoffsand handbacksManage QueuesTest-FirstAutomation

…

Work ItemsHigh value (MBIs)Discovery (MVPs)

Vertical slices to validate

…

People Allocation# of value streamsCross-functionalityProfessional ServicesBudgetingCollaborationHow measured…

WorkLevel

Stay below capacity

Otherwise takes too

long to deliver things

of lesser value

If done poorly get

delays and multi-

tasking

Poor workflow

causes delays

Working beyond capacity injects delays

and multi-tasking. Biggest cause of waste

Poor quality causes

rework and delays

adding functionality

The Minimum

Business Increment

Dedicated

Product Teams

Test-first

Automated testing

Keep work within capacity by having

a well-defined intake process

Test-first

Automated testing

19

20

May 20



THE MINIMUM BUSINESS INCREMENT

How do we best right-size our work?

MVPs are not enough


KEY CONCEPTSSmall batches of work are good

MVPs are good for innovation

We need something else for enhancements (MBIs)

Sequencing work should be based on MBIs

MBIs are containers for what needs to happen

The MBI template

21

22

May 20



We want an artifact to drive our work.

Must be releasable (have value on release)

… and as quick as possible (be small)

While the focus may be on the customer these

decisions include business value factors


Minimum Viable Product (MVP)

The smallest piece of work to be used to validate

a hypothesis about a potential product.

Geared towards startups.

First time a product/service is released.

Usually built by a small team that can pivot.

But, what do you do when:

• You are an established company?

• It is an enhancement to an existing product/service?

• Multiple teams are required to build it and they are not aligned?

23

24

May 20



Minimum Business Increment (MBI)

The minimum amount of value that can be built,

deployed and consumed, that makes sense

from a business perspective.

It contains all the pieces required for realization

of value.

As well as the capabilities needed to create it.

MBIs are an extension of the MMF of Denne and

Cleland-Huang’s in Software by Numbers.

Note that SAFe’s MMF is not related to this.


An MBI is not a reason to deliver less. It is a reason to deliver the value sooner.

Chunk it small but do it all (until something with

more value comes along)

25

26

May 20



MVPs and MBIs are mindsets and about incremental delivery but are not the same

• Both create end-to-end slices of functionality to validate the work.

• Both are customer centric.

• MVPs are investments in new products while MBIs are investments in existing products.

• MVPs start small with a team and grow while MBIs usually require several teams.

• MVPs start with few features and add to them while MBIs decompose identified functionality into their most valuable aspects by decomposing features.

• MVPs require focused interactions with prospective clients while MBIs are usually identified and distributed through the existing marketing organization.

• MVPs have a continuation mindset while after each MBI one should consider if there’s been enough value.

• We go from MVPs to MBIs when either the product is mature or requires multiple teams to build it.


Objectives and Key Results

Initiatives

Minimum Business Increments and/or MVPs

Features / Scenario(s)

User Stories

Right-sized Stories

Tasks

MBIs and MVPs represent the boundary between business initiatives and development.

From the business stakeholder’s perspective they are the next chunk of business value they will get.

Define MBIs by focusing on:

• client

• market segment

• geography

From the development group’s perspective they are the focus of what they need to build, release and have the customer realize value from.

Strategies

DISCOVERY

IMPLEMENTATION

27

28

May 20



Job sequencing is the key to economic outcomes.

If you only quantify one thing, quantify the Cost of Delay.Don Reinertsen (Reinertsen 2009)

Calculate cost of delay on MBIs.Value of MVPs is unknown.Epics are too big (not all of an epic is released).Features are too small if they are not complete on their own.


Value of MBIs

MBIs provide a view of what’s most important

to be worked on across the organization. This

facilitates collaboration while enabling local

decision making to fulfill the overall picture.

Planning events should be around creating and

delivering MBIs quickly.

MBIs tie strategies to development to release.

29

30

May 20



Minimum Business Increment Template

An example checklist for creating MBIs

The MBI Template is not for governance. It is used

to remind teams about what they have decided

they need to do to create value in a sustainable

manner.Architectural issues

• Other capacities needed (e.g.,

UX, shared services)

• What’s needed for release /

realization?

Support Groups

• Documentation

• Marketing

• Support

• Ops

Is there a time of delivery risk?

• If yes, when? Why?

Requirements

• Who it is for?

• Do use cases exist to

describe the value?

• Does it meet the

organization’s definition of

done?

• What’s needed to develop it?

• What development teams

involved in creating it?


DEDICATED PRODUCT TEAMS

31

32

May 20



Coordinate by organizing people around the workflow

The primary question is not “how do you

coordinate teams?”, but “how do you make it

so the teams need less coordination?”

Improving flow is easier and less complex by

attending to how people are organized than by

managing the work flowing through a poorly

organized group of people.

By improving the structure of the people we lower

the number of interactions and make coordination

easier.


The Dedicated Product Team

Core Team

SPECIAL SKILLS

SPECIAL EXPERIENCE

Core Team

Feature Team

Use Kanban to request work items to be done by people whose skills are required across teamsor have them

provide people temporarily as needed.

A dedicated product teams (DPT) is a cross-

functional team, or team of teams, able to create

an MBI or MVP on their own. They are

dedicated to working on this increment and do

not work on other things while building this

increment except on an exceptional basis.

If a team of teams, they are composed of:

Feature teams are teams that can create

features – end-to-end functionality that a

customer can use but may or may not be

valuable by themselves.

Core Teams are close to being cross-functional

but are missing a few key skills.

It is more an attitude that the people in the DPT

are working together than the actual structure.

Feature Team

Dedicated Product TeamCross-functional, focused, dedicated

33

34

May 20



TEST-FIRST AS PROCESS


The “Triad”

36

Test

Spec

35

36

May 20



ATDD

The Big Goal is:Collaboration Leading to a Shared Understanding


WHAT SAFE® PROVIDES: THE GOOD AND THE BAD

37

38

May 20



SAFe has a good start SAFe gets companies unjammed by:

• creating Agile Release Trains

• Implementing product management

• doing quarterly planning while avoiding

overloading teams

• having teams work together in common

cadence with frequent synchronization

• using DevOps

• partial shift in management


Shared

services need

to be handled

with Kanban

DevOps is

an

essential

part of

Lean-Agile

delivery

The product

manager role is

essential to attend

to products, not

merely features

The RTE is needed

to provide the larger

perspective of the

train, not merely the

team

A delivery pipeline

focused on value to

the customer across

the teams of the train

is essential

Teams working in common cadence with

frequent synchronization is essentialQuality

technical

practices

are even

more

important

at scaleEffective leadership

is essential

A program

backlog to create

the context for

the teams is

useful creates the

context for

collaboration

Lean is required

at scale

39

40

May 20



Esse

nti

al S

AFe

Everyone needs theseEveryone needs these, but they are more complex than need be.


SAFE FROM A VALUE STREAM PERSPECTIVE

41

42

May 20



Systems are defined by the relationships between their components and not the components themselves. Easiest to see these in a value stream.


SAFe as a Value Stream

43

44

May 20



SAFe as a Value Stream

Why view from a value stream perspective?

• Systems are about the relations between their components.

• They are not just the components.

• Value streams highlight these relationships.

• Upstream has great effect on downstream.

• Want to start thinking in terms of flow.

• It is less disruptive to expand functionality by adding

activities to the value stream than to add new levels.


The Keys to Essential SAFe

The product

manager role is

essential to attend

to products, not

merely features

A delivery pipeline

focused on value to

the customer across

the teams of the train

is essential

Teams working in common cadence with

frequent synchronization is essential

DevOps is

an

essential

part of

Lean-Agile

delivery

Shared services need to

be handed with Kanban

A program backlog

to create the context

for the teams is

useful creates the

context for

collaboration

The RTE is needed

to provide the larger

perspective of the

train, not merely the

team

Effective leadership

is essential

Lean is required at

scale

Quality technical

practices are even more

important at scale

45

46

May 20



Note that even small orgs or sub-

orgs of big companies need this

As well as this

Epics are too big while

features and enablers

are too small to

sequence on

This leaves much

selection and

prioritization to the PI

Using MVPs at this

high-level defeats their

true purpose.

SAFe Has Some Issues

The concept of the smallest

increment of business

value for an existing

product is missing


DA FLEX PLAYBOOK FOR SAFE

47

48

May 20



The Agile OrganizationThe future of Agile revolves around three laws

1) Law of the small team

2) Law of the customer

3) Law of the network

Age of Agile, Steve Denning

We want a network of semi-autonomous, self-organizing

teams focused on creating value for your customers.

ARTs and the PI Planning event are good steps to unjam the

system and to gather the information needed to create the

network. But they won’t take you to true agility.

Instead of a few large ships, we want a fleet of aligned small

ships.

Sometimes you take a big ship and break it into a flotilla of

small ships.

Sometimes you take a disorganized group of small ships and

align them into a flotilla.


DA FLEX and SAFe

The playbook does not fundamentally change SAFe.

It takes what works, improves a few concepts and

adds a few missing ones in order to create a simpler,

more effective SAFe.

Types of plays:

1. Improvements (e.g., PI Planning)

2. Additions (e.g., MBIs, creating dedicated product

teams)

3. Enablers are plays SAFe implies you need but

doesn’t provide (e.g., creating the dual operating

system)

4. Corrections (e.g., value streams, WSJF)

49

50

May 20



The FLEX Playbook is a collection of actions to take

to attempt to make specific improvements.

Actions are either a single play or a set of plays

(called a ‘play set’).

Necessary concepts and useful principles are

included.

A play is defined as:

• A specific set of actions taken to achieve a

specific result in a specific circumstance.

• Has particular forces to attend to

A play set is defined as more than one play that are

to be done together to create a result larger than

one play can do on its own.

The DA FLEX Playbook

For SAFe


DA FLEX and SAFe

Take a value stream view. Otherwise essential practices are

missed or complexity is added. Also useful for eliminating silos.

Start where appropriate. Starting at the program level is not

always the best place to start.

Improve Product management. MVPs are insufficient. Use

MBIs as the main artifact to extend existing offerings.

Team organization. ARTs may be a good start, but dedicated

product teams enabling a product mindset realize value faster.

Dependency management and team coordination. Planning

cycles can be shorter once working groups are smaller.

Enable continuous improvement with kaizen. Two week to

2-3 month learning cycles slows learning.

Implement Lean management. Knowing it is a good thing

doesn’t tell you how to manifest it.

51

52

May 20



DA FLEX Play Book

Four phases

1. Improve in place. Use new FLEX concepts and a few

plays to improve SAFe’s core practices. Enables quicker

releases, better management of shared services and

improved cross-functionality of teams

2. Restructure teams and shorten planning cycles as

possible. Use Lean thinking and deep understanding of

workflows to decompose ARTs into dedicated product

teams. This allows for shorter program increments.

3. Align teams to business stakeholders and implement

agile budgeting. Achieve the desired network of semi-

autonomous teams aligned with business stakeholders

and implement agile budgeting as possible.

4. Guided continuous improvement. Using proven

techniques designed for your context. The journey never

ends, keep improving.

Phases can be done in sequence or in parallel.


1. Minimum Business Increments

Phase 1: Improve in place

1.Minimum Business Increments

2.Use MBIs

3.a. Improve PI Planning

3.b. Shared services as service providers

4.Improve cross-functionality of teams

5.Adopt ATDD / BDD

Minimum Business Increments are an

essential artifact for tying workflow from

initiative to feature.


53

54

May 20





2.Use MBIs


3.b. Shared services as service providers


5.Adopt ATDD / BDD

Minimum Business Increments are

used to help teams align teams around

the releases of value. They contain both

the description of what’s needed as well

as who needs to be involved,

2. Use MBIsUse DA-FLEX WSJF

Phase 1: Improve in place1. Minimum Business

Increments


3a. Prior to PIs slightly adjust teams based on who is needed.

During PIs:1) Dependency Management2) Quick completion of MBIs

After PIs: Make further adjustments to teams based on identified dependencies

3b. Shared services as professional

service providers



2.Use MBIs


3.b. Shared services as service

providers


5.Adopt ATDD / BDD

Program increments are opportunities

to:

• Identify dependencies across teams

• Use this knowledge to improve team

organizations

• Focus on collaboration and dependency

management to achieve quicker

releases than about detailed planning.

Shared services should provide people to

teams when possible.




55

56

May 20



4. Improve team cross-functionality



2. Use MBIs

3. a. Improve PI Planning

3. b. Shared services as service

providers

4. Improve cross-functionality of

teams

5. Adopt ATDD / BDD

After the planning event there is time to do

a retrospection on where people were

multi-tasking across teams. Now is an

opportunity to do some larger

improvement for the teams. This will

remove delays and allow team members

to focus. We’re also now one step closer

to the next phase of aligning multiple

teams to one product.





During PIs:Dependency ManagementQuick completion of MBIs



service providers


5. Add ATDD to some degree



2. Use MBIs

3. a. Improve PI Planning

3. b. Shared services as service providers

4. Improve cross-functionality of teams


Acceptance Test-Driven Development is

more of a procedural change than it is

technical training. While SAFe does

recommend the ATDD training include

product owners it is not explicitly designed

for that. It should be. ATDD is about the

triad – product owner:developer:tester. If

you used SAFe’s training to get here,

great, it not, use other ATDD training to

get you here.








service providers


57

58

May 20



Phase 1: Improvement in Place

Phase 2: Decomposing ARTs into DPTs

6. Agree to the Disciplined Agile

Promises

All roles promise to:

• Create psychological safety

• Accelerate value realization

• Collaborate proactively

• Make all work and workflow visible

• Improve predictability

• Keep workloads within capacity

• Improve continuously

Shared promises greatly improves the

effectiveness of the organization.








service providers



6. Agree to the Disciplined Agile Promises





7. Dedicated product teams

The teams in the networks of teams don’t

have to be limited to two-pizza teams.

They need to be:

• Cross-functional for the MBIs they are

working on

• Dedicated to what they are working on

• Stable so they can build a stream of

MBIs

This sets up an Agile budgeting process

for the initiatives spawning these MBIs.








service providers




7. Dedicated Product Teams

59

60

May 20



8. Decompose ARTs into Dedicated Product Teams




7. Dedicated product teams

8. Decompose ARTs into DPTs

Independent DPTs can work more

efficiently than ARTs that have several

dependencies between their sub-teams.

This enables shorter planning cycles.








service providers







Phase 3: Organize around products and

start Agile budgeting

9. Align Dedicated Product Teams to

stakeholders

Since Dedicated Product Teams work on

MBIs, we can align them to the

stakeholders that are spawning them. This

sets the stage for Agile budgeting.


Phase 3: Organize around products and start Agile budgeting






service providers





61

62

May 20



10. Start Agile Budgeting





9. Align Dedicated Product Teams to

stakeholders

10. Start agile budgetingIt is easier to implement a quality agile

budgeting process by reorganizing the

people to align with products than it is by

managing artifacts to go to disparate

teams.


Phase 3: Organize around products and start Agile budgeting



service providers













Phase 4: Continuous Guided

Improvement

SAFe’s Inspect and adapt focuses on how

well ARTs are achieving their objectives.

Lean and flow thinking suggests focusing

on removing constraints and lowering

delays between steps

Methods are provided to:

• Improve team, DPT and ART formation

• Improve workflow

• Improve planning / flow methods

Phase 4: Use Guided Continuous Improvement

63

64

May 20


✓ For more information on Disciplined Agile go to https://disciplinedagileconsortium.org/

✓ For more information on the DA FLEX Playbook for SAFe go to portal.netobjectives.com/davsc

✓ To get involved, join the Disciplined Agile LinkedIn discussion group https://www.linkedin.com/groups/4685263/

65

https://disciplinedagileconsortium.org/

https://www.linkedin.com/groups/4685263/

al shalloway · 2020-05-27 · founder and former ceo of net objectives co-founder of lean-systems...

Documents