Empirical proces control

agile42 | We advise, train and coach companies building
software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
Empirical Process Control
An important but often overlooked aspect of agile product
development

Agenda
• Introduction
• Defined Process Control
• Hands-on
• material needed 5 pens/pencils + one A4 paper
• Empirical Process Control
• Cynefin Framework
• Applied to Scrum
• NUMMI a concept GM failed to copy

Niels Verdonk
Agile Coach
niels.verdonk@agile42.com

agile42 - The Agile Coaching Company
We make your agile transition succeed
agile42 has a proven approach to successful agile implementations. We support you with a
full range of coaching services and specialized trainings.
We work locally & worldwide
Connected coaching for international
teams
•Coaches across the globe
•Deliver consistently across internationally
distributed organizations
•Support different time zones
•Recognize cultural diversity.
Agile Transition
Agile change for the whole organization
•Transformation across entire organizations
•At individual, departmental and management
level
•Assessment
•Set goals and define strategy for change
•Guide organizations through the transformation
•While building knowledge for sustainability

Defined Process Control

Input -> Activity ->
Output
Production-based process

• Sequence of activity chains
• Input Activity Output➟ ➟
• Each activity requires specific skills

• Sequence of activity chains
• Input Activity Output➟ ➟
• Each activity requires specific skills
• Flow is pre-defined and predictable
• Time passed / time estimated = efficiency.
• Handoff after each activity, responsibility transfers to the next role

Empirical Game

G
am
e
Pencil Game
• Put the A4 paper in front of you and draw a circle like so:
• Take pens in one hand and close your eyes and let go
• With your eyes closed try to predict where they fell
• How many are completely outside the circle?
Needed: 5 Pens/Pencils and a sheet of A4 paper

G
am
e
Pencil Game
• Now repeat with your eyes open

G
am
e
Pencil Game
• Now repeat with your eyes open
• Try to change 1 thing to improve
• Now how many are completely outside the circle?

Experiment and
Analyze
R&D based approach

• Based based on empirical measurement
• Measure results in a defined interval of time
• Conduct Safe-to-Fail experiments
• Allows for stabilization and optimization
• While improving the outcome iteratively

• Based based on empirical measurement
• Measure results in a defined interval of time
• Conduct Safe-to-Fail experiments
• Allows for stabilization and optimization
• While improving the outcome iteratively
• Effective in unordered, complex systems
• With behavior which can’t be predicted upfront
• But retrospectively we can identify patterns in behavior

Cynefin Framework

Cynefin Framework
• Developed by Dave Snowden
as a sense making model
• Cynefin is a Welsh word, which
means 'habitat' or 'place’
• The true meaning is we all have
different pasts and
backgrounds
• The name describes the
evolutionary nature of complex
systems

Simple
Disorde
r
Cause and Effect relationship
exists, are predictable and
repeatable
Domains in a Nutshell

Simple
Complicated
Disorde
r
repeatable
exists, but are not self-evident,
analysis is required

Simple
ComplicatedComplex
Disorde
r
repeatable
Cause and Effect are only
obvious in hindsight, with
unpredictable emergent
outcomes.

Simple
ComplicatedComplex
Chaotic
Disorde
r
repeatable
Cause and Effect are only
obvious in hindsight, with
unpredictable emergent
outcomes.
No Cause and Effect can be
determined. We need to act
very quickly in order to stabilize
the system again.

Simple
Sense
Categorize
Respond
Cynefin Framework
Disorde
r

Simple
Complicated
Sense
Categorize
Respond
Sense
Analyze
Respond
Cynefin Framework
Disorde
r

Complex
Simple
Complicated
Sense
Categorize
Respond
Sense
Analyze
Respond
Probe
Sense
Respond
Cynefin Framework
Disorde
r

Complex
Simple
Complicated
Chaotic
Sense
Categorize
Respond
Sense
Analyze
Respond
Probe
Sense
Respond
Act
Sense
Respond
Cynefin Framework
Disorde
r

Empirical Process Control in Scrum

Software Development is Complex
• Software Development today is almost always in the Cynefin
Complex domain

Complex domain
• On a technical level we are dealing with:
• Various modules, gems, libraries, etc.
• Interaction with 3rd
party systems and services
• We are not repeating an existing known process

Complex domain
• On a technical level we are dealing with:
• Various modules, gems, libraries, etc.
• Interaction with 3rd
party systems and services
• We are not repeating an existing known process
• On a functional level we are dealing with:
• Changing requirements and priorities due to market changes
• We cannot predict the behavior of global internet users

Developer Insights
• In waterfall solutions are created upfront including detailed technical
design.
• In practice developers encounter imperfections in the technical design
• Also on a functional level things are not always accurate
• The results were that we needed to charge our clients extra (remember
CRs?)

Developer Insights
• In waterfall solutions are created upfront including detailed technical
design.
• In practice developers encounter imperfections in the technical design
• Also on a functional level things are not always accurate
• The results were that we needed to charge our clients extra (remember
CRs?)
• In Scrum cross functional experts work together to solve small
problems
• The problems defined in User Stories are solved collaboratively
• They can apply what they learned already in the next user story
• The technical design is emerging

Incremental Product Development
• An incremental process is not by definition an empirical approach
• You can still use Scrum to deliver a pre-defined software solution
• This has benefits, you will still deliver working software each Sprint
• But you cannot deal with changes in your market
• Or know how your pre-defined solution will be received by global users

Incremental Product Development
• An incremental process is not by definition an empirical approach
• You can still use Scrum to deliver a pre-defined software solution
• This has benefits, you will still deliver working software each Sprint
• But you cannot deal with changes in your market
• Or know how your pre-defined solution will be received by global users
• If you apply an empirical approach to Product Development
• Product Owners evaluate the delivered User Stories together with the team
• The Backlog can be re-prioritized accordingly and stories deleted or added
• We can work towards a Minimal Viable Release and validate it with our users
• We release sooner and incorporate the feedback to create a better products

Continuous Improvement of the Process
• After each Sprint we gather feedback on how team can work more
effective
• This allows us to continually improve the way we work
• We should inspire teams to try things, conduct safe-to-fail experiments
• Some experiments will be successful, they can incorporate this in the
process
• Some experiments will fail, and they can stop doing this

Continuous Improvement of the Process
• After each Sprint we gather feedback on how team can work more
effective
• This allows us to continually improve the way we work
• We should inspire teams to try things, conduct safe-to-fail experiments
• Some experiments will be successful, they can incorporate this in the
process
• Some experiments will fail, and they can stop doing this
• It’s vital for organizations to show their commitment to support teams
• By showing they are acting on organizational impediments outlined by
the teams.
• The progress on these items should be visible

Short story: NUMMI Factory

Toyota and GM partnered in the US
• The ideas behind Agile and Scrum come from Lean Manufacturing based on the
NUMMI plant in the US using the Toyota Production System (TPS).

NUMMI plant in the US using the Toyota Production System (TPS)
• Toyota was building high quality cars in Japan. In the US however GM had a terrible quality
track record rate and quality was poor. In the 80s GM closed down a factory in Fremont
with one of the poorest quality, and an unmotivated workforce

• When the US were going to increase import taxes on Japanese cars, they partnered with
GM to reopen the Fremont plant. They introduced TPS and trained the workforce. It was a
huge success

huge success
• What everyone considered strange was that Toyota would partner with GM, a competitor,
and allowed them to see the reasons for their success

huge success
• GM staff who had seen the plant in Fremont, tried to copy the process in their other plants.
They failed miserably! They only copied the outline of the plant, but failed to realize it was
the teamwork and the focus on continuous improvement which was the key!

huge success
• GM staff who had seen the plant in Fremont, tried to copy the process in their other plants.
They failed miserably! They only copied the outline of the plant, but failed to realize it was
the teamwork and the focus on continuous improvement which was the key!
• Moral of the story, implementing an empirical approach to continuous improvement is
hard, but key to the success of an agile implementation such as Scrum

Thank you :-)

Questions? & Answers!
For any further comment and or question, feel free to contact
us: netherlands@agile42.com
Further References:
agile42 Website http://www.agile42.com/
Cynefin Framework: http://www.cognitive-edge.com

Empirical proces control

More Related Content

What's hot

Similar to Empirical proces control

More from Niels Verdonk

Recently uploaded

Empirical proces control

Editor's Notes