Adap%ng	
  Agility:	
  Ge0ng	
  your	
  
Agile	
  Transforma%on	
  Unstuck	
  
Camille	
  Bell	
  
cbell@CamilleBellConsul...
Audience	
  
Some	
  Assump0ons	
  About	
  You:	
  	
  
•  You	
  have	
  read	
  agility	
  books	
  or	
  a8ended	
  tr...
Approach	
  
What	
  We’re	
  Going	
  to	
  Do:	
  	
  
•  Look	
  at	
  a	
  few	
  common	
  agile	
  transforma<on	
  ...
Issue	
  &	
  Mi<ga<on:	
  General	
  Template	
  
What:	
  
•  <general	
  problem	
  descrip<on>	
  
Impact:	
  	
  
•  ...
Issue:	
  Missing	
  Customer	
  
What:	
  
•  No	
  on-­‐site	
  customer	
  for	
  XP	
  
–  Scrum	
  Product	
  Owner	
...
Mi<ga<on:	
  Missing	
  Customer	
  
Customer	
  truly	
  overly	
  busy:	
  
•  Shadow	
  and	
  observe	
  customers	
  ...
Issue:	
  No	
  Single	
  Product	
  Owner	
  
What:	
  
•  Scrum	
  expects	
  a	
  single	
  Product	
  Owner	
  
•  But...
Mi<ga<on:	
  No	
  Single	
  Product	
  Owner	
  
Op<on	
  1:	
  	
  	
  Dividing	
  feature	
  allotment	
  by	
  ROI	
  ...
Mi<ga<on:	
  No	
  Single	
  Product	
  Owner	
  
(con<nued)	
  
Op<on	
  3:	
  	
  	
  Establish	
  Kanban	
  style	
  fe...
Issue:	
  User	
  Stories	
  are	
  Too	
  Big	
  
What:	
  
•  User	
  stories	
  should	
  be	
  small	
  enough	
  that...
Mi<ga<on:	
  User	
  Stories	
  are	
  Too	
  Big	
  
Split	
  big	
  stories	
  apart	
  into	
  many	
  small	
  stories...
Issue:	
  User	
  Stories	
  are	
  Too	
  Vague	
  
What:	
  
•  You	
  are	
  wri<ng	
  User	
  Stories	
  to	
  avoid	
...
Mi<ga<on:	
  User	
  Stories	
  are	
  Too	
  Vague	
  
User	
  Stories	
  didn’t	
  provide	
  enough	
  detail	
  to	
  ...
Customer	
  Collaborates	
  with	
  Dev	
  Team	
  on	
  
Confirma<on	
  of	
  Stories	
  
cbell@CamilleBellConsul0ng.com	
...
User	
  Stories	
  Confirmed	
  Through	
  	
  
Automated	
  Tests	
  During	
  Itera<on	
  
cbell@CamilleBellConsul0ng.com...
Issue:	
  High	
  Bug	
  Count	
  
What:	
  
•  You	
  have	
  a	
  con<nuing	
  stream	
  of	
  bugs	
  
•  Bug	
  count	...
Mi<ga<on:	
  High	
  Bug	
  Count	
  
Lack	
  of	
  understanding	
  of	
  end	
  user:	
  
•  Common	
  problem	
  in	
  ...
Issue:	
  Customers/POs	
  Never	
  Choose	
  
Technical	
  Stories	
  for	
  Next	
  Itera<on/Sprint	
  	
  
What:	
  
• ...
Mi<ga<on:	
  Customers/POs	
  Never	
  Choose	
  
Technical	
  Stories	
  for	
  Next	
  Itera<on/Sprint	
  	
  
Make	
  c...
Mi<ga<on:	
  Customers/POs	
  Never	
  Choose	
  
Technical	
  Stories	
  for	
  Next	
  Itera<on/Sprint	
  	
  
Customer	...
Mi<ga<on:	
  Customers/POs	
  Never	
  Choose	
  
Technical	
  Stories	
  for	
  Next	
  Itera<on/Sprint	
  	
  
cbell@Cam...
Mi<ga<on:	
  Customers/POs	
  Never	
  Choose	
  
Technical	
  Stories	
  for	
  Next	
  Itera<on/Sprint	
  	
  
Technical...
What:	
  
•  There	
  are	
  dozens	
  or	
  possibly	
  hundreds	
  stories	
  in	
  the	
  product	
  backlog	
  
•  Scr...
Mi<ga<on:	
  Customers/POs	
  Wont	
  Take	
  	
  
the	
  Time	
  to	
  Priori<ze	
  the	
  Backlog	
  
If	
  0me	
  is	
 ...
Mi<ga<on:	
  Customers/POs	
  Wont	
  Take	
  	
  
the	
  Time	
  to	
  Priori<ze	
  the	
  Backlog	
  
Progressive	
  tri...
Mi<ga<on:	
  Customers/POs	
  Wont	
  Take	
  	
  
the	
  Time	
  to	
  Priori<ze	
  the	
  Backlog	
  
cbell@CamilleBellC...
Issue:	
  Velocity	
  is	
  Con<nually	
  Slowing	
  Down	
  
What:	
  
•  New	
  user	
  stories	
  with	
  the	
  same	
...
Switching	
  between	
  three	
  one	
  week	
  tasks	
  means	
  	
  
none	
  	
  of	
  them	
  get	
  done	
  in	
  thre...
Mi<ga<on:	
  Velocity	
  is	
  Slowing	
  Down	
  
Task	
  switching:	
  
•  Set	
  strict	
  Work	
  in	
  Progress	
  Li...
cbell@CamilleBellConsul0ng.com	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  ...
Issue:	
  Too	
  Much	
  Work	
  in	
  Itera<on	
  Despite	
  
Story	
  Points	
  Matching	
  Prior	
  Velocity	
  
What:	...
Underes0mated	
  stories:	
  
•  If	
  poli<cal	
  pressure	
  is	
  causing	
  team	
  to	
  lower	
  es<mates,	
  stand	...
Mi<ga<on:	
  Too	
  Much	
  Work	
  in	
  Itera<on	
  	
  
Too	
  many	
  fire	
  fights:	
  
•  Avoid	
  fire	
  fights	
  if...
Issue:	
  Standup	
  Mee<ng	
  Take	
  Forever	
  
What:	
  
•  Standup	
  mee<ngs	
  are	
  supposed	
  to	
  be	
  short...
Mi<ga<on:	
  Standup	
  Mee<ng	
  Takes	
  Forever	
  
Team	
  members	
  focus	
  and	
  0me	
  management	
  is	
  poor:...
Mi<ga<on:	
  Standup	
  Mee<ng	
  Takes	
  Forever	
  
Team	
  is	
  too	
  large:	
  
Op<on	
  1:	
  	
  	
  Scrum	
  Sol...
Issue:	
  Standup	
  Mee<ngs	
  Don’t	
  	
  
Discuss	
  Real	
  Problems	
  
What:	
  
•  Standup	
  mee<ngs	
  are	
  sh...
Mi<ga<on:	
  Standup	
  Mee<ngs	
  Don’t	
  	
  
Discuss	
  Real	
  Problems	
  
Team	
  members	
  and	
  facilitator	
  ...
Issue:	
  Management	
  Doesn't	
  Value	
  
Removing	
  Impediments	
  Quickly	
  
What:	
  
•  Your	
  team	
  tells	
  ...
Mi<ga<on:	
  Management	
  Doesn't	
  Value	
  
Removing	
  Impediments	
  Quickly	
  
Management	
  is	
  new	
  to	
  th...
Mi<ga<on:	
  Management	
  Doesn't	
  Value	
  
Removing	
  Impediments	
  Quickly	
  
Middle	
  management	
  doesn’t	
  ...
Issue:	
  So	
  many	
  hoops	
  to	
  jump	
  through	
  
that	
  it	
  takes	
  forever	
  to	
  get	
  anything	
  done...
Mi<ga<on:	
  So	
  many	
  hoops	
  .	
  .	
  .	
  
Each	
  sub	
  group	
  is	
  a5emp0ng	
  to	
  locally	
  100%	
  op0...
Request	
  
Approve	
  	
  
&	
  	
  
Priori<ze	
  
Technical	
  
Assessment	
  
Code	
  	
  
&	
  	
  
Test	
  
Verify	
 ...
Request	
  
Approve	
  	
  
&	
  	
  
Priori<ze	
  
Technical	
  
Assessment	
  
Code	
  	
  
&	
  	
  
Test	
  
Verify	
 ...
•  Imagine	
  a	
  bridge	
  or	
  road	
  trying	
  to	
  carry	
  cars	
  on	
  100%	
  
of	
  its	
  surface	
  (any	
 ...
Don’t	
  Go	
  It	
  Alone	
  
Become	
  ac0ve	
  in	
  local	
  user	
  groups:	
  
•  Agile	
  Leadership	
  Network	
  ...
Camille	
  Bell	
  
Agile	
  Coaching	
  &	
  Consul<ng	
  
Retrospec<ves	
  
Agile	
  Boot	
  Camps	
  	
  
Agile	
  Trai...
Upcoming SlideShare
Loading in...5
×

Adapting Agility: Getting your Agile Transformation Unstuck

336

Published on

In this presentation, I explore many common Agile transformation issues and what you can do about them. I cover challenges with customers, technical process, organizational hurdles, prioritization, agile requirements, etc. Some of the topics include:

o No single Product Owner in Scrum.
o No on-site customer for Extreme Programming.
o The user stories are too big.
o The user stories are too vague.
o Bug count is going up or not going down.
o Customer/Stakeholders/PO never choose technical stories for next iteration/sprint.
o Customer/Stakeholders/PO won't take the time to prioritize their backlog.
o Even though story points match prior velocity, there seems to be too much work.
o Stand-up or Scrum meetings take forever.
o Stand-up or Scrum meetings are short, but no one talks about real problems.
o Management doesn't value removing impediments quickly.
o Velocity seems to be slowing down.
o So many hoops to jump through that it takes forever to get anything done.

Published in: Technology, Lifestyle
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
336
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Adapting Agility: Getting your Agile Transformation Unstuck

  1. 1. Adap%ng  Agility:  Ge0ng  your   Agile  Transforma%on  Unstuck   Camille  Bell   cbell@CamilleBellConsul0ng.com   Twi5er  @agilecamille   Agile  DC  2012                                                                                                                                                                                        October  23,  2012  
  2. 2. Audience   Some  Assump0ons  About  You:     •  You  have  read  agility  books  or  a8ended  training   •  You  manage,  lead,  coach  or  encourage  the  use  of  agile   prac<ces   •  You,  yourself,  are  agile   •  But  .  .  .      some%mes  things  could  be  going  be1er   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                    2  
  3. 3. Approach   What  We’re  Going  to  Do:     •  Look  at  a  few  common  agile  transforma<on  issues   •  Use  my  experience  and  that  of  some  other  agile  coaches   •  For  each  example  issue   –  Examine  the  What,  Impact    and  Why   –  Suggest  poten<al  Mi0ga0ons      (Things  to  Try)   •  Provide  a  template  to  examine  issues   What  We’re  Not  Going  to  Do:     •  Solve  all  Agile  issues   •  Provide  all  possible  solu<ons  for  any  issue   •  Promise  any  Silver  Bullets   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                      3  
  4. 4. Issue  &  Mi<ga<on:  General  Template   What:   •  <general  problem  descrip<on>   Impact:     •  <lesser  and  greater  impacts>     Why:   •  <likely  causes>   Mi0ga0on  (things  to  try  to  solve  problem):     •  <target  each  cause>  or   •  <some  general  op<ons  for  mul<ple  causes>  or   •  <both>   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                      4  
  5. 5. Issue:  Missing  Customer   What:   •  No  on-­‐site  customer  for  XP   –  Scrum  Product  Owner  is  undesignated  or  unavailable   Impact:     •  No  direc<on,  no  feedback      =>      WRONG  PRODUCT   Why:   •  On-­‐site  customers  are  more  the  excep<on  than  rule   •  Not  available  during  business  hours   –  Truly  overly  busy  -­‐  running  the  business,    on  market  room  floor   –  Physically  unavailable  (e.g.  in  ba8lefield,  space,  etc.)   –  Specula<ve  customer  doesn’t  yet  exist   –  Customer  doesn’t  see  value  in  <me  spent   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                      5  
  6. 6. Mi<ga<on:  Missing  Customer   Customer  truly  overly  busy:   •  Shadow  and  observe  customers   Customer  physically  unavailable:   •  Use  proxies  who  have  worked  in  customer  role   Real  customer  doesn’t  yet  exist:     •  Work  with  marke<ng  or  others  close  to  poten<al  customers   •  Create  customer  focus  groups   Customer  doesn’t  see  value  in  0me  spent:   •  Quickly  create  mini  app  based  on  best  guess  of  customer  values   (implement  one  or  two  small  features)   •  Demonstrate  to  customer  in  their  space  at  their  convenience   •  Get  feedback   •  Repeat  un<l  customer  becomes  involved   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                      6  
  7. 7. Issue:  No  Single  Product  Owner   What:   •  Scrum  expects  a  single  Product  Owner   •  But  you  have  many  customers   Impact:     •  No  priori<za<on,  wrong  priori<za<on  and/or  import  features   en<rely  neglected    =>      WRONG  PRODUCT   Why:   •  Complex  apps  have  many  types  of  users  with  different  needs   •  A  single  person  seldom  knows  all  user  roles  in  detail   •  A  single  person  can’t  weigh  compe<ng  needs  outside  his   exper<se   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                      7  
  8. 8. Mi<ga<on:  No  Single  Product  Owner   Op<on  1:      Dividing  feature  allotment  by  ROI   –  If  marke<ng  or  sales  can  determine  ROI  by  user  type   •  Give  each  Product  Owner  a  propor<onal  share  of  feature   development   Op<on  2:      Dividing  feature  allotment  evenly   –  If  you  can’t  determine  ROI  or  similar  weighted  value   •  Give  each  Product  owner  an  equal  share  of  feature   development   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                      8  
  9. 9. Mi<ga<on:  No  Single  Product  Owner   (con<nued)   Op<on  3:      Establish  Kanban  style  feature  input  queue   –  Set  a  Work  in  Progress  Limit   –  Let  each  Product  Owner  submit  a  story  to  the  queue   –  Let  POs  horse  trade  among  themselves  for  priority  queue   posi<oning   Op<on  4:      Establish  a  Chief  Product  Owner   –  Has  no  features  of  his  own;  only  priori<zes  other  POs’  features   –  Could  be  dedicated  agile  coach   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                      9  
  10. 10. Issue:  User  Stories  are  Too  Big   What:   •  User  stories  should  be  small  enough  that  several  can  be   completed  during  a  single  itera<on   •  But  your  customer’s  user  stories  take  weeks  to  complete   Impact:     •  Development  cadence  is  very  uneven   •  Es<ma<on  is  difficult  and  inaccurate   •  Comple<on  of  any  single  user  story  is  uncertain          =>      WRONG  PRODUCT  and/or  LATE  PRODUCT   Why:   •  Your  user  stories  are  complex,  compound  stories  including  many   features,  alterna<ve  flows,  mul<-­‐part  condi<onals,  tackle  all  levels   at  once  or  are  one  large  general  case   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  10  
  11. 11. Mi<ga<on:  User  Stories  are  Too  Big   Split  big  stories  apart  into  many  small  stories:   •  Spilt  many  featured  stories  into  separate  stories   •  Spilt  condi<onal  stories  with  “and”,  “or”,  “then”  or  other   connector  words  into  separate  stories.   •  Split  implied  condi<onal  stories  into  separate  stories  (e.g.  “process   all  credit  cards”  becomes  “process  American  Express”,  “process   Master  Card”,  “process  “VISA”,  etc.   •  Split  complex  alterna<ve  flow  stories  into  separate  main  flow   (happy  path)  and  mul<ple  alternate  flow  stories   •  Split  collec<on  stories  into  some  first  story  with  add  on  stories   •  Split  recursive  general  case  stories  first  into  a  base  case,  recursive   func<onality  becomes  separate  stories   •  Implement  the  simplest  stories  first   •  Refactor  out  commonali<es  between  stories  on  implementa<on   of  later  related  secondary  and  ter<ary  stories     cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  11   For more ideas see:  Bill  Wake’s  3  “20  Ways  to  Split  Stories”,    &  Mike  Cohen’s  “User  Stories  Applied”  
  12. 12. Issue:  User  Stories  are  Too  Vague   What:   •  You  are  wri<ng  User  Stories  to  avoid  requirements  bloat   •  You  even  ask  the  customer  ques<ons  as  you  go   •  But  when  you  demo,  you  discover  you  are  way  off  the  mark   Impact:     •  Incorrect  func<onality,    <me  wasted  correc<ng          =>      WRONG  PRODUCT  and/or  LATE  PRODUCT   Why:   •  User  Stories  didn’t  provide  enough  detail  to  implement   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  12  
  13. 13. Mi<ga<on:  User  Stories  are  Too  Vague   User  Stories  didn’t  provide  enough  detail  to  implement:   •  Cards  aren’t  enough:  Need  Jeffries  3  Cs*   –  Card:  the  User  Story  itself   –  Conversa<on:  talk,  repeat  what  the  customer  said  in  different  words,  get   feedback,  ask  clarifying  ques<ons  for  more  details,  challenge  your   assump<ons   –  Confirma<on:  automated  tests   •  Automated  tests  demand  precision   –  Given,  When,  Then  Cucumber  tests  are  very  good  for  high  level  ATDD,  BDD   –  If  possible  sit  down  with  customer  to  as  you  write  tests   –  Show  the  tests  to  customer   –  Drill  down  with  Rspec  or  Shoulda   –  Get  test  data  input  and  expected  results  from  customer   •  Run  the  tests  and  show  results  to  the  customer   –  Customer  may  think  of  something  he  forgot   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  13  Ref:  Ron  Jeffries  3  Cs  of  User  Stories  
  14. 14. Customer  Collaborates  with  Dev  Team  on   Confirma<on  of  Stories   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  14   User Story: Vetting Sighting In order to show confirmation of a sighting, As a US-CERT analyst, I want to mark a sighting a vetted • XYZ sighting is viewed by Charley US-CERT analyst • Charley marks  sigh<ng  as  ve8ed • Tracy from Treasury searches for sigh<ngs  ve8ed  today • Tracy sees XYZ as  a  confirmed  sigh<ng Ref:  Ron  Jeffries  3  Cs  of  User  Stories  
  15. 15. User  Stories  Confirmed  Through     Automated  Tests  During  Itera<on   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  15   • XYZ sighting is viewed by Charley US-CERT analyst • Charley marks  sigh<ng  as  ve8ed • Tracy from Treasury searches for sigh<ng  ve8ed  today • Tracy sees XYZ as  a  confirmed  sigh<ng User Story: Vetting Sighting In order to show confirmation of a sighting, As a US-CERT analyst, I want to mark a sighting a vetted describe ”Imports TEWI sightings" do context "a simple line item should know its name, quanity and price" do let(:purchase) { LineItem.new("1 book at 12.49") } it "should have a name of 'book'" do purchase.name.should == 'book' end it "should have a quanity of 1" do purchase.quantity.should == 1 end it "should have a price of 12.49" do purchase.price.should == 12.49 end end describe ”CERT analyst finds a recent TEWI sighting" do context "a simple line item should know its name, quanity and price" do let(:purchase) { LineItem.new("1 book at 12.49") } it "should have a name of 'book'" do purchase.name.should == 'book' end it "should have a quanity of 1" do purchase.quantity.should == 1 end it "should have a price of 12.49" do purchase.price.should == 12.49 end end describe ”Vets a sighting" do context "a simple line item should know its name, quanity and price" do let(:purchase) { LineItem.new("1 book at 12.49") } it "should have a name of 'book'" do purchase.name.should == 'book' end it "should have a quanity of 1" do purchase.quantity.should == 1 end it "should have a price of 12.49" do purchase.price.should == 12.49 end end describe ” Trusted partner finds un-vetted sighting" do context "a simple line item should know its name, quanity and price" do let(:purchase) { LineItem.new("1 book at 12.49") } it "should have a name of 'book'" do purchase.name.should == 'book' end it "should have a quanity of 1" do purchase.quantity.should == 1 end it "should have a price of 12.49" do purchase.price.should == 12.49 end end describe "Trusted partner finds vetted sighting" do context ”a vetted sighting should be clearly vetted" do before(:each) do new_sighting.build_from_TEWI() cert_user.new(‘default_cert’) new_sighting.vet(cert_user) new_partner.new(‘default_partner’) end it "should have a tag of ’vetted'" do new_sighting.tag.should_include == ’vetted' end it "should be viewable by partner" do new_sighting.accesable_by(new_partner).should == true end end
  16. 16. Issue:  High  Bug  Count   What:   •  You  have  a  con<nuing  stream  of  bugs   •  Bug  count  isn’t  going  down  and  may  be  going  up   •  Some  previously  fixed  bugs  show  up  again   Impact:     •  Unstable  product      =>      UNHAPPY  USERS,  BAD  PRESS,  PAYING   USERS  DEFECT  TO  OTHER  VENDORS   Why:   •  Lack  of  understanding  of  end  user   •  High  technical  debt   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  16  
  17. 17. Mi<ga<on:  High  Bug  Count   Lack  of  understanding  of  end  user:   •  Common  problem  in  early  product  life     –  Release  Beta  versions  to  prevent   –  Write  RED  test,  to  prevent  bug  recurrence  (TDD  prac<ce)  before  fixing  bugs   –  Help  Product  Owner  to  get  closer  to  customer   –  Follow  standard  usability  guidelines   •  If  usability  problems  persist,  you  may  be  building  the  wrong  product       High  technical  debt:   •  Common  problem  in  mid-­‐late  product  life   –  Write  RED  test,  to  prevent  bug  recurrence  (TDD  prac<ce)  before  fixing  bugs   –  Set  aside  a  li8le  <me  ever  itera<on  for  Refactoring   –  Target  code  to  refactor  each  itera<on  (metric_fu  gem  can  help)   –  Write  tests  as  safety  net  before  refactoring  code   –  Write  all  new  code  following  BDD  and  TDD  prac<ces   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  17  
  18. 18. Issue:  Customers/POs  Never  Choose   Technical  Stories  for  Next  Itera<on/Sprint     What:   •  User  Stories  are  wri8en  “As  a  <user>,  I  want  <feature>,  so  that  <value>”   •  Some  of  the  stories  are  have  a  strong  technical  focus   •  The  technical  stories  are  important   •  But  the  customer  never  selects  technical  stories   Impact:     •  No  technical  stories  chosen      =>      INCREASING  TECHNICAL  DEBT   •  Increasing  Technical  Debt              =>    SLOWER  NEW  FEATURE  DEVELOPMENT   •  Increasing  Technical  Debt              =>    INCREASING  BUG  COUNT   •  Increasing  Bug  Count                              =>  USER  DEFECTION  TO  OTHER  VENDORS   Why:   •  Customer  priori<zes  only  by  business  value   •  Technical  debt  doesn’t  seem  real  to  customer   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  18  
  19. 19. Mi<ga<on:  Customers/POs  Never  Choose   Technical  Stories  for  Next  Itera<on/Sprint     Make  con%nuous  technical  improvement    part  of  everyday   work  not  separate  stories:   •  Improving  your  code  base  shouldn’t  require  permission   –  You  don’t  need  permission  to  write  code,  compile  or  check  into  a  repository;   similarly  technical  improvement  is  part  of  every  techie’s  job   •  Every  <me  you  touch  code  that  needs  modifica<on  for  new  features,   improve  it  technically  as  well:   –  Add  acceptance,  unit,  integra<on  tests  to  the  code,  if  missing,  enhance   as  needed   –  With  passing  tests  in  place,  refactor  the  code  you  have  changed   •  But,  in  some  places,  the  poli<cal  culture  requires  a  different  approach            cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  19  
  20. 20. Mi<ga<on:  Customers/POs  Never  Choose   Technical  Stories  for  Next  Itera<on/Sprint     Customer  priori0zes  only  by  business  value:   •  The  customer  is  doing  the  right  thing  based  on  the  informa<on   available   •  All  stories  need  to  clearly  state  customer  value   •  The  format  of  the  user  story  is  part  of  the  problem.  Even  a   technical  story  must  include:   –  Business  value  not  technical  value   –  Some  business  user  not  a  technical  user   •  Instead  use  this  format:          “In  order  to  <business  value>,                As  a  <  business  user>,                I  want  <feature>”   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  20  
  21. 21. Mi<ga<on:  Customers/POs  Never  Choose   Technical  Stories  for  Next  Itera<on/Sprint     cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  21   Story: Refactor Big Ball of Mud As a programmer, I want to refactor the ”big ball of mud" code, So that the code is simpler Story: Faster Features / Cheaper Maintenance In order to deliver new features faster and lower maintenance costs, As a program manager <or other applicable business user>, I want the the ”big ball of mud" code refactored Value  last   Technical  user   No  clear  business  value   Value  first     Business  user   Clear  business  value  
  22. 22. Mi<ga<on:  Customers/POs  Never  Choose   Technical  Stories  for  Next  Itera<on/Sprint     Technical  debt  doesn’t  seem  real   to  customer:   •  Technical  debt  is  too  abstract   •  Find  a  way  to  make  the  tech  story   concrete   •  Where  possible,  visualize  debt   •  Or  measure  tech  debt  in  <me                     or  money     •  For  example,  to  visualize  a  big   refactoring  story:   –  Print  out  everything  that  needs   refactoring   –  Spread  it  out  where  everyone  can   see   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  22   Photo Ref:  Henrik  Knibergm  ”Lean  from  the  Trenches”  
  23. 23. What:   •  There  are  dozens  or  possibly  hundreds  stories  in  the  product  backlog   •  Scrum  says  the  Product  Owner  should  priori<ze  all  of  them  1,  2  …  etc.   •  That  isn’t  happening   Impact:     •  Worst  case:  No  priori<za<on,  wrong  priori<za<on              =>    IMPORTANT  FEATURES  NEGLECTED  while            =>    WASTING      TIME                                  and        MONEY     Why:   •  The  customer  has  limited  <me   •  The  customer  doesn’t  see  the  value  in  priori<zing  everything  in   numerical  order   Issue:  Customers/POs  Won’t  Take     the  Time  to  Priori<ze  the  Backlog   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  23  
  24. 24. Mi<ga<on:  Customers/POs  Wont  Take     the  Time  to  Priori<ze  the  Backlog   If  0me  is  limited  and  there  are  too  many  stories,      you  don’t  need  to  priori0ze  them  all:   •  Make  the  best  use  of  the  <me  the  customer  does  have   •  The  customer  may  be  right     –  If  you  have  hundreds  of  un-­‐priori<zed  user  stories,  priori<zing  them  all  is  a   waste  of  <me    Use  a  progressive  triage  to  find  top  stories   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  24  
  25. 25. Mi<ga<on:  Customers/POs  Wont  Take     the  Time  to  Priori<ze  the  Backlog   Progressive  triage  to  find  top  stories:   1.  Get  10  or  12  top  user  stories  in  priority  order  (or  skip  to  step  2)   –  Ask  the  customer  for  the  top  10  or  12  user  stories  (this  may  not  work)   –  Priori<ze  those  1,  2,  3  .  .  .   –  Implement  those  stories  and  ignore  the  rest  un<l  down  to  the  3  or  4  remaining   –  As  customer  to  select  and  priori<ze  few  more  top  stories  un<l  you  have  10  or  12   2.  Have  customer  divide  stories  into  High,  Medium  &  Low   –  Works  best  with  movable  cards  or  s<cky    notes   –  There  will  be  a  dispropor<onate  number  of  highs  (this  is  normal)   –  Remove  all  the  Medium  and  Low  stories   3.  Repeat  step  2  un<l  down  to  10  or  12  user  stories   4.  Priori<ze  those  1,  2,  3  .  .  .   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  25  
  26. 26. Mi<ga<on:  Customers/POs  Wont  Take     the  Time  to  Priori<ze  the  Backlog   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  26   High   Medium   Low   Backlog   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .   In  order  to  .  .  .   As  a  .  .  .   I  want  .  .  .  
  27. 27. Issue:  Velocity  is  Con<nually  Slowing  Down   What:   •  New  user  stories  with  the  same  complexity  /  story  points  take   longer  than  similar  older  user  stories   Impact:     •  Slower  feature  development          =>      INCREASED  DEVELOPMENT  COST  per  FEATURE              and            FEWER  FEATURES  or  LATE  PRODUCT   Why:   •  Task  switching   •  Change  in  staffing   •  Increasing  technical  debt   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  27  
  28. 28. Switching  between  three  one  week  tasks  means     none    of  them  get  done  in  three  weeks.   Week 1 Week 2 Week 3 Week 4 Task A Task B Task C Dev   completes   task  before   star<ng  next   one   Dev  switches   between  tasks   Ref:  Mary  and  Tom  Poppendieck  on  Lean  cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  28  
  29. 29. Mi<ga<on:  Velocity  is  Slowing  Down   Task  switching:   •  Set  strict  Work  in  Progress  Limits  to  prevent  task  switching   –  Recommended  Max  WIP  limit        =(  #  Developers  /  #  Developers  per  Story)  +  1  (  if  stories  get  blocked)   –  e.g.      XP  Team  of  6  Developers:  6/2  +  1  =  WIP  of  4   –  Lower  WIP  limit  further  may  have  benefits   Change  in  staffing:   •  Staff  turnover  slows  velocity  as  new  members  spin  up   •  Use  pair  programming,  etc.  to  spin  up  faster  and  lessen  Truck  Factor   •  Work  to  make  your  team  a  place  people  want  to  stay   Increasing  technical  debt:   •  Use  “High  technical  debt”  mi<ga<on  from  “High  Bug  Count”   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  29  
  30. 30. cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  30   Story  Board  with  WIP  Limits   Ref: Reconstructed Kanban board used at Yahoo Note: the absolute limit to the number of stories in progress at one time for each activity Note: only one Expedite story at a time -- no room for more!
  31. 31. Issue:  Too  Much  Work  in  Itera<on  Despite   Story  Points  Matching  Prior  Velocity   What:   •  The  es<mated  story  point  for  an  itera<on  are  iden<cal  to  prior  itera<ons   •  But  .  .  .  comple<ng  commi8ed  stories  is  hit  and  miss   •  And  .  .  .  the  team  when  the  team  misses,  the  team  misses  by  a  lot   Impact:     •  Missed  commitments        =>          LOST  TRUST,  LATE  PRODUCT   Why:   •  Underes<mated  stories   •  Some  stories  “too  small”  to  es<mate   •  Staff  availability  varies   •  Too  many  fire  fights   •  Change  in  staffing   •  High  technical  debt   •  Too  much  task  switching   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  31  
  32. 32. Underes0mated  stories:   •  If  poli<cal  pressure  is  causing  team  to  lower  es<mates,  stand  firm,  tell  the   truth  and  provide  op<ons  to  those  pressuring  the  team   –  Some<mes  it  is  very  hard  to  tell  management  or  business  how  much  work   something  is,  but  it  will  be  worse  when  your  team  doesn’t  deliver   –  Suggest  to  management  implemen<ng  best  value  split  first   Some  stories  “too  small”  to  es0mate:   •  Team  has  a  number  of  “0”  point  stories   –  e.g.  “fix  spelling  error”,    “change  font  size”,  “change  background  color”,  etc.   •  Individually  they  aren’t  worth  es<ma<ng,  but  together  they  add  up   –  Lump  a  similar  group  together,  un<l  worth  1,  2  or  3  story  points   Staff  availability  varies:   •  Some  variability  is  normal,  lower  commitments  accordingly   •  Remember  to  account  for  vaca<ons,  holidays,  training  and  other  predictable   staff  absences  (ask  every  itera<on,  don’t  assume  you  know)   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  32   Mi<ga<on:  Too  Much  Work  in  Itera<on    
  33. 33. Mi<ga<on:  Too  Much  Work  in  Itera<on     Too  many  fire  fights:   •  Avoid  fire  fights  if  you  can,  but  oven  you  can’t   •  Consider  using  Kanban  with  mul<ple  input  queues  to  handle,  Expedite,  Bug   Fixes,  New    Development  and  other  Levels  of  Service   •  If  “surprise”  work  is  seasonal  or  predictable,  lower  other  commitments  during   those  <mes   Change  in  staffing:   •  Use  “Staff  is  changing”  mi<ga<on  from  “Velocity  is  Slowing  Down”   Increasing  technical  debt:   •  Use  “High  technical  debt”  mi<ga<on  from  “High  Bug  Count”   Task  switching:   •  Use  “Task  switching”  mi<ga<on  from  “Velocity  is  Slowing  Down”   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  33  
  34. 34. Issue:  Standup  Mee<ng  Take  Forever   What:   •  Standup  mee<ngs  are  supposed  to  be  short;  usually  15   minutes  max   •  Your  standup  mee<ng  take  much,  much  longer   Impact:     •  Standup  is  dreaded,  poorly  a8ended,  not  held  daily   •  A8endees  space  out  missing  important  informa<on            =>  STANDUP  FAILS  PURPOSE,  WASTES  TIME   Why:   •  Team  members  focus  and  <me  management  is  poor   •  Management  and  others  hijack  standup   •  Team  is  too  large   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  34  
  35. 35. Mi<ga<on:  Standup  Mee<ng  Takes  Forever   Team  members  focus  and  0me  management  is  poor:   •  Remove  all  chairs  and  force  a  real  standup   •  Hold  mee<ng  daily  to  keep  it  short  and  <mely   •  Time-­‐box  mee<ng  and  each  speaker  with  <mers   •  Use  talking  s<ck   •  Un<l  team  gets  really  focused  limit  to  only  the  3  Ques<ons   •  Hold  break  out  sessions  averwards  (for  those  interested)  on   topics  you  had  to  halt  discussion  during  standup   Management  and  others  hijack  standup:   •  First  ensure  team  member  focus  (above)   •  Remind  others  that  standup  is  for  the  technical  team  only   •  Remind  observers  to  be  quiet,  if  they  interrupt   •  Deal  with  the  poli<cs   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  35  
  36. 36. Mi<ga<on:  Standup  Mee<ng  Takes  Forever   Team  is  too  large:   Op<on  1:      Scrum  Solu0on   –  Divide  technical  team  into  mul<ple  teams   •  Hold  separate  Scrum/Standup  for  each  team   •  Hold  Scrum  of  Scrums  to  roll  up  progress  &  impediments   Op<on  2:      Kanban/Scrumban  Solu0on   –  If  applicable,  divide  technical  team  into  mul<ple  teams   •  Hold  joint  Kanban  board  session  of  en<re  large  team   •  If  needed,  hold  separate  small  team  stand  ups  averwards   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  36  
  37. 37. Issue:  Standup  Mee<ngs  Don’t     Discuss  Real  Problems   What:   •  Standup  mee<ngs  are  short  and  follow  Scrum  rules   •  But  real  issues  aren’t  discussed   Impact:     •  Development  is  slowed  by  late  discovered  impediments  &  risks        =>      LATE  PRODUCT   Why:   •  Team  member  embarrassment,  lack  of  awareness,  etc.   •  Team  members  don’t  believe  underlying  problem  are  solvable   •  Facilitator  lacks  insight  into  hidden  road  blocks   •  Team  members  don’t  feel  comfortable  calling  each  other  on  behavior   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  37  
  38. 38. Mi<ga<on:  Standup  Mee<ngs  Don’t     Discuss  Real  Problems   Team  members  and  facilitator  need  non-­‐threatening  prac0ce  :   •  Read  up  on  Bill  Wake’s  “Scrum  from  Hell”  exercise     –  h8p://xp123.com/ar<cles/scrum-­‐from-­‐hell/   •  If  needed  invent  a  “neutral  example  app”  for  exercise     –  e.g.  resume  site,  travel  site,  etc.   –  Don’t  build  anything,  just  pretend   •  Choose  misbehavior  cards  that  highlight  teams  problems   –  e.g.  hidden  impediment,  not  answering  3  ques<ons,  etc.   –  Add  a  few  good  behavior  cards  to  deck   –  Add  unique  team  misbehavior  cards  if  needed     •  Run  “Scrum  from  Hell”  as  a  game  (about  15  minutes)   •  Reveal  cards  and  talk  about  experience   •  Repeat  periodically,  changing  Scrum  Master  and  team  roles  un<l   everyone  has  experience  with  different  roles  and  cards   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  38  
  39. 39. Issue:  Management  Doesn't  Value   Removing  Impediments  Quickly   What:   •  Your  team  tells  management  about  the  impediments  blocking  progress   •  But  .  .  .  li8le  is  done  and  what  is  done  happens  slowly   Impact:     •  Impediments  are  removed  slowly  or  not  at  all        =>      TEAM  PRODUCTIVITY  IS  A  FRACTION  OF  WHAT  IT  COULD  BE   Why:   •  Management  is  new  to  their  agile  role  of  road  block  remover   •  Management  unaware  of  the  impact  of  impediments  and  blockers   •  Middle  management  doesn’t  have  the  power  to  remove  blockers   •  Removing  some  impediments  do  take  a  long  <me  in  your  organiza<on   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  39  
  40. 40. Mi<ga<on:  Management  Doesn't  Value   Removing  Impediments  Quickly   Management  is  new  to  their  agile  role  of  road  block  remover:   •  Educate  your  management  team  on  Agility   –  If  possible  get  management  in  Scrum  Master  or  Kanban  training   –  Give  open  brown  bags  and  other  “byte  sized”  training   –  Offer  to  give  short  agile  presenta<ons  at  management  retreats   –  Speak  at  PMI  mee<ngs  (Scrum  especially  has  become  very  popular)   •  Coach  your  managers   Management  unaware  of  the  impact  of  impediments  and  blockers:   •  Use  burning  visibility   –  Post  Impediments  Lists  –  with  names  when  needed   –  Use  Kanban  boards  to  highlight  blocks   •  Keep  metrics  on  wait  <me   •  Show  impact  of  wai<ng  in  Time                                  and        Money     cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  40  
  41. 41. Mi<ga<on:  Management  Doesn't  Value   Removing  Impediments  Quickly   Middle  management  doesn’t  have  the  power  to  remove  blockers:   •  Gain  power  for  manager   –  Determine  what  blocks  your  manager  from  having  the  power  he  needs   –  Examine  official  (org  chart)  and  un-­‐official    (buddies  network)   –  Brainstorm  with  manager  to  determine  strategy  to  gain  needed  power   •  Go  around  the  system   –  “It’s  easier  to  ask  forgiveness  than  to  get  permission”  –  Admiral  Hopper   –  But  you  have  to  be  right  (and  not  illegal)   Removing  some  impediments  do  take  a  long  0me  in  your  organiza0on:   •  Problem  is  most  common  in  large  organiza<ons  with  <ers  of  compe<ng   managers,  too  many  checks  and  no  real  sense  of  balance   •  Use  all  mi<ga<ons  from  “So  Many  Hoops”  (next),  that  apply   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  41  
  42. 42. Issue:  So  many  hoops  to  jump  through   that  it  takes  forever  to  get  anything  done   What:   •  Your  company  has  many  departmental  teams  which  you  depend  on  and   which  depend  upon  one  another  for  equipment  and  services   •  Each  has  lengthy  and  complex  approval  processes   •  Each  has  overworked  staffs  and  long  wait  queues   Impact:     •  Extremely  poor  overall  efficiency  =>      LATE  PRODUCT   Why:   •  Each  sub  group  is  a8emp<ng  to  locally  op<mize  itself  to  100%  efficiency   •  Excessive  local  op<miza<on  harms  global  op<miza<on     •  No  charts  or  metrics  alert  the  CIO  of  the  magnitude  and  impact  of   queuing  delays   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  42  
  43. 43. Mi<ga<on:  So  many  hoops  .  .  .   Each  sub  group  is  a5emp0ng  to  locally  100%  op0mize  itself:   Excessive  local  op0miza0on  harms  global  op0miza0on:   •  Top  level  management  (e.g.  CIO,  etc.)  is  tracking  the  wrong   things  and  providing  the  wrong  incen<ves,  un<l  CIO  becomes   aware,  li8le  will  change   No  charts  or  metrics  alert  the  CIO  of  the  magnitude  and  impact  of    queuing  delays:   •  Track  wait  <mes,  create  Value  Stream  Maps  of  worst  problems  and   publish  findings  within  company   •  Educate  management  on  Lean,  Kanban,  Push  vs.  Pull  &  Value  Stream   •  Provide  metaphors  that  middle  and  top  management  relate  too   cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  43  
  44. 44. Request   Approve     &     Priori<ze   Technical   Assessment   Code     &     Test   Verify     &     Fix   Deploy   To   Verifica<on   To   Opera<ons   Form   sent  to   Queue   Form   sent  to   Queue   Form   sent  to   Queue   Weekly   Review   Wait  for   Architect   Wait  for   Developers   15  m   ½    w   5  m   2  w   15  m  2  m   2  w   3  h  45  m  1    w   2  h   3  m  15  m   6  w  +  4  h   Biweekly  Release   ½    w   2  h  +  40  m   1%     Efficiency   Using a Value Stream Map Big Delays are Reducible Ref:  Mary  and  Tom  Poppendieck  on  Lean  cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  44  
  45. 45. Request   Approve     &     Priori<ze   Technical   Assessment   Code     &     Test   Verify     &     Fix   Deploy   To   Verifica<on   To   Opera<ons   E-­‐mail   Tech  Lead   E-­‐mail   Supervisor   Assign   Developer   2    h   5  m   2  h   15  m  2  m   1  h   2  h   3  m  15  m   325  m   Developer  available   10    m   160  m   33%     Efficiency   15  m   Efficiency Radically Improved by Shortening Wait Queues Ref:  Mary  and  Tom  Poppendieck  on  Lean  cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  45  
  46. 46. •  Imagine  a  bridge  or  road  trying  to  carry  cars  on  100%   of  its  surface  (any  rush  hour  in  Washington,  DC)   Use Relatable Metaphor –  More  cars  push  to  get  on  the   bridge  than  it  can  possibly   handle   –  Cars  back  up  for  miles   –  The  rate  of  cars  crossing  the   bridge  is  very  low;  commutes   are  horrible   –  If  the  traffic  limited  itself  to   capacity  of  the  road  or  bridge   the  rate  of  cars  crossing  would   vastly  increase  and  commutes   improve   Ref: David J. Anderson - ”Kanban"cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  46  
  47. 47. Don’t  Go  It  Alone   Become  ac0ve  in  local  user  groups:   •  Agile  Leadership  Network  (meets  monthly  in  Tysons)   •  Technology  Specific  Groups   Read  about  several  agile  prac0ces:   •  Lean  &  Kanban   •  Scrum   •  eXtreme  Programming   A5end  conferences  and  training   Bring  in  consultants,  where  appropriate   Share  your  knowledge  and  experience     cbell@CamilleBellConsul0ng.com                                                                                                                                                                                                                                                                  47  
  48. 48. Camille  Bell   Agile  Coaching  &  Consul<ng   Retrospec<ves   Agile  Boot  Camps     Agile  Training   Updated  Slides   or  just  to  chat  about  things  agile   cbell@CamilleBellConsul0ng.com  

×