heart of agile meets “risk reduction 2.0 … the heart...heart of agile collaborate deliver...

© Alistair Cockburn 2015

“Heart of Agile” meets “Risk Reduction 2.0 (Disciplined Learning)”

Dr. Alistair Cockburn http://Alistair.Cockburn.us


2

People ...

To an interpreter unforgiving of error

Making decisions every decision has economic consequences and resources are limited.

… they don’t understand which keeps changing

Deciding

… they don’t understand which keeps changing … they don’t understand which keeps changing


3

The Agile Manifesto invites wimpy-ness

"… Individuals and interactions over processes & tools…" (Yayy!! I don't have to follow those stupid processes any more!)

"… Working software over comprehensive documentation…"

(W00t!! Dump the documentation! I LOVE this agile stuff!) "… Customer collaboration over contract negotiations…"

(I'm done when I'm done and I never have to say when!) "… Responding to change over following a plan…"

(No plans! No project managers! No architects! )

Where do I sign up?


4 People develop skills in 4 stages


5

The Heart of Agile simplifies again

Collaborate

Deliver

Reflect

Improve


6

The Heart expands into Details

Learning Income

Collaboration

Trust

Experiment Change

Examine

Introspect

Collaborate

Deliver

Reflect

Improve

Business Social Technical

Cost Queues Early Revenue

Goals

Results

Include Emotions

Focus Forwards

Emotional Safety

Concretely (Solutions Focus)

Limit Changes

Aggressively

Allow failure

Let someone else do it

Step forward

Listen


7

Craft Professions

skills in a medium

Cooperative Game communication teamwork strategies

Knowledge Acquisition pay-to-learn trim-the-tail

Flow Management unvalidated decisions

= inventory, lean processes

Self-Awareness (Personalities) the people, strategies, techniques

actually used

Advanced Agile Development

origami courtesy of Gery Derbier


8

Use Lean Processes

for Flow Management


9

(Think about how many lines

of code testers get

handed at one moment!)

In software development, people wait on other people to make decisions

I wish they’d decide what style they want!

Users & Sponsors

Testers Business Analysts

I wish they’d decide what

functions they want!

A decision made by the user/sponsor to be used by the

UI designer I wish they’d decide

on the UI design already!

I wish they’d think a bit more carefully

before coding!

Programmers

Every line of code is a decision!

UI Designers


10

Users & Sponsors

Testers

Business Analysts

Programmers

UI Designers

Software = manufacturing if Inventory = Decisions!


11

A team’s optimal process and best strategies depend on its decision dependency network.

Users & Sponsors

absent

UI Designers

Business Analysts

some Programmers

Database designers

Tester

Enough Users & Sponsors

Many Business Analysts

Not enough Programmers Some

Testers

Enough Users & Sponsors

UI Designer

A few Business Analysts

Lots of Programmers

Single, solitary Database designer


12

Large-batch transfers (of decisions, in our case ) makes a system’s behavior harder to predict.

time

people

Vertical lines = queue length at any time

Horizontal lines = wait time in the queue

time

People arriving

People being served

people


13

Queuing theory shows that feed systems like these run more smoothly with small transfers

time

Vertical lines = queue length at any time

Horizontal lines = wait time in the queue

People arriving

People being served

time

people people


14

This applies when you choose to hand testers 1,000 lines of code to test, or 100 lines of code.

Hint: Prefer 100

time

Testers 100 lines of code show up for testing

Total # of design decisions being validated

Decisions being validated (or broken)

time

Testers 1,000 lines of code show up for testing

How long this line of code / screen / use case /

decision sits in the testing queue

How long this line of code / screen / use case /

decision sits in the testing queue

Decisions arriving


15

Users & Sponsors

UI Designers

Programmers Testers

Business Analysts

Convert jams

Users & Sponsors

UI Designers

Programmers Testers

Business Analysts

to continuous flow.

Reduce decisions in motion & balance the flow


16

Design is

Knowledge Acquisition


17

Delivers nearly no knowledge (or risk reduction)

Big-Bang Design is a late-learning strategy

time

Knowledge comes at the “moment of truth”: final integration.

cost

Growth of knowledge with big-bang integration


18

Development sequence indifferent (with respect to knowledge)

Delivers knowledge (risk reduction)

We can pay to learn early in the project

time

cost

Growth of knowledge with early, continuous integration


19

Develop for business value once risks are down

time

Knowledge growing (risk reduction)

cost

Business value growing

Reduce risks: - Business - Social - Technical - Cost / Schedule


20

Value

Knowledge / risk reduction

Three project stages: Risk, Value, Tail

time

Tail

risk value tail Item1 .. … ... item 2 . … .. item 3 .. … . item 4 .. .. . :


21

Trim to deliver on-time (or early)

Delay to get more or better

Payoff = Trim-the-Tail: Deliver by value or date


22

Craft Professions

skills in a medium

Cooperative Game communication teamwork strategies

Knowledge Acquisition pay-to-learn trim-the-tail

Flow Management unvalidated decisions

= inventory, lean processes

Self-Awareness (Personalities) the people, strategies, techniques

actually used

Designing in Teams

origami courtesy of Gery Derbier


23

Postscript: time to deliver a project

time = log( D (b..p) ) * N (u..p) * log( N (p) ) time to deliver a project =

distance between business owner & programmer (log)

* number of people between user & programmer

* number of programmers (log)


24

Heart of Agile

Collaborate

Deliver

Reflect

Improve

heart of agile meets “risk reduction 2.0 … the heart...heart of agile collaborate deliver...

Documents