scaling agile with the lessons of lean product development flow

MN Half‐day Tutorial 6/3/2013 1:00 PM

"Scaling Agile with the Lessons of Lean Product Development Flow"

Presented by:

Alan Shalloway Net Objectives

Brought to you by:

340 Corporate Way, Suite 300, Orange Park, FL 32073 888‐268‐8770 ∙ 904‐278‐0524 ∙ [email protected] ∙ www.sqe.com

Alan Shalloway Net Objectives

With more than forty years of experience, the founder and CEO of Net Objectives Alan Shalloway is an industry thought leader in lean, kanban, product portfolio management, Scrum, and agile design. Alan helps companies transition enterprise-wide to lean and agile methods, and teach courses in these areas. He is the primary author of Lean-Agile Software Development: Achieving Enterprise Agility, Design Patterns Explained, Lean-Agile Pocket Guide for Scrum Teams, and Essential Skills for the Agile Developer. Cofounder and board member for the Lean Software and Systems Consortium, Alan is a popular speaker at prestigious conferences worldwide.

copyright 2012. Net Objectives, Inc. All Rights Reserved

Lean-Agile Project Manager 4/13/2013

1

© Copyright 2012 Net Objectives, Inc. All Rights Reserved 1

AgileLean

Scaling Agile with the Lessons of Lean Product Development Flow

Al Shalloway, CEO

Net Objectives




2


Lean Enterprise

Business

Management

Team

ASSESSMENTS

CONSULTING

TRAINING

COACHING

Lean Management

Project ManagementLean-Agile

Kanban / Scrum

ATDD / TDD / Design Patterns

technical process

Lean for Executives

Product Portfolio Management

Business Product Owner

Scaled Agile Framework


• The Foundations of Lean

• Lean-Agile Framework

• Case Studies

Achieving Enterprise Agility



3


Handling the cross-team technical and business dependencies of multiple teams

Creating enterprise wide architectures

Managing the workload of people who are required by several teams (this occurs due to any number of reasons but includes folks who have needed subject matter expertise, critical skills or rare knowledge of legacy code).

Coordinating multiple stakeholders with multiple teams

Aligning groups with disparate motivations

Quick Poll of Where People Are


thinkingpoints

Foundations of Lean

1. Systems thinking

2. Respecting people

3. Management provides leadership

• Understand the whole• Errors due to systems more than

people• Bad behavior systems induced• Good systems won’t guarantee good

results• Bad systems guarantee bad results• Need good systems and good people• Systems have patterns



4


The Scrum Model

Product Owner

Development Team & SM

Reflects Reality for One Product and One Team


Product Owners

Application Development teams & SMs

Stakeholders for multiple programs

Component Teams



5


Integration Team

Business Stakeholders

Development Teams

Inter-team dynamics are quite

different from intra-team dynamics


Scrum is often a good start to spin up Agile teams

It is not necessarily

a good start at

achieving Agility

across an

organization

But in any event, you can

leverage your investment



6


scaling Agile with Scrum alone is

ind

ivid

ua

l

te

am

s

te

am

of

te

am

s

… e

nt

er

pr

isefractal

faultyfragile

Intra-team behavior isNot the same as inter-team behavior


tog evaheW

sdrawkcabti

-edispudna

.nwod

We have got

it backwards

and upside-

down.



7


Complex systems still have patterns


different kinds

of predictability



8


which part of the airplane is responsible forflight?


Ops & Support

Customers

Shared Components

Shared Components

Product Related

Product Related

Product Related

SoftwareRelease

NewRequirements

Development

CustomerProduct Managers

Business LeadersRegional Coordinators

Trainers & Educators

Product Champion(s)

Capabilities

BusinessConsumption

Concept

The Software Development Value Stream

SoftwareProduct



9


Ops & Support

Customers

Shared Components

Shared Components

Product Related

Product Related

Product Related

SoftwareRelease

SoftwareProduct

NewRequirements

Development




Product Champion(s)

Capabilities

BusinessConsumption

Concept

How Blockages Occur in Value Stream

Not Using MMFs

Doesn’t Do Incremental

Development

Not Involved During Build

Not Involved

Poor Engineering

Practices

Too Many Selected

No Big Picture


defined

Lean Operations / Manufacturing

reduce cost of variation

empirical

Lean Product Development

low cost flexibility

Lean-Agile Software Developmentrealize business value faster

T Y P E S O F L E A N



10


AGILE provides framework and practices for producing increments of functionality

LEAN provides principles and practices which enable defining and prioritizing increments of highest business value

Inp

ut Business

PriorityBusinessPlanning

Business Staging

Ready to Pull

Iter

atio

n

0

IterativeDevelopment

IncrementalDeployment

Support & Feedback

LEAN KANBAN ITERATIVE AGILE


thinkingpoints

Foundations of Lean

1. Systems thinking



• People must self-organize• People understand their work best• Must also respect the nature of

people



11


thinkingpoints

Foundations of Lean

1. Systems thinking



• Vision• Big picture• Holistic


Let’s go back to

2001 when it (mostly)

all began



12


CONSIDER

• Agile paradigm not accepted

• Teams wanted to do it

• “laws” of Agile not understood

• Several beginning methods available

• XP

• Scrum

• Crystal


Scaling Agility

using methods that work at team level to get teams to

work together

Agility at Scale Focus on entire value

stream

Shortening cycle time

Avoid excessive WIP at

product level



13


thinkingpoints

Lean-Agile Framework

1. Drive From Business Value

2. Deliver Value as Soon as Possible

3. Organize for Value Delivery

4. Build Quality In

5. Make Everything Visible

6. Attend to Change

• Discover what is of value• Discover how to build it• Build it• Deploy it


Agility

Predictability

Business Value

and faster realization of

is where you have



14


You need Agility for:– Speed

Faster realization of Business Value

–ValueGet more (business value) from current resources (capacity)

–ProductivityHigher productivity of business value delivery (measurable)


Agilityis about

Business Value

Increments not

Development Cycles



15


Always

7%

Often

13%

Sometimes

16%

Rarely

19%

Never Used

45%

Source: Standish GroupStudy of 2000 projects at 1000 companies

Usage of Features and Functions in Typical System

WASTEand the

DELAY OF VALUE


focusing on the known, valuable features

gives greater certainty

produces greater value

lowers risk of mis-building and over-building

Deliver in Stagesw h e n p o s s i b l e



16



GROUP D ISCUSSION

Discovering what is valuable

or

Building and achieving it

Which is more important?



17


discover next increment

discover how to build it and implement it

realize it

BusinessValue

You cannot build the right thing

if you have not discovered it first!”“


thinkingpoints





4. Build Quality In


6. Attend to Change

• Create Minimal Business Increments• Sequence• Manage across the portfolio



18


First Release

Investment

Period

Payback

Period

Profit

Period

Breakeven

Cas

h flo

w

Time

economics of responsiveness

Mark Denne and Jane Cleland-Huang Software by Numbers


Staged Releases

First

Release

Invest-

ment

Period

Profit

Period

Pay-

back

Period

Cas

h flo

w

Time

Release 1 Net Return



19


Staged Releases

Profit

Period

Second

Release

Invest-

ment

Period

Pay-

back

Period


Cas

h flo

w

Time



Profit

Period

Investment

Invest-

ment

Period

Pay-

back

Period

Breakeven

Point

Total Return

Cas

h flo

w

Time

staged releases

Use Minimal Business Increments (MBI)(sometimes called MMFs, MVPs, MVFs, MMRs)



20


Business Evolution vs. System Evolution


Evolving the Business



21


Evolving the System


Incrementally Realizing Business Value

Evolving the System

What risks do these approaches lower?

risk

value

value

risk



22


Ideal / Pareto (80/20) Minimal Build Out / Roll Out

Waterfall ? Blend (Portfolio)

Business Value Realization Trends


Deliver in Stages when possible

Always build in Stages don’t build it if you

don’t know it’s of value



23


Business Backlog for STPProgram: No touch STP

High Low

Plan Setup Ent. Data Workflow Auto. STP

Bus Inc

Bus Inc

Bus Inc

Bus Inc

Bus Inc…

9 months

Plan Setup

Ent. Data

Workflow

Auto. STP

80% 10% 10%

6 months!

4 months

1 month of a dev team’s vs.

Realizing value 3 months sooner!


ACH(automated clearinghouse)

ACH is our electronic network to clear credit and debit transactions with other institutions

Primary Objective: By Year’s end, process 100% of all loans

Primary Objective: Reduce the number of checks required by 25%

Key Feature: 0.0001% error rate



24


Business Backlog for ACH

Loans Checks

Goal: 100% of Loans 25% Reduction in Checks

High Low



Loans Checks


High Low

Outbound Inbound Withdrawals Terminations

1 4 2 3



25


Business Capabilities for ACH

Outbound - Loans

Manage Bank Info

Redirect from chk to ACH

Bank Notify

Update Reconciliation

Cover Funds

Confirm ?

Analytics & Reporting

Web Call in

IVR Paper

BF - Web MMF – Web & Call in

• What are the businesscapabilities needed for ACH?

• What are the sources?• How can we group them

for highest value?



Loans Checks


High Low


1 4 2 3MMF

Web | Call in

BFIVR

BFPaper

Release 1 Release 2 Release 3



26


Web Call in

MMF – Web & Call in

User Story Manage banking info for a Web-initiated outbound ACH transaction

Outbound - Loans

Manage Bank Info

Redirect from chk to ACH

Bank Notify

Update Reconciliation

Cover Funds

Confirm ?

Analytics & Reporting

Business Features to User Stories



Loans Checks


High Low


1 4 2 3MMF

Web | Call in

BFIVR

BFPaper

Release 1 Release 2 Release 3

Manage Bank Info

Beware!

Building Manage Bank Info as a standalone component for everything is a system evolution!

Might be more efficient from an IT perspective, but it is NOT from a business value perspective!!!



27


Cost of Risk

ALWAYS DRIVE FROM BUSINESSVALUE

Cost of Delay

valu

e t

o t

he b

usi

ness

low

hig

h

release 1 release 4

time

High ROI


thinkingpoints





4. Build Quality In


6. Attend to change

• Hubs and Pods• Roles required



28


how much of what you do is

valuable?rework?


Getting

Requirements

Testing

Programming

Design

Integration

Planning

Collaboration

Re-doing

requirements

Working from old

requirements

“Fixing” bugs

“Integration”

errors

Deployment

Building

unneeded

features

Overbuilding

frameworks

What Work Do You Do?

TrainingDocumentation

Essentially

duplicating

componentsWhat percentage of your time do you spend on the left? Write it down.



29


1. Identify the actions taken in the value stream

Approv

eRequest Reqts Sign Off

Review Deploy

Analysis

Design Code Test


0.5 hrs 160 hrs8 hrs 8 hrs

120 hrs 280 hrs 240 hrs

100 hrs

8 hrs2 hrs

Approv

eRequest Reqts Sign Off

Review Deploy

Analysis

Design Code Test


2. What was the real time from start to finish of the action?



30


0.5 hrs 160 hrs8 hrs 8hrs

120 hrs 280 hrs 240 hrs

100 hrs

8 hrs2 hrs

Approve.1 / 7.9 hrs

Request0.5 / 0.0 hr

Reqts60 / 100 hrs

Sign Off1 / 7 hrs

Review 2 / 0 hrs

Deploy3 / 5 hrs

Analysis40 / 60 hrs

Design40 / 80 hrs

Code80 / 200 hrs

Test40 / 200 hrs



3. What was the average time working on this vs working on other things?



120 hrs 280 hrs 240 hrs

100 hrs

8 hrs2 hrs

320 hrs 80 hrs 320 hrs 80 hrs

80 hrs





4. Identify time between actions

Approve.1 / 7.9 hrs

Request0.5 / 0.0 hr

Reqts60 / 100 hrs

Sign Off1 / 7 hrs

Review 2 / 0 hrs

Deploy3 / 5 hrs

Analysis40 / 60 hrs

Design40 / 80 hrs

Code80 / 200 hrs

Test40 / 200 hrs



31

© Copyright 2012 Net Objectives, Inc. All Rights Reserved 6113 April 2013


120 hrs 280 hrs 240 hrs

100 hrs

8 hrs2 hrs






4. Identify time between actions

5. Identify any loop backs required

80 hrs

65% defective

Repeat 3X

20% rejected

Repeat 1X

Approve.1 / 7.9 hrs

Request0.5 / 0.0 hr

Reqts60 / 100 hrs

Sign Off1 / 7 hrs

Review 2 / 0 hrs

Deploy3 / 5 hrs

Analysis40 / 60 hrs

Design40 / 80 hrs

Code80 / 200 hrs

Test40 / 200 hrs


1. Identify the actions taken in the value stream2. What was the real time from start to finish of the action?3. What was the average time working on this vs working on other things?4. Identify time between actions5. Identify any loop backs required6. Calculate Process Cycle Efficiency:

Approve.1 / 7.9 hrs

Request0.5 / 0.0 hrs

Reqts60 / 100 hrs

Sign Off1 / 7 hrs

Review 2 / 0 hrs

Deploy3 / 5 hrs

Analysis40 / 60 hrs

Design40 / 80 hrs

Code80 / 200 hrs

Test40 / 200 hrs


120 hrs 280 hrs 240 hrs

100 hrs

8 hrs2 hrs



65% defectiveRepeat 3X

20% rejectedRepeat 1X

80 hrs

Approve.1 / 7.9 hrs


Reqts60 / 100 hrs

Sign Off1 / 7 hrs

Review 2 / 0 hrs

Deploy3 / 5 hrs

Analysis40 / 60 hrs

Design40 / 80 hrs

Code80 / 200 hrs

Test40 / 200 hrs

Avg Time Worked Total Cycle Time

0.5 hrs 160 hrs8 hrs 8 hrs

120 hrs 280 hrs 240 hrs

100 hrs

8 hrs2 hrs


160 hrs 80 hrs 80 hrs



80 hrs

80 hrs

PCE = = 14.9%509 hrs

3433 hrs

509 hrs

3433 hrs

Avg Time Worked Total Cycle Time



32


Approve.1 / 7.9 hrs


Reqts60 / 100 hrs

Sign Off1 / 7 hrs

Review 2 / 0 hrs

Deploy3 / 5 hrs

Analysis40 / 60 hrs

Design40 / 80 hrs

Code80 / 200 hrs

Test40 / 200 hrs


120 hrs 280 hrs 240 hrs

100 hrs

8 hrs2 hrs





80 hrs


160 hrs 80 hrs 80 hrs



80 hrs

80 hrs

3433 – 509 = 2924

Eliminating delays between what you do

Getting better at what you do

Which gives a better return?


Here’s a spot!

…and another!



33





34


Ops & Support

Customers

Shared Components

Shared Components

Product Related

Product Related

Product Related

SoftwareRelease

SoftwareProduct

NewRequirements

Development




Product Champion(s)

Capabilities

Business

Consumption

Concept


Consider the Software Value Stream

Managing

here Reduces

induced

waste here


Lean Enterprise

Business

Management

Team

MAKE

VALUE

FLOW



35


MAKE

INCREMENTAL DELIVERY

CREATIVE PROBLEM SOLVING

QUALITY BUILT INtechnical

Team

technical


technical

VALUE

PRIORITIZATION

BUSINESS ITERATIONS

RELEASE PLANNING

Business



36


technical

FLOW

Value Stream Visualization

Impediment Impact

Workflow as Process

ACCOUNTABILITY

Manage (limit) queues

Visual controls

Manage flow (process)

Management


Portfolios

Programs

Projects

Book of WorkRolling ReleasesLevels 1, 2, & 3

Program BacklogReleases

Multiple Teams

Product BacklogIterations

Whole Team

Lean

-Agi

le

Fram

ewo

rkSc

ale

d A

gile

Fr

amew

ork

Scru

m

Fram

ewo

rk

Executive,Business,

Management,& Team

Business,Management,

& Team

Business& Team Practices

Responsibilities Scale and ScopeToolsets Complexity



37


Lea n - Agi le Ro les

Business

Business Subject Matter ExpertBusiness Analyst

Focus GroupsUser Acceptance Testers

Lean-Agile PM (Scrum Master)Technical LeadDevelopersTestersSupport

Value Stream OwnerBusiness Sponsor

Stakeholders

CIOCTOTechnology Sponsor

Business Product OwnerBusiness Program Manager

Product Owner (Release)

Technology OwnerTechnology Delivery ManagerApplication Development Manager

HUB / MANAGEMENT

EXECUTIVE

POD / FRONT LINElevel 1

level 2

level 3

Lea n - Agi le Ro les

Technology


Value Stream Owner

Realize highest business value

Optimal cycle time from idea to realization

Business Sponsor Realize business value and ROI

Assigns BPO, Business Value Priority and Budget

Technology Sponsor

Technology and process to incrementally realize business value with quality solutions

Ensure holistic enterprise system integrity

Establish the technology boundaries for the organization

Stakeholders Business standards for the organization

P O R T F O L I O - R O L E S A N D R E S P O N S I B I L I T I E S

LEVEL 3 - EXECUTIVE



38


hubs organize delivery of value


H U B - R O L E S A N D R E S P O N S I B I L I T I E S


Prioritize & incrementally realize business value, ROI

Owns scope, timeline, and priority; assigns the PO

Product Owner (Release)

Owns scope, timeline, priority, and sequence to produce the assigned minimal value increment; Drives the Pods - continually prioritizes, defines and accepts what the Pod(s) are producing.

Technology Owner Technology, process and practices, and boundaries to iteratively produce business value increments

Business PM Visibility, Project administration and oversight on behalf of the Business.

TechnologyDelivery Manager

Flow: Continual, predictable, incremental delivery of quality solution(s)

Application Development Mgr

Technical Integrity: Extensibility & maintainability

Architecture & design; Development standards

LEVEL 2 - MANAGEMENT



39


Hubs: Application AreasHolistic Technical Integrity

Architecture

System Design

Policies – Readiness, Planning, Development, Test, & Deploy

Development Standards

Lean-Agile Process (Iterative & Kanban) & Process Control

Engineering Practices

Documentation

Technical ‘Debt’


pods deliver value



40


Lean-Agile PM (Scrum Master)

Visibility, transparency, coaching for Lean-agile Practices

Continuous incremental process improvement

Business Lead/SME

Acceptance criteria

Validation and implementation of business value increment

Whole Team Produce and implement quality business value increment(s)

Continuous incremental improvement

Whole team includes all skills necessary to produce a business value increment

Core: Business analyst, technical lead, application developers, QA testers, production support

P O D ( S ) - R O L E S A N D R E S P O N S I B I L I T I E S

LEVEL 1 – FRONT LINE


thinkingpoints





4. Build Quality In


6. Attend to Change

• QA is about preventing defects• Don’t build it if you don’t know it• It is not fail fast it is detect errors fast



41


DILBERT: © Scott Adams/Dist. by United Feature Syndicate, Inc.

© Copyright 2012 Net Objectives, Inc. All Rights Reserved 82_s

Customer: I need new

features yesterday

Devs hear: Get it done; Fast,

at all costs!

code base: Sloppy changes

code base: Increased complexity

code base: Increased defects

code base: Exponential

increase in time to add features



42

© Copyright 2012 Net Objectives, Inc. All Rights Reserved 83_s

Testers are overloaded

Testing occurs long after coding

Devs don’t get immediate feedback

Devs create more defects

Testers w/more workSystems w/more defects

further delays in feedback


True process efficiency = 7.8%



43


Finding defects is waste.

Preventing defects is essential”

“


Acceptance-centric

Continuous integration

Collaboration

Minimize technical debt

Minimize process waste

All process visible

LEAN THINKINGBuild Quality In



44



GROUP D ISCUSSION

What happens if we have poor quality?

What causes poor quality?

About Poor Quality



45


Example: Acceptance TDD

Standard

Hours

Hol/Sun

Hours

Wage Pay()

40 0 20

45 0 20

48 8 20

Basic Employee Compensation

Each week, hourly employees are paid

• A standard wage per hour for the first 40 hours worked

• 1.5 times their wage for each hour after the first 40 hours

• 2 times their wage for each hour worked on Sundays and holidays

Payroll.Fixtures.WeeklyCompensation


Example: Acceptance TDD

Standard

Hours

Hol/Sun

Hours

Wage Pay()

40 0 20 $800

45 0 20 $950

48 8 20 $1520

Basic Employee Compensation

Each week, hourly employees are paid

• A standard wage per hour for the first 40 hours worked

• 1.5 times their wage for each hour after the first 40 hours

• 2 times their wage for each hour worked on Sundays and holidays

Payroll.Fixtures.WeeklyCompensation



46


BEFORE

ITERATION

PLANNING

ITERATION

PLANNING

DEVELOPMENT

STORY

ACCEPTANCE

Acceptance Test Timeline

Product Ownerrefines stories & tests

Teamadd detail

Teamrefine testsget tests to pass Team

Add to regression test suite


Test-Later Test-First

Design the code "in your head" or

using design artifacts

Verify this structure mentally, if you

think of it, and have the time (how

do you “test” your design?)

Automated tests are hard to add

(code not always designed for

them)

Intentions are recorded separately

from the code

“Implementation-centric”

Analysis/design is done in the

context of acceptance tests,

written for each story.

Every aspect of the solution is

verified—quickly and repeatable

Code is designed to be inherently

testable from the beginning

Tests record intent and provide

examples

Tests give insight about design

quality

“Interface-centric”



47


New

Quality Assurance

the

proper role of

is preventing defectsand improving process

and




48


thinkingpoints





4. Build Quality In


6. Attend to Change

• Value stream• Explicit policies• Work being done


EXPONENTIALLY MORE WORK

working on multiple projects at same time induces



49


What We Think Willand What Does Happen

Rework

Overhead

Planned Work

Rework

Overhead

Planned Work

New Features

Cost of Interruptions


Time Available for New Features

Time to add new functionality

Years in future

Current

Time Spent Fixing Bugs Within and Across Systems

??? Years?

% o

f ca

pac

ity

Maximum capacity of the team



50


thinkingpoints





4. Build Quality In


6. Attend to Change

• Too much change can be worse than no change

• Attend to pilots• Lean-Agile Roadmap


T E L L I N G P E O P L E “ J U S T D O I T ”

J U S T D O E S N ’ T D O I T



51


Legacy Organization: Matrix Resources to Projects

Project 1

Project 2

Project 3

Project 4

Project N


Let’s Create a Pilot Project

Project 1

Project 2

%

Project 3

Project 4

Project N

Business Analyst, Architect, Usability Expert, Developer, Developer, Tester, Project Manager

Expert

Experience has shown that if you create a cross-functional co-located team you will improve 3x without changing your process.



52


Transitions Require Why and How

Understanding the why may get you started

Understanding the how will help overcome the fear

The perceived value must be greater than the fear


Enterprise Agility

Business

Management

Team

technical



53


Lean-Agile: Evolving Agility

Continually evolving

Sustaining, not improving

Declining MaturationA

gilit

y

Time (years)

Iterative Flow Highest Business Value

Low

∞

Lean Thinking

Business

MgmtTeam


Lean-Agile: Evolving Agility

Continually evolving

Sustaining, not improving

Declining MaturationA

gilit

y

Time (years)

Iterative Flow Highest Business Value

Low

∞Where are you currently?

TeamBusiness

Management



54


change the

management

system


change the

management

system

Should a company target its culture in its efforts to transform its production processes and all the [roles] associated with it?

It is tempting to answer: Yes!

But that would be a mistake.



55


change the

management

system

Culture is no more likely a target than the air we breathe. It is not something to target for change.

Culture is an idea arising from experience.


change the

management

system

The idea of the culture of a place or organization is a result of what we experience there. In this way, a company’s culture is a result of its management system.

Culture is critical.

To change it, you have to change the management system.



56


change the

management

system

Focus on the management system, on targets you can see: leaders’ behavior, specific expectations, tools, routine practices.

Lean production systems make this easier, because they emphasize explicitly defined processes and use visual controls.”


Lean-Agile Roadmap

• Where are you?

– Product initiation

– # products

• Culture

• Team structure

• Cross product / component dependencies

• Technical debt

• Level of testing



57


thinkingpoints

Case Studies

1. Agile Planning

2. Cross-functional Teams

3. Dynamic Feature Teams

4. Shared Backlogs

5. Product Management

• Focus on MBI• Pareto Vs Parkinson




58



thinkingpoints

Case Studies

1. Agile Planning



4. Shared Backlogs


• Self-organizing, cross-functional, teams

• Must attend to laws of software development



59


Team Organization

UI Team

Mid-tier Team

Database Team

UI Team

Mid-tier Team

Database Team

Team

1

Team

2

Team

3Cross-team cross-tribe collaboration is difficult.

Inter-tribal

Intra-tribal


thinkingpoints

Case Studies

1. Agile Planning



4. Shared Backlogs


• Principles trump practices• Swarm when possible



60


Background

Case Study: Military Aircraft

• 7 components on plane

• 70 person dev group (50 devs)

• 7 teams (4-10 each)

• 4 test platforms, 2 simulators, 1 plane

• Challenge was integration extremely

difficult


Dynamic Feature Teams



61


Resulting Savings

63% increase in throughput

42% decrease in defects

Greater than 22% savings* ($1.73M)

*Was thought to be higher but not claimed due to political reasons


thinkingpoints

Case Studies

1. Agile Planning



4. Shared Backlogs


• Self-organization across teams does not work

• Create a bigger team



62


Background

Case Study: Coordinating Teams

• Multiple teams

• Specialized

• Each team completed sprints in two weeks

…but value not delivered for months

…and then with challenges


Overall Team Organization

Product Line B applications

Component team for line B applications

System-Wide Component Team

Component team for line A applications

Product Line A applications



63


Teams on a Project

System-Wide Component Team

Product Line B applications

Component team for line B applications

Component team for line A applications

Product Line A applications


MBI

Split MBI

according to

Teams

Teams split according

to components

Teams work on

their parts Teams work on

their part until done

MBI

Eventually integrating

them together

Feedback times for:

Team

Across teams

Customer

Progress bar

2 weeks

6 weeks

8 weeks



64


Common Challenge

Common Guiding

Principle?


Principles to Guide Us

• Front of the Value Stream

– Value

– Minimal Marketable features

• Flow – making our teams efficient

– People work on one thing

– No delays in workflow

– People must pull work when

ready

– Work must be available to teams

in a coordinated fashion



65


PO

RT

FO

LI

OIn

pu

t BusinessPriority

BUSINESS DISCOVERY BUSINESS DELIVERY

BusinessPlanning

Business Staging

Ready to Pull

CONTEXT OF THE SOLUTION

DecisionHigh enough business value?

DecisionTechnically feasible, sufficient ROI?

Iter

atio

n

0

IterativeDevelopment

IncrementalDeployment

Support & Feedback

DecisionReady to release?

DecisionIs there capacity?

Define acceptance criteria and feature sequence

Build iteratively, deploy incrementally

Review business value , approve, and prioritize

Define value increments and sequence

Define product backlog

Iterative Development

Iterative Development

Iterative DevelopmentSh

ared

Bac

klo

g

Inte

grat

ion

Tra

in


MBI

Split MBI

into sub-features

Development teams split

according to components

Teams work on

their part

After one iteration, teams

integrate their components

MBI

Progress bar

Integration still required

but takes much less time

Feedback times for:

Team

Across teams

Customer

2 weeks

2 weeks

2 weeks



66


thinkingpoints

Case Studies

1. Agile Planning



4. Shared Backlogs


• Product Owner Role Limited• Cross Product View Needed


Case studyCoordinating Multiple Business Stakeholders with Multiple Team



67


The Simple Case

A1

A2

A1

1. Define Business capabilities

2. Create MMFs Team Product Backlog

A1dA2A

3. Prioritize MMFs

4. Create high level stories5. Assign to team backlog

Product Owners

Architecture / Technical Leads

A1cA1bA1a Team 1

Stakeholders Development teams


A Harder Case

A1

A2

A1


2. CreateMMFs

A1dA2A

3. Prioritize MMFs 4. Create high level stories

5. Assign to team backlogs

Product Owners

A2c


A1cA1bA1a

A2bA2a

Team Product Backlogs

Team 1

Team 2

Team 3

Team 4




68


Normal Problem – We Call it Tough

A

B

C

D

E



Team 1

Team 2

Team 3

Team 4

Product Owners



Product Owner Role Stretched too ThinTeam Product Backlogs

Team 1

Team 2

Team 3

Team 4

A

B

C

D

E

?

??

?

??

?

Product Owners do project management

Stakeholders can’t go to one source to see what to do

Teams have to coordinate with themselves


Product Owners




69


Product Managers and Product Owners

Product Managers

Product Owners


Team 1

Team 2

Team 3

Team 4

A

B

C

D

E


Product Manager: • represents the stakeholders•prioritizes MMFs•breaks MMFs into components

Product Owner: •acts as SME to team• represents team to product managers•breaks MMFs into components with Prod Mgrs•breaks components into stories

Architecture / Technical LeadsArchitects / Technical Leads• responsible for technical dependencies across teams•provide high level costs to Product Managers


Agile At Scale

A1

B1

C1A2

A1

B3

B2

B1

C2

C1


2. CreateMMFs

B1c

B2c

Blo

cked

B3c

A1dA2

B2B3

C2

A

B

C

3. Prioritize MMFs 4. Create high level stories

5. Assign to team backlogs


B1bB1a

A1cA1bA1a

B2bB2a

B3bB3a


Team 1

Team 2

Team 3

Team 4

Product Managers

Product Owners




70


Drive From Business ValueDeliver Value as Soon as PossibleOrganize for Value DeliveryBuild Quality InMake Everything VisibleAttend to Change

key points


Net Objectives’ Webinars

_s

Business & Agile Webinar Series – April – December 2013

An Introduction to Agile from a Business / Executive Point of View

Agile Implementations: Overviews of Scrum, Kanban, and Scrumban

How to Start an Agile Implementation

Team Kanban: Manifesting Lean at the Team Level

Enhancing and Extending Scrum With Lean

Patterns of Scaling Agile Across Teams

Patterns of Scaling Agile Across an Enterprise (will discuss the Scaled Agile Framework as well as our own Lean-Agile Roadmap

The Net Objectives Enterprise Agility Roadmap: Patterns of Successful Lean-Agile Adoption

Technical Agility Series

Technical Agility: What Design Patterns Were Made For

Emergent Design: The Practical Application of Design Patterns in the Agile World

Acceptance Test-Driven Development: An Essential Practice That Saves More Time Than It Takes

Sustainable Test-Driven Development: How to Have TDD Improve Your Designs and Tests Without Slowing You Down

See www.netobjectives.com/events to learn more

Register at www.netobjectives.com/register for slides & more

http://www.netobjectives.com/events

http://www.netobjectives.com/register



71

© Copyright 2012 Net Objectives, Inc. All Rights Reserved 141copyright © 2010 Net Objectives Inc.

Register at www.netobjectives.com/register

See www.netobjectives.com/resources

Contact me at [email protected]

Twitter tag @alshalloway

Thank You!


Lean Enterprise

Business

Management

Team

ASSESSMENTS

CONSULTING

TRAINING

COACHING

Lean for Executives



Scaled Agile Framework

Lean Management

Project ManagementLean-Agile

Kanban / Scrum

ATDD / TDD / Design Patterns

technical process

QUE S T I O N S?

For more info on free resources see:www.netobjectives.com/resources

http://www.netobjectives.com/register

http://www.netobjectives.com/resources

mailto:[email protected]

scaling agile with the lessons of lean product development flow

Technology

loansmanage bank inforedirect

evolving agilitycontinually evolvingsustaining

dynamic feature teams4

incrementally realize business

define business capabilities2

build quality in5

average time working

poor quality