agile way of dealing with uncertainty in a complex adaptive world

Post on 06-May-2015

5.204 Views

Category:

Technology

1 Downloads

Preview:

Click to see full reader

DESCRIPTION

It is human nature to look for patterns while solving new problems. We have a dangerous tendency to reuse what we already know to solve the next problem. We rarely discard what we've learned; we simply build on top of it. Sometimes this is a useful tactic, but often new problems and their context are slightly (if not vastly) different than the previous ones. And applying our previous way of doing things, will not be best suited for tackling the new problem. In the software world, we've seen a similar desire to find the "one true way", "the BEST method", "the silver bullet" to solve all software development problems. Alas, after decades of trying we've not found one. In this workshop, I'll let you discover why this is not possible and possibly explain how best to deal with this problem. This ideas in this workshop are based on my experience backed by latest research from Cognitive Science, Complex Adaptive System’s Theory and Evolutionary Psychology.

TRANSCRIPT

Naresh Jainnaresh@agilefaqs.com

twitter: @nashjain

http://nareshjain.com

1Saturday 1 September 2012

Agile Way of dealing with Uncertainty in a

Complex Adaptive World

Naresh Jainnaresh@agilefaqs.com

twitter: @nashjain

http://nareshjain.com

1Saturday 1 September 2012

Video on Selective Attention http://www.youtube.com/watch?v=vJG698U2Mvo

2Saturday 1 September 2012

Selec%ve  A)en%on

The  process  by  which  a  person  can  selec%vely  pick  out  one  s%mulus  from  a  mixture  of  s%muli  occurring  simultaneously.

3Saturday 1 September 2012

Which  line  is  the  longest?

1

2

3

4Saturday 1 September 2012

Which  line  is  the  longest?

1

2

3

Müller-Lyer optical illusion

4Saturday 1 September 2012

Which  Orange  Circle  is  bigger?

5Saturday 1 September 2012

Which  Orange  Circle  is  bigger?

Ebbinghaus optical illusion

5Saturday 1 September 2012

6Saturday 1 September 2012

Pet  Plant  Research  @  an  elderly  Nursing  Home

7Saturday 1 September 2012

Pet  Plant  Research  @  an  elderly  Nursing  Home

7Saturday 1 September 2012

Student  Volunteers  @  Nursing  Home

8Saturday 1 September 2012

Student  Volunteers  @  Nursing  Home

8Saturday 1 September 2012

Why?

9Saturday 1 September 2012

What  would  you  prefer?

A  lo)ery  %cket  with  a  random  number  

or  a  number  you’ve  picked?

10Saturday 1 September 2012

What  would  you  prefer?

In  the  Casino,  if  you  toss  the  dice  

or  someone  else  tosses  the  dice?

11Saturday 1 September 2012

What  would  you  prefer?

In  the  Casino,  if  you  toss  the  dice  

or  someone  else  tosses  the  dice?

Do you think it will make any difference?

11Saturday 1 September 2012

Illusion  of  Control

Our  desire  to  control  is  so  powerful  that  the  feeling  of  being  in  control  is  so  rewarding  that  people  oLen  act  as  though  they  can  control  the  uncontrollable.

12Saturday 1 September 2012

Electrical  Shock  Research

High  Volts  Shock  Group  vs.  Low  Volts  Shock  Group

 5  shocks  of  5  volts  each  vs.  3  shocks  of  2-­‐4  volts  each

Every  10  seconds  vs.  Random  %me  interval

13Saturday 1 September 2012

Electrical  Shock  Research

High  Volts  Shock  Group  vs.  Low  Volts  Shock  Group

 5  shocks  of  5  volts  each  vs.  3  shocks  of  2-­‐4  volts  each

Every  10  seconds  vs.  Random  %me  intervalWhich Group would have sweated more, whose heart beats would be faster and who claimed

to be more afraid?

13Saturday 1 September 2012

Uncertainty

14Saturday 1 September 2012

Uncertainty

Why?Our desire to Control

14Saturday 1 September 2012

How  do  we  deal  with  Uncertainty?

15Saturday 1 September 2012

How  do  we  deal  with  Uncertainty?

15Saturday 1 September 2012

How  do  we  deal  with  Uncertainty?

15Saturday 1 September 2012

How  do  we  deal  with  Uncertainty?

15Saturday 1 September 2012

How  do  we  deal  with  Uncertainty?

15Saturday 1 September 2012

Predictability  Paradox

16Saturday 1 September 2012

How to Organize a Children's Party?

A video by Dave Snowdenhttp://www.youtube.com/watch?v=Miwb92eZaJg

17Saturday 1 September 2012

18Saturday 1 September 2012

19Saturday 1 September 2012

Why is there only ONE Toyota or Apple today?

20Saturday 1 September 2012

Products & Processes are like haircutsCopying someone else’s rarely works

21Saturday 1 September 2012

Retrospec%ve  Coherence

22Saturday 1 September 2012

Retrospec%ve  Coherence

Hindsight does not lead to foresight!

22Saturday 1 September 2012

ME

23Saturday 1 September 2012

24Saturday 1 September 2012

Tech Talks!

25Saturday 1 September 2012

26Saturday 1 September 2012

Taking ownership of a simple process

Adapted from Jeff Patton

27Saturday 1 September 2012

The  Ball  Point  Game

28Saturday 1 September 2012

The  Ball  Point  Game

Your  goal:

As  a  team  predictably  "process"  the  most  number    of  balls  in  a  round  by  passing  a  ball  to  each  member

You  have  3  rounds  to  get  the  best  score  you  can

28Saturday 1 September 2012

The  Ball  Point  Game

Your  goal:

As  a  team  predictably  "process"  the  most  number    of  balls  in  a  round  by  passing  a  ball  to  each  member

You  have  3  rounds  to  get  the  best  score  you  can

Simple  structure:

Predict  the  number  of  balls  you  can  process

Pass  balls  for  2  minutes  (no  more,  no  less)

Take  2  minute  to  discuss  and  improve  your  strategy

28Saturday 1 September 2012

The  Ball  Point  Game

Your  goal:

As  a  team  predictably  "process"  the  most  number    of  balls  in  a  round  by  passing  a  ball  to  each  member

You  have  3  rounds  to  get  the  best  score  you  can

Simple  structure:

Predict  the  number  of  balls  you  can  process

Pass  balls  for  2  minutes  (no  more,  no  less)

Take  2  minute  to  discuss  and  improve  your  strategy

Simple  rules:

Everyone  must  touch  the  ball  for  it  to  be  “done”

The  ball  must  have  “air  %me”  -­‐  it  must  be  tossed  or  dropped  between  team  members

28Saturday 1 September 2012

Core  Agile  concepts  learned?

Adapted from Jeff Patton29Saturday 1 September 2012

Core  Agile  concepts  learned?

Ideal  processes  use  a  simple  framework  -­‐  like  a  game  

Adapted from Jeff Patton29Saturday 1 September 2012

Core  Agile  concepts  learned?

Ideal  processes  use  a  simple  framework  -­‐  like  a  game  

Changing  your  strategies  &  tac7cs,  not  the  framework,  allow  you  to  improve  

Adapted from Jeff Patton29Saturday 1 September 2012

Core  Agile  concepts  learned?

Ideal  processes  use  a  simple  framework  -­‐  like  a  game  

Changing  your  strategies  &  tac7cs,  not  the  framework,  allow  you  to  improve  

Process  improvement  comes  from  change  

Adapted from Jeff Patton29Saturday 1 September 2012

Core  Agile  concepts  learned?

Ideal  processes  use  a  simple  framework  -­‐  like  a  game  

Changing  your  strategies  &  tac7cs,  not  the  framework,  allow  you  to  improve  

Process  improvement  comes  from  change  

Skill  improvement  come  from  prac7ce  

Adapted from Jeff Patton29Saturday 1 September 2012

Core  Agile  concepts  learned?

Ideal  processes  use  a  simple  framework  -­‐  like  a  game  

Changing  your  strategies  &  tac7cs,  not  the  framework,  allow  you  to  improve  

Process  improvement  comes  from  change  

Skill  improvement  come  from  prac7ce  

Certain  kind  of  es%mates  improves  with  frequent  measurement  

Adapted from Jeff Patton29Saturday 1 September 2012

Core  Agile  concepts  learned?

Ideal  processes  use  a  simple  framework  -­‐  like  a  game  

Changing  your  strategies  &  tac7cs,  not  the  framework,  allow  you  to  improve  

Process  improvement  comes  from  change  

Skill  improvement  come  from  prac7ce  

Certain  kind  of  es%mates  improves  with  frequent  measurement  

Velocity  is  agile’s  language  for  measuring  throughput  

Adapted from Jeff Patton29Saturday 1 September 2012

Core  Agile  concepts  learned?

Ideal  processes  use  a  simple  framework  -­‐  like  a  game  

Changing  your  strategies  &  tac7cs,  not  the  framework,  allow  you  to  improve  

Process  improvement  comes  from  change  

Skill  improvement  come  from  prac7ce  

Certain  kind  of  es%mates  improves  with  frequent  measurement  

Velocity  is  agile’s  language  for  measuring  throughput  

Visibility  of  work  helps  us  make  improvement  decisions  

Adapted from Jeff Patton29Saturday 1 September 2012

Core  Agile  concepts  learned?

Ideal  processes  use  a  simple  framework  -­‐  like  a  game  

Changing  your  strategies  &  tac7cs,  not  the  framework,  allow  you  to  improve  

Process  improvement  comes  from  change  

Skill  improvement  come  from  prac7ce  

Certain  kind  of  es%mates  improves  with  frequent  measurement  

Velocity  is  agile’s  language  for  measuring  throughput  

Visibility  of  work  helps  us  make  improvement  decisions  

Reflec7on:  observing,  measuring  &  changing  is  the  means  for  process  improvement

Adapted from Jeff Patton29Saturday 1 September 2012

Core  Agile  concepts  learned?

Ideal  processes  use  a  simple  framework  -­‐  like  a  game  

Changing  your  strategies  &  tac7cs,  not  the  framework,  allow  you  to  improve  

Process  improvement  comes  from  change  

Skill  improvement  come  from  prac7ce  

Certain  kind  of  es%mates  improves  with  frequent  measurement  

Velocity  is  agile’s  language  for  measuring  throughput  

Visibility  of  work  helps  us  make  improvement  decisions  

Reflec7on:  observing,  measuring  &  changing  is  the  means  for  process  improvement

Team  work  is  an  individual  skill

Adapted from Jeff Patton29Saturday 1 September 2012

“Simple, clear purpose and principles give rise to complex

and intelligent behavior.

Complex rules and regulations give rise to simple

and stupid behavior.”

Dee Hock30Saturday 1 September 2012

Your  SoLware  Development  Game?

What  would  be:

Your  goal

Simple  structure

Simple  rules

31Saturday 1 September 2012

The  Agile  Game

Adapted from Jeff Patton32Saturday 1 September 2012

The  Agile  Game

Your  goal: As  a  team,  predictably  deliver  max  value  to  users  &  stakeholders

Adapted from Jeff Patton32Saturday 1 September 2012

The  Agile  Game

Your  goal: As  a  team,  predictably  deliver  max  value  to  users  &  stakeholders

Simple  structure:   As  a  team,  set  a  goal  &  plan  to  accomplish  the  work  

Deliver  working  solu%on  by  the  end  of  a  fixed  cycle  

Reflect  &  improve  your  Product,  Plan,  People  and  Process

Adapted from Jeff Patton32Saturday 1 September 2012

The  Agile  Game

Your  goal: As  a  team,  predictably  deliver  max  value  to  users  &  stakeholders

Simple  structure:   As  a  team,  set  a  goal  &  plan  to  accomplish  the  work  

Deliver  working  solu%on  by  the  end  of  a  fixed  cycle  

Reflect  &  improve  your  Product,  Plan,  People  and  Process

Simple  rules:Whole  team  works  together  &  takes  responsibility  for  the  outcome

Progress  and  quality  must  be  kept  visible

Finished  work  (working  solu%on)  is  the  only  measure  of  progress

Adapted from Jeff Patton32Saturday 1 September 2012

33Saturday 1 September 2012

Agile Origins

33Saturday 1 September 2012

SoLware  Engineering?

34Saturday 1 September 2012

SoLware  Engineering?

Crea%ng  SoLware  is  a  CraL.

Conver%ng  source  code  to  executable  is  the  engineering  bit.

34Saturday 1 September 2012

“Software Engineering is the application ofa systematic, disciplined, quantifiableapproach to development, operation andmaintenance of software: that is, theapplication of engineering to software.”

IEEE Standard Computer Dictionary,

ISBN 1-55937-079-3, 1990

IEEE  defines  SoLware  Engineering  as...

35Saturday 1 September 2012

Who  used  SoLware  Engineering?

36Saturday 1 September 2012

Who  used  SoLware  Engineering?

36Saturday 1 September 2012

For the space shuttle’s operating system37Saturday 1 September 2012

Some  Sta%s%csNASA’s  Defect  Density

38Saturday 1 September 2012

The  last  11  versions  of  the  space  shu)le’s  420,000  line  systems  had  a  total  of  17  

defects.  

Some  Sta%s%csNASA’s  Defect  Density

38Saturday 1 September 2012

The  last  11  versions  of  the  space  shu)le’s  420,000  line  systems  had  a  total  of  17  

defects.  

Some  Sta%s%csNASA’s  Defect  Density

38Saturday 1 September 2012

One  More  Data  Point

39Saturday 1 September 2012

One  More  Data  Point

39Saturday 1 September 2012

Another  real  soLware  engineering  project

40Saturday 1 September 2012

Safeguard - Ballistic Missile Defense System

Another  real  soLware  engineering  project

40Saturday 1 September 2012

1969-­‐1975,  5407  person  years

Hardware  designed  at  the  same  Ame  as  soBware  specs  being  wriDen

Late  changes  in  requirements  not  an  opAon

42

1820

20

reqmts20 %

design20 %

code &unit test

18 %

integrationtesting42 %

Safeguard - Ballistic Missile Defense System

Another  real  soLware  engineering  project

40Saturday 1 September 2012

1969-­‐1975,  5407  person  years

Hardware  designed  at  the  same  Ame  as  soBware  specs  being  wriDen

Late  changes  in  requirements  not  an  opAon

42

1820

20

reqmts20 %

design20 %

code &unit test

18 %

integrationtesting42 %

Safeguard - Ballistic Missile Defense System

Did it Succeed?

Another  real  soLware  engineering  project

40Saturday 1 September 2012

Safeguard  Ballis%c  Missile  Defense  System…

41Saturday 1 September 2012

Revised Project Statistics

Safeguard  Ballis%c  Missile  Defense  System…

41Saturday 1 September 2012

Revised Project StatisticsThe  project  was  delivered  according  to  specifica%ons  

Safeguard  Ballis%c  Missile  Defense  System…

41Saturday 1 September 2012

Revised Project StatisticsThe  project  was  delivered  according  to  specifica%ons  

Cost:  $25  Billion  (not  adjusted)

Safeguard  Ballis%c  Missile  Defense  System…

41Saturday 1 September 2012

Revised Project StatisticsThe  project  was  delivered  according  to  specifica%ons  

Cost:  $25  Billion  (not  adjusted)

1969-­‐1975,  5407  person  years

Safeguard  Ballis%c  Missile  Defense  System…

41Saturday 1 September 2012

Revised Project StatisticsThe  project  was  delivered  according  to  specifica%ons  

Cost:  $25  Billion  (not  adjusted)

1969-­‐1975,  5407  person  years

Operational for 133 days - Project terminated in 1978

Safeguard  Ballis%c  Missile  Defense  System…

41Saturday 1 September 2012

Revised Project StatisticsThe  project  was  delivered  according  to  specifica%ons  

Cost:  $25  Billion  (not  adjusted)

1969-­‐1975,  5407  person  years

‘By the time the 6-year anti-missile system project was completed, the new missiles were faster than the anti-

missile missiles’

Operational for 133 days - Project terminated in 1978

Safeguard  Ballis%c  Missile  Defense  System…

41Saturday 1 September 2012

Where do things go wrong?

42Saturday 1 September 2012

Requirements are stable

43Saturday 1 September 2012

Technology is well known and mature

44Saturday 1 September 2012

Everything goes as expected/planned

45Saturday 1 September 2012

We’ve a great deal of expertise having

done the same thing many times before

46Saturday 1 September 2012

Heavy weight methods work well when the previous

points are valid

47Saturday 1 September 2012

Projects with those characteristics are few

and far between.

48Saturday 1 September 2012

Heavy  Weight  Methodologies

49Saturday 1 September 2012

Heavy weight methodologies work in some instances, but there are high costs, and the risk in using them in dynamic environments is high.

Heavy  Weight  Methodologies

49Saturday 1 September 2012

The  Business  Case  for  Agile  Development

SucceededFailedChallenged

Chaos  Report  2006.  Standish  Group

We  need  to  do  be)er  than  this  ….

IT Projects

50Saturday 1 September 2012

Project  Overruns….

51Saturday 1 September 2012

Always7%

OLen13%

Some%mes16%

Rarely19%

Never45%

Standish  Group  study  reported  at  XP2002  by  Jim  Johnson,  Chairman

O@en  or  Always  Used:  20%

Rarely  or  NeverUsed:  64%

Feature  Use

52Saturday 1 September 2012

How  significant  is  requirements  change  on  a  project?  “The  average  project  has  30%  requirements  change”

Can  We  Predict  What  We  Need  ?

53Saturday 1 September 2012

Why Agile?

54Saturday 1 September 2012

Albert Einstein55Saturday 1 September 2012

Albert Einstein

A perfection of means, and confusion of aims, seems to be

our main problem.

55Saturday 1 September 2012

\ 56

Process  is  a  placebo

56Saturday 1 September 2012

\

Jared  spool’s  tricks  to  Dogma  conAnuum  arranges  terminology  from  improvisaAon  to  atrophy

56

Process  is  a  placebo

56Saturday 1 September 2012

Process is built on values and principles and tailored to fit its

context

Src: Jeff Patton57Saturday 1 September 2012

Src: Jeff Patton58Saturday 1 September 2012

Traditional cost profile

Lower  cost  of  change  curve

59Saturday 1 September 2012

Agile system cost profile

Traditional cost profile

Lower  cost  of  change  curve

59Saturday 1 September 2012

“I’m glad we’re all agreed then.”

Clear  communica%on  is  the  founda%on

60Saturday 1 September 2012

“Ah...”

Get  mental  models  out  on  the  table

61Saturday 1 September 2012

“Ah!”

Convergence  through  itera%on

62Saturday 1 September 2012

“I’m glad we’re all agreed then.”

A  genuinely  shared  understanding

63Saturday 1 September 2012

Tradi%onal  soLware  development  fixes  scope  then  es%mates  to  figure  out  %me  and  cost

Traditional software

development

Src: Jeff Patton64Saturday 1 September 2012

Tradi%onal  soLware  development  fixes  scope  then  es%mates  to  figure  out  %me  and  cost

Traditional software

development

Scope

Time Cost(resources)

Src: Jeff Patton64Saturday 1 September 2012

Tradi%onal  soLware  development  fixes  scope  then  es%mates  to  figure  out  %me  and  cost

Traditional software

development

Scope

Time Cost(resources)

Src: Jeff Patton64Saturday 1 September 2012

Tradi%onal  soLware  development  fixes  scope  then  es%mates  to  figure  out  %me  and  cost

Traditional software

development

Scope

Time Cost(resources)

Src: Jeff Patton64Saturday 1 September 2012

Agile  development  fixes  %me  and  cost,  then  leverages  itera%on  and  incremen%ng  to  maximize  scope  

Traditional software

development

Scope

Time Cost(resources)

Src: Jeff Patton65Saturday 1 September 2012

Agile  development  fixes  %me  and  cost,  then  leverages  itera%on  and  incremen%ng  to  maximize  scope  

Traditional software

development

Scope

Time Cost(resources)

Src: Jeff Patton65Saturday 1 September 2012

Agile  development  fixes  %me  and  cost,  then  leverages  itera%on  and  incremen%ng  to  maximize  scope  

Traditional software

development

Scope

Time Cost(resources)

Agile software development

Src: Jeff Patton65Saturday 1 September 2012

Agile  development  fixes  %me  and  cost,  then  leverages  itera%on  and  incremen%ng  to  maximize  scope  

Traditional software

development

Scope

Time Cost(resources)

TimeCost

(resources)

Agile software development

Src: Jeff Patton65Saturday 1 September 2012

Agile  development  fixes  %me  and  cost,  then  leverages  itera%on  and  incremen%ng  to  maximize  scope  

Traditional software

development

Scope

Time Cost(resources)

Scope

TimeCost

(resources)

Agile software development

Src: Jeff Patton65Saturday 1 September 2012

Leverage  a  shared  understanding  of  desired  product  goals  to  minimize  scope  while  maximizing  value

Traditional software

development

Scope

Time Cost(resources)

Scope

TimeCost

(resources)

Agile software development

Src: Jeff Patton66Saturday 1 September 2012

Leverage  a  shared  understanding  of  desired  product  goals  to  minimize  scope  while  maximizing  value

Traditional software

development

Scope

Time Cost(resources)

Scope

TimeCost

(resources)

Agile software development

Target business goals & outcomesSrc: Jeff Patton

66Saturday 1 September 2012

Building  Quality  into  the  Process

Toyoda Loom

67Saturday 1 September 2012

Source: Beyond Agile Software Development Becoming Lean, Mary Poppendieck, Poppendieck.llc

Utilization (%)

Focus  on  Throughput

68Saturday 1 September 2012

Tradi%onal  Process

69Saturday 1 September 2012

Tradi%onal  Process

69Saturday 1 September 2012

Applying  Lean  Principles  to  SoLware  Development

70Saturday 1 September 2012

End-to-End small slices of work

Applying  Lean  Principles  to  SoLware  Development

70Saturday 1 September 2012

End-to-End small slices of work 20 % done = 100 % usable

Applying  Lean  Principles  to  SoLware  Development

70Saturday 1 September 2012

Fix / Integrate $

Test

Code

DesignSpecifications

Use Cases / Functional Specs

Requirements Gathering

Project Plan/Estimation

$

Inception

$

$

$

Lean  Principles  applied  to  SoLware  Development  

71Saturday 1 September 2012

Itera%ve

Adapted from Jeff Patton

72Saturday 1 September 2012

Itera%ve

Adapted from Jeff Patton

72Saturday 1 September 2012

Itera%ve

Adapted from Jeff Patton

72Saturday 1 September 2012

Itera%ve

Adapted from Jeff Patton

72Saturday 1 September 2012

Incremental

Adapted from Jeff Patton

73Saturday 1 September 2012

Incremental

Adapted from Jeff Patton

73Saturday 1 September 2012

Incremental

Adapted from Jeff Patton

73Saturday 1 September 2012

Incremental

Adapted from Jeff Patton

73Saturday 1 September 2012

Itera%ve  AND  Incremental

Adapted from Jeff Patton

74Saturday 1 September 2012

Itera%ve  AND  Incremental

• Mix  the  strategies:–Iterate to  find  and  improve  soluAons

–Increment to  add  funcAonality  

Adapted from Jeff Patton

74Saturday 1 September 2012

Itera%ve  AND  Incremental

• Mix  the  strategies:–Iterate to  find  and  improve  soluAons

–Increment to  add  funcAonality  

Adapted from Jeff Patton

74Saturday 1 September 2012

Itera%ve  AND  Incremental

• Mix  the  strategies:–Iterate to  find  and  improve  soluAons

–Increment to  add  funcAonality  

Adapted from Jeff Patton

74Saturday 1 September 2012

Itera%ve  AND  Incremental

• Mix  the  strategies:–Iterate to  find  and  improve  soluAons

–Increment to  add  funcAonality  

Adapted from Jeff Patton

74Saturday 1 September 2012

Itera%ve  AND  Incremental

• Mix  the  strategies:–Iterate to  find  and  improve  soluAons

–Increment to  add  funcAonality  

Adapted from Jeff Patton

74Saturday 1 September 2012

AgileBirth of a new Software Movement!

75Saturday 1 September 2012

Agile  has  evolved  over  many  years

Src: Jeff Patton

76Saturday 1 September 2012

2000

77Saturday 1 September 2012

FDD | Feature Driven Development (Jeff DeLuca)

DSDM | Dynamic System Development Method (Dane Faulkner)

Adaptive Software Development (Jim Highsmith)

Crystal (Alistair Cockburn)

SCRUM (Ken Schwaber)

XP | Extreme Programming (Kent Beck)

Lean Software Development (Mary Poppendieck)

2000

77Saturday 1 September 2012

XP

Pragmatic

DSDM

Crystal Lean

Adaptive

Scrum

FDD

Agile

Agile  Umbrella

78Saturday 1 September 2012

Agile Manifesto

79Saturday 1 September 2012

Agile Manifesto

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

79Saturday 1 September 2012

Agile Manifesto

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

– Individuals and interactions OVER processes and tools.

79Saturday 1 September 2012

Agile Manifesto

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

– Individuals and interactions OVER processes and tools. – Working software OVER comprehensive documentation.

79Saturday 1 September 2012

Agile Manifesto

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

– Individuals and interactions OVER processes and tools. – Working software OVER comprehensive documentation. – Customer collaboration OVER contract negotiation.

79Saturday 1 September 2012

Agile Manifesto

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

– Individuals and interactions OVER processes and tools. – Working software OVER comprehensive documentation. – Customer collaboration OVER contract negotiation. – Responding to change OVER following a plan.

79Saturday 1 September 2012

Agile Manifesto

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

– Individuals and interactions OVER processes and tools. – Working software OVER comprehensive documentation. – Customer collaboration OVER contract negotiation. – Responding to change OVER following a plan.

That is, while there is value in the items on the right, we value the items on the left more.”

© 2001 Agile Alliance. http://www.agilemanifesto.org

79Saturday 1 September 2012

Agile Manifesto Principles

80Saturday 1 September 2012

Our highest priority is to satisfy the customer through early and

continuous delivery of valuable software.

81Saturday 1 September 2012

Welcome changing requirements, even late in development. Agile processes

harness change for the customer's competitive advantage.

82Saturday 1 September 2012

Deliver working software frequently, from a couple of

weeks to a couple of months, with a preference to the shorter

timescale.

83Saturday 1 September 2012

Business people and developers must work together daily

throughout the project.

84Saturday 1 September 2012

Build projects around motivated

individuals. Give them the environment

and support they need, and trust them to get the job done.

85Saturday 1 September 2012

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

86Saturday 1 September 2012

Working software is the primary measure of progress.

87Saturday 1 September 2012

Agile processes promote sustainable development. The

sponsors, developers, and users should be able to maintain a constant pace

indefinitely.

88Saturday 1 September 2012

Simplicitythe art of maximizing the amount of

work not doneis essential.

89Saturday 1 September 2012

Continuous attention to technical excellence and good design

enhances agility.

90Saturday 1 September 2012

The best architectures, requirements, and designs emerge

from self-organizing teams.

91Saturday 1 September 2012

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts

its behavior accordingly.

92Saturday 1 September 2012

It  turns  out...

93Saturday 1 September 2012

It  turns  out...

 Ziv's  law  -­‐  specifica%ons  will  never  be  fully  understood.

93Saturday 1 September 2012

It  turns  out...

 Ziv's  law  -­‐  specifica%ons  will  never  be  fully  understood.

 Humphrey's  law  -­‐  the  user  will  never  know  what  they  want  un%l  aLer  the  system  is  in  produc%on  (maybe  not  even  then)

93Saturday 1 September 2012

It  turns  out...

 Ziv's  law  -­‐  specifica%ons  will  never  be  fully  understood.

 Humphrey's  law  -­‐  the  user  will  never  know  what  they  want  un%l  aLer  the  system  is  in  produc%on  (maybe  not  even  then)

 Wegner's  lemma  -­‐  an  interac%ve  system  can  never  be  fully  specified  nor  can  it  ever  be  fully  tested.  

93Saturday 1 September 2012

It  turns  out...

 Ziv's  law  -­‐  specifica%ons  will  never  be  fully  understood.

 Humphrey's  law  -­‐  the  user  will  never  know  what  they  want  un%l  aLer  the  system  is  in  produc%on  (maybe  not  even  then)

 Wegner's  lemma  -­‐  an  interac%ve  system  can  never  be  fully  specified  nor  can  it  ever  be  fully  tested.  

 Langdon's  lemma  -­‐  soLware  evolves  more  rapidly  as  it  approaches  chao%c  regions  (taking  care  not  to  spill  over  into  chaos)

93Saturday 1 September 2012

It  turns  out...

 Ziv's  law  -­‐  specifica%ons  will  never  be  fully  understood.

 Humphrey's  law  -­‐  the  user  will  never  know  what  they  want  un%l  aLer  the  system  is  in  produc%on  (maybe  not  even  then)

 Wegner's  lemma  -­‐  an  interac%ve  system  can  never  be  fully  specified  nor  can  it  ever  be  fully  tested.  

 Langdon's  lemma  -­‐  soLware  evolves  more  rapidly  as  it  approaches  chao%c  regions  (taking  care  not  to  spill  over  into  chaos)

Any association of predictive or defined processes with Agile is an exercise in futility. - Jeff

93Saturday 1 September 2012

Treat  agile  principles  as  “proper%es”  you  use  to  assess  process  health

Performing  a  simple  process  health  checkup:  h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2  

94Saturday 1 September 2012

Treat  agile  principles  as  “proper%es”  you  use  to  assess  process  health

1. Frequent  delivery

Performing  a  simple  process  health  checkup:  h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2  

94Saturday 1 September 2012

Treat  agile  principles  as  “proper%es”  you  use  to  assess  process  health

1. Frequent  delivery

2. ReflecAve  improvement

Performing  a  simple  process  health  checkup:  h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2  

94Saturday 1 September 2012

Treat  agile  principles  as  “proper%es”  you  use  to  assess  process  health

1. Frequent  delivery

2. ReflecAve  improvement

3. Close  communicaAon

Performing  a  simple  process  health  checkup:  h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2  

94Saturday 1 September 2012

Treat  agile  principles  as  “proper%es”  you  use  to  assess  process  health

1. Frequent  delivery

2. ReflecAve  improvement

3. Close  communicaAon

4. Focus

Performing  a  simple  process  health  checkup:  h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2  

94Saturday 1 September 2012

Treat  agile  principles  as  “proper%es”  you  use  to  assess  process  health

1. Frequent  delivery

2. ReflecAve  improvement

3. Close  communicaAon

4. Focus

5. Personal  safety

Performing  a  simple  process  health  checkup:  h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2  

94Saturday 1 September 2012

Treat  agile  principles  as  “proper%es”  you  use  to  assess  process  health

1. Frequent  delivery

2. ReflecAve  improvement

3. Close  communicaAon

4. Focus

5. Personal  safety

6. Easy  access  to  experts

Performing  a  simple  process  health  checkup:  h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2  

94Saturday 1 September 2012

Treat  agile  principles  as  “proper%es”  you  use  to  assess  process  health

1. Frequent  delivery

2. ReflecAve  improvement

3. Close  communicaAon

4. Focus

5. Personal  safety

6. Easy  access  to  experts

7. Strong  technical  environment

Performing  a  simple  process  health  checkup:  h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2  

94Saturday 1 September 2012

Treat  agile  principles  as  “proper%es”  you  use  to  assess  process  health

1. Frequent  delivery

2. ReflecAve  improvement

3. Close  communicaAon

4. Focus

5. Personal  safety

6. Easy  access  to  experts

7. Strong  technical  environment

8. Sunny  day  visibility

Performing  a  simple  process  health  checkup:  h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2  

94Saturday 1 September 2012

Treat  agile  principles  as  “proper%es”  you  use  to  assess  process  health

1. Frequent  delivery

2. ReflecAve  improvement

3. Close  communicaAon

4. Focus

5. Personal  safety

6. Easy  access  to  experts

7. Strong  technical  environment

8. Sunny  day  visibility

9. Regular  cadence

Performing  a  simple  process  health  checkup:  h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2  

94Saturday 1 September 2012

Treat  agile  principles  as  “proper%es”  you  use  to  assess  process  health

1. Frequent  delivery

2. ReflecAve  improvement

3. Close  communicaAon

4. Focus

5. Personal  safety

6. Easy  access  to  experts

7. Strong  technical  environment

8. Sunny  day  visibility

9. Regular  cadence

10.High  energy

Performing  a  simple  process  health  checkup:  h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2  

94Saturday 1 September 2012

Treat  agile  principles  as  “proper%es”  you  use  to  assess  process  health

1. Frequent  delivery

2. ReflecAve  improvement

3. Close  communicaAon

4. Focus

5. Personal  safety

6. Easy  access  to  experts

7. Strong  technical  environment

8. Sunny  day  visibility

9. Regular  cadence

10.High  energy

11.Empowered  teams

Performing  a  simple  process  health  checkup:  h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2  

94Saturday 1 September 2012

Treat  agile  principles  as  “proper%es”  you  use  to  assess  process  health

1. Frequent  delivery

2. ReflecAve  improvement

3. Close  communicaAon

4. Focus

5. Personal  safety

6. Easy  access  to  experts

7. Strong  technical  environment

8. Sunny  day  visibility

9. Regular  cadence

10.High  energy

11.Empowered  teams

12.DisrupAve  change

Performing  a  simple  process  health  checkup:  h)p://www.s%ckyminds.com/s.asp?F=S15474_COL_2  

94Saturday 1 September 2012

Our  Team  Rooms

95Saturday 1 September 2012

Our  plans  looks  like  this

Source : ThoughtWorks

96Saturday 1 September 2012

some  more  plans…

97Saturday 1 September 2012

src: ThoughtWorks India98Saturday 1 September 2012

src: ThoughtWorks India

Work or Fun or Both?

99Saturday 1 September 2012

src: ThoughtWorks India

Work or Fun or Both?

99Saturday 1 September 2012

Agile Evolution

100Saturday 1 September 2012

XP

Pragmatic

DSDM

Crystal Lean

Adaptive

Scrum

FDD

Agile

Agile  Umbrella

101Saturday 1 September 2012

Agile  become...

XP

Agile

Scrum

102Saturday 1 September 2012

103Saturday 1 September 2012

Balance discovery with delivery

Delivery: building product right

Discovery: understanding the right product to

build

Src: Jeff Patton104Saturday 1 September 2012

Then  came  along...

XP

Agile

LeanAgile-UX

ProductDiscovery

Agile Ecosystem

Scrum

105Saturday 1 September 2012

High Level View of an Agile Process

Src: Jeff Patton106Saturday 1 September 2012

Then  came  along...

XP

Agile

Agile-UX

ProductDiscovery

Agile Ecosystem

ScrumLean

Kanban

107Saturday 1 September 2012

Where did Agile Originate?

Src: Jeff Patton108Saturday 1 September 2012

Problem

Solu

tion

Known Unknown

Kno

wn

Unk

now

n

Src: Eric Ries

Where  Agile  appears  to  work  best?

109Saturday 1 September 2012

Problem

Solu

tion

Known Unknown

Kno

wn

Unk

now

n

A g i

l e

Src: Eric Ries

Where  Agile  appears  to  work  best?

109Saturday 1 September 2012

Problem

Solu

tion

Known Unknown

Kno

wn

Unk

now

n

A g i

l e ??

Src: Eric Ries

Where  Agile  appears  to  work  best?

109Saturday 1 September 2012

Kaizen vs. Kaikaku

110Saturday 1 September 2012

Currently...

XP

Agile

LeanAgile-UX

ProductDiscovery

Dev-OPs

LeanStartup

AgileEcosystem

KanbanScrum

111Saturday 1 September 2012

The  Future

XPAgile

Agile-UX

ProductDiscovery

Dev-OPs

Lean Startup

Costumer Development

CDCD

ContinuousDelivery

MVP

Pivot

KanbanScrum Lean

112Saturday 1 September 2012

113Saturday 1 September 2012

Organizations have habits, and they will stick to their habits even at the risk of their own

survival.Brad Anderson, CEO, Best Buy

114Saturday 1 September 2012

Organizational structures have a short life... Nobody likes to reorganize, and you

always run the risk that you distract your employees and lose focus on customers.

But if you don't do it, you lose your competitive edge.

Nancy McKinstry, CEO, Wolters Kluwer

115Saturday 1 September 2012

116Saturday 1 September 2012

117Saturday 1 September 2012

Innovation

118Saturday 1 September 2012

Metrics Mess

119Saturday 1 September 2012

120Saturday 1 September 2012

Metrics MessKnowledge Islands

121Saturday 1 September 2012

122Saturday 1 September 2012

Be  careful  not  to…

Naresh Jainnaresh@agilefaqs.com

twitter: @nashjain

http://nareshjain.com

123Saturday 1 September 2012

Be  careful  not  to…

Naresh Jainnaresh@agilefaqs.com

twitter: @nashjain

http://nareshjain.com

Ques%ons?123Saturday 1 September 2012

Be  careful  not  to…

Naresh Jainnaresh@agilefaqs.com

twitter: @nashjain

http://nareshjain.com

Ques%ons?123Saturday 1 September 2012

top related