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 [email protected]


agile42 - The Agile Coaching CompanyWe 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 & worldwideConnected coaching for international teams

•Coaches across the globe•Deliver consistently across internationally distributed organizations•Support different time zones•Recognize cultural diversity.

Agile TransitionAgile 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


Game

Game

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


Game

Game

Pencil Game





• Now repeat with your eyes open




Game

Game

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

Disorder

Cause and Effect relationship exists, are predictable and

repeatable

Domains in a Nutshell


Simple

Complicated

Disorder


repeatable

Cause and Effect relationship exists, but are not self-evident, analysis is required



Simple

ComplicatedComplex

Disorder


repeatable


Cause and Effect are only obvious in hindsight, with unpredictable emergent

outcomes.



Simple

ComplicatedComplex

Chaotic

Disorder


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.



SimpleSense

CategorizeRespond

Cynefin Framework

Disorder


Simple

Complicated

SenseCategorizeRespond

SenseAnalyzeRespond

Cynefin Framework

Disorder


Complex

Simple

Complicated

SenseCategorizeRespond

SenseAnalyzeRespond

ProbeSense

Respond

Cynefin Framework

Disorder


Complex

Simple

Complicated

ChaoticSense

CategorizeRespond

SenseAnalyzeRespond

ProbeSense

Respond

ActSense

Respond

Cynefin Framework

Disorder


Cynefin Framework


Empirical Process Control in Scrum


Software Development is Complex

• Software Development today is almost always in the Cynefin 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 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

• They could actually be a topic in a Management Team meeting


Short story: NUMMI Factory


Toyota and GM partnered in the US

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



• The ideas behind Agile and Scrum come from Lean Manufacturing based on theNUMMI 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






• What everyone considered strange was that Toyota would partner with GM, a competitor, and allowed them to see the reasons for their 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!







• 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: [email protected]

Further References:

agile42 Website http://www.agile42.com/

Cynefin Framework: http://www.cognitive-edge.com

empirical proces control

Technology

increase import

unpredictable

lean manufacturing

3rd party

complexsoftware

effect relationship

a4 papergamepencil

dave snowden