Camille Bell, profile picture
Uploaded byCamille Bell
747 views

Adapting Agility: Getting your Agile Transformation Unstuck

The document discusses challenges in agile transformations, focusing on issues like missing on-site customers, lack of a single product owner, oversized or vague user stories, high bug counts, and difficulty in prioritizing technical stories. It offers various mitigation strategies for each issue to enhance agile practices, including improving customer involvement, breaking down user stories, and establishing clearer prioritization methods. The content emphasizes the importance of understanding user needs and integrating technical improvements into everyday work to reduce technical debt.

Embed presentation

Adap%ng  Agility:  Ge0ng  your   Agile  Transforma%on  Unstuck   Camille  Bell   cbell@CamilleBellConsul0ng.com   Twi5er  @agilecamille   Agile  DC  2012                                                                                                                                                                                        October  23,  2012  
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  
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  
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  
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  
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  
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  
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  
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  
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  
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”  
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  
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  
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  
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
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  
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  
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  
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  
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  
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  
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”  
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  
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  
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  
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  .  .  .  
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  
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  
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  
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!
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  
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    
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  
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  
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  
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  
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  
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  
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  
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  
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  
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  
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  
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  
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  
•  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  
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  
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  

More Related Content

PDF
An Introduction to Kanban
byCamille Bell
 
PDF
eXtreme Programming
byArtem Tabalin
 
PDF
Promoting Agility with Running Tested Features - Lightening Talk
byCamille Bell
 
PDF
Growing Manual Testers into Automators
byCamille Bell
 
PDF
Automate Debugging with git bisect
byCamille Bell
 
PDF
Testing for Agility: Bringing Testing into Everything
byCamille Bell
 
PDF
Inside Behavior Driven Development
byCamille Bell
 
PDF
Hey You Got Your TDD in my SQL DB by Jeff McKenzie
byQA or the Highway
 
An Introduction to Kanban
byCamille Bell
 
eXtreme Programming
byArtem Tabalin
 
Promoting Agility with Running Tested Features - Lightening Talk
byCamille Bell
 
Growing Manual Testers into Automators
byCamille Bell
 
Automate Debugging with git bisect
byCamille Bell
 
Testing for Agility: Bringing Testing into Everything
byCamille Bell
 
Inside Behavior Driven Development
byCamille Bell
 
Hey You Got Your TDD in my SQL DB by Jeff McKenzie
byQA or the Highway
 

What's hot

PPTX
Test Driven Development with Laravel
byTyler Johnston
 
PPTX
Testable requirements
byWyn B. Van Devanter
 
PDF
Anand Bagmar - Behavior Driven Testing (BDT) in Agile
byAnand Bagmar
 
PDF
Flexing your Agile Muscle - Agile Technical Concepts Explained
bySandy Mamoli
 
PDF
Introduction to TDD and BDD
byLuis García Castro
 
PPTX
Refactoring page objects The Screenplay Pattern
byRiverGlide
 
PDF
WE are Doing it Wrong - Dmitry Sharkov
byQA or the Highway
 
PDF
Test and Behaviour Driven Development (TDD/BDD)
byLars Thorup
 
PPTX
Selenium + Specflow
bycromwellryan
 
PDF
An Introduction To Software Development - Final Review
byBlue Elephant Consulting
 
PDF
How testers add value to the organization appium conf
byCorina Pip
 
PPTX
Westrich spock-assets-gum
byBrian Westrich
 
PDF
Tec314f
byJohn Art
 
PDF
Specification by Example - Agile India 2015
byAnkur Sambhar
 
PDF
Getting your mobile test automation process in place - using Cucumber and Cal...
byNiels Frydenholm
 
PDF
Automation testing in Agile project
byHien Nguyen
 
PPTX
Production code without tests
byAkim Khalilov
 
PPTX
Developer Testing
byChris Wallace
 
PPTX
I Don't Test Often ...
byGareth Bowles
 
ODP
Extreme Programming
byKnoldus Inc.
 
Test Driven Development with Laravel
byTyler Johnston
 
Testable requirements
byWyn B. Van Devanter
 
Anand Bagmar - Behavior Driven Testing (BDT) in Agile
byAnand Bagmar
 
Flexing your Agile Muscle - Agile Technical Concepts Explained
bySandy Mamoli
 
Introduction to TDD and BDD
byLuis García Castro
 
Refactoring page objects The Screenplay Pattern
byRiverGlide
 
WE are Doing it Wrong - Dmitry Sharkov
byQA or the Highway
 
Test and Behaviour Driven Development (TDD/BDD)
byLars Thorup
 
Selenium + Specflow
bycromwellryan
 
An Introduction To Software Development - Final Review
byBlue Elephant Consulting
 
How testers add value to the organization appium conf
byCorina Pip
 
Westrich spock-assets-gum
byBrian Westrich
 
Tec314f
byJohn Art
 
Specification by Example - Agile India 2015
byAnkur Sambhar
 
Getting your mobile test automation process in place - using Cucumber and Cal...
byNiels Frydenholm
 
Automation testing in Agile project
byHien Nguyen
 
Production code without tests
byAkim Khalilov
 
Developer Testing
byChris Wallace
 
I Don't Test Often ...
byGareth Bowles
 
Extreme Programming
byKnoldus Inc.
 

Viewers also liked

PPTX
Hyper V Sunum
byÇözümPARK
 
PDF
CARMELO TERESIANO - SALUDO PASCUAL 2015
byORDEN SEGLAR CARMELITAS DESCALZOS
 
DOC
Devendra Nw CV
byDevendra singh Rathore
 
PDF
Estructuracion
byuldech
 
DOCX
Christina Moore - Resume 05_2015
byChristina Moore
 
PPT
clase: ciudadanía digital y deberes y derechos del ciberciudadanos.
byvanessa ximena vega morales
 
PPTX
IMPORTANCIA DE LA ÉTICA Y LA MORAL
byAngelicacuzco
 
PPTX
Windows Server 2008 R2 Üzerinde Hyper-V ile Gelen Yenilikler
byÇözümPARK
 
PPTX
Présentation de DART TRAINING - #Edition10
byDigital Thursday
 
DOC
Explorando las redes wireless
byJorge Arroyo
 
PDF
diapositiva
byuldech
 
PPTX
Blogs 6
byanajbd27
 
PPTX
Exchange server 2007 mail server ugulamaları
byÇözümPARK
 
TXT
Leeame
byAriana Cosme
 
PDF
Implications for sparing, sharing and caring
byASB Partnership for the Tropical Forest Margins
 
PPTX
Blogs
byanajbd27
 
PDF
Vibhuti patel marathi translation gender budget in india arthasamvad 2005
byVibhuti Patel
 
DOCX
Pengertian evaporasi, kondensasi, dan tranperasi
byAgres Tarigan
 
DOCX
93645940 definisi-mineralogi-dan-mineral
byAgres Tarigan
 
Hyper V Sunum
byÇözümPARK
 
CARMELO TERESIANO - SALUDO PASCUAL 2015
byORDEN SEGLAR CARMELITAS DESCALZOS
 
Devendra Nw CV
byDevendra singh Rathore
 
Estructuracion
byuldech
 
Christina Moore - Resume 05_2015
byChristina Moore
 
clase: ciudadanía digital y deberes y derechos del ciberciudadanos.
byvanessa ximena vega morales
 
IMPORTANCIA DE LA ÉTICA Y LA MORAL
byAngelicacuzco
 
Windows Server 2008 R2 Üzerinde Hyper-V ile Gelen Yenilikler
byÇözümPARK
 
Présentation de DART TRAINING - #Edition10
byDigital Thursday
 
Explorando las redes wireless
byJorge Arroyo
 
diapositiva
byuldech
 
Blogs 6
byanajbd27
 
Exchange server 2007 mail server ugulamaları
byÇözümPARK
 
Leeame
byAriana Cosme
 
Implications for sparing, sharing and caring
byASB Partnership for the Tropical Forest Margins
 
Blogs
byanajbd27
 
Vibhuti patel marathi translation gender budget in india arthasamvad 2005
byVibhuti Patel
 
Pengertian evaporasi, kondensasi, dan tranperasi
byAgres Tarigan
 
93645940 definisi-mineralogi-dan-mineral
byAgres Tarigan
 

Similar to Adapting Agility: Getting your Agile Transformation Unstuck

KEY
Rapid Release Planning
byAgileDad
 
PDF
Certified Scrum Product Owner Training
byguest74599
 
PDF
Agile2009 - How to sell a traditional client on an Agile project plan
byOpenSource Connections
 
POTX
Agile Teams
byHammad Ahmad
 
KEY
Writing GREAT Agile User Stories
byAgileDad
 
PDF
Agile Software Development Overview
byStewart Rogers
 
PPT
Agile
byabsvis
 
KEY
Selling Agile
byPaul Klipp, paul@paulklipp.com
 
PPTX
WinSmart Technologies
bybijunairk
 
DOCX
Agile Product Management, Agile methodologies and development
byPabitha Chidambaram
 
PPTX
Agile for product owners v12
byRavi Tadwalkar
 
PPTX
Intro to Agile
byCătălina Movileanu
 
PDF
Managing international software projects interactively using scrum
byPeter Horsten
 
PDF
AT2012_Pune_LessonsfromaSuccessfulPO_rathinakumar
byIndia Scrum Enthusiasts Community
 
PPTX
Keeping Product Backlog Healthy
byDhaval Panchal
 
PDF
Winning clients' trust with Agile project management
bycameronandwilding
 
PPT
Product management class rookie to pro
byBim Akinfenwa
 
PDF
Agile Intro for FCL
byjabizz
 
PDF
Agile estimation and planning by bachan anand ( sep 10th)
byConscires Agile Practices
 
PDF
Selling lean development
bywozmir
 
Rapid Release Planning
byAgileDad
 
Certified Scrum Product Owner Training
byguest74599
 
Agile2009 - How to sell a traditional client on an Agile project plan
byOpenSource Connections
 
Agile Teams
byHammad Ahmad
 
Writing GREAT Agile User Stories
byAgileDad
 
Agile Software Development Overview
byStewart Rogers
 
Agile
byabsvis
 
Selling Agile
byPaul Klipp, paul@paulklipp.com
 
WinSmart Technologies
bybijunairk
 
Agile Product Management, Agile methodologies and development
byPabitha Chidambaram
 
Agile for product owners v12
byRavi Tadwalkar
 
Intro to Agile
byCătălina Movileanu
 
Managing international software projects interactively using scrum
byPeter Horsten
 
AT2012_Pune_LessonsfromaSuccessfulPO_rathinakumar
byIndia Scrum Enthusiasts Community
 
Keeping Product Backlog Healthy
byDhaval Panchal
 
Winning clients' trust with Agile project management
bycameronandwilding
 
Product management class rookie to pro
byBim Akinfenwa
 
Agile Intro for FCL
byjabizz
 
Agile estimation and planning by bachan anand ( sep 10th)
byConscires Agile Practices
 
Selling lean development
bywozmir
 

More from Camille Bell

PDF
Kata Your Way to SW Craftsmanship
byCamille Bell
 
PDF
What They Didn't Tell You in CSM Clas
byCamille Bell
 
PDF
What CS Class Didn't Teach About Testing
byCamille Bell
 
PDF
Remote Mob Programming
byCamille Bell
 
PDF
Software Craftsmanship Workshop
byCamille Bell
 
PDF
Promoting Agility with Running Tested Features - Paper
byCamille Bell
 
Kata Your Way to SW Craftsmanship
byCamille Bell
 
What They Didn't Tell You in CSM Clas
byCamille Bell
 
What CS Class Didn't Teach About Testing
byCamille Bell
 
Remote Mob Programming
byCamille Bell
 
Software Craftsmanship Workshop
byCamille Bell
 
Promoting Agility with Running Tested Features - Paper
byCamille Bell
 

Recently uploaded

PDF
Lets Build a Serverless Function with Kiro
byChris Bingham
 
PDF
[BDD 2025 - Mobile Development] Mobile Engineer and Software Engineer: Are we...
bywintari3
 
PDF
Transforming Content Operations in the Age of AI
byEnterprise Knowledge
 
PDF
PCCC25（設立25年記念PCクラスタシンポジウム）：エヌビディア合同会社 テーマ２「NVIDIA BlueField-4 DPU」
byPC Cluster Consortium
 
PPTX
MuleSoft AI Series : Introduction to MCP
byMulesoftMunichMeetup
 
PDF
Mulesoft Meetup Online Portuguese: MCP e IA
byPedro Baroni
 
PDF
ODSC AI West: Agent Optimization: Beyond Context engineering
byShashikant Jagtap
 
PDF
MuleSoft Meetup: Dreamforce'25 Tour- Vibing With AI & Agents.pdf
byTintu Jacob Shaji
 
PDF
[BDD 2025 - Artificial Intelligence] AI for the Underdogs: Innovation for Sma...
byWintari Yasmin
 
PPTX
UFCD 0797 - SISTEMAS OPERATIVOS_Unidade Completa.pptx
byscribddobruno
 
PDF
[BDD 2025 - Full-Stack Development] Agentic AI Architecture: Redefining Syste...
byWintari Yasmin
 
PDF
10 Best Automation QA Testing Software Tools in 2025.pdf
byRohitBhandari66
 
PDF
Mastering UiPath Maestro – Session 2 – Building a Live Use Case - Session 2
byDianaGray10
 
PDF
[BDD 2025 - Mobile Development] Crafting Immersive UI with E2E and AGSL Shade...
byWintari Yasmin
 
PDF
Open Source Post-Quantum Cryptography - Matt Caswell
byAll Things Open
 
PDF
DUBAI IT MODERNIZATION WITH AZURE MANAGED SERVICES.pdf
byLogicEra
 
PPTX
kernel PPT (Explanation of Windows Kernal).pptx
byINFOBYTES1
 
PDF
Parallel Computing BCS702 Module notes of the vtu college 7th sem 4.pdf
byMatheshVishnu
 
PDF
5 Common Supply Chain Attacks and How They Work | CyberPro Magazine
byCyberPro Magazine
 
PDF
Cybersecurity Prevention and Detection: Unit 2
byVICTOR MAESTRE RAMIREZ
 
Lets Build a Serverless Function with Kiro
byChris Bingham
 
[BDD 2025 - Mobile Development] Mobile Engineer and Software Engineer: Are we...
bywintari3
 
Transforming Content Operations in the Age of AI
byEnterprise Knowledge
 
PCCC25（設立25年記念PCクラスタシンポジウム）：エヌビディア合同会社 テーマ２「NVIDIA BlueField-4 DPU」
byPC Cluster Consortium
 
MuleSoft AI Series : Introduction to MCP
byMulesoftMunichMeetup
 
Mulesoft Meetup Online Portuguese: MCP e IA
byPedro Baroni
 
ODSC AI West: Agent Optimization: Beyond Context engineering
byShashikant Jagtap
 
MuleSoft Meetup: Dreamforce'25 Tour- Vibing With AI & Agents.pdf
byTintu Jacob Shaji
 
[BDD 2025 - Artificial Intelligence] AI for the Underdogs: Innovation for Sma...
byWintari Yasmin
 
UFCD 0797 - SISTEMAS OPERATIVOS_Unidade Completa.pptx
byscribddobruno
 
[BDD 2025 - Full-Stack Development] Agentic AI Architecture: Redefining Syste...
byWintari Yasmin
 
10 Best Automation QA Testing Software Tools in 2025.pdf
byRohitBhandari66
 
Mastering UiPath Maestro – Session 2 – Building a Live Use Case - Session 2
byDianaGray10
 
[BDD 2025 - Mobile Development] Crafting Immersive UI with E2E and AGSL Shade...
byWintari Yasmin
 
Open Source Post-Quantum Cryptography - Matt Caswell
byAll Things Open
 
DUBAI IT MODERNIZATION WITH AZURE MANAGED SERVICES.pdf
byLogicEra
 
kernel PPT (Explanation of Windows Kernal).pptx
byINFOBYTES1
 
Parallel Computing BCS702 Module notes of the vtu college 7th sem 4.pdf
byMatheshVishnu
 
5 Common Supply Chain Attacks and How They Work | CyberPro Magazine
byCyberPro Magazine
 
Cybersecurity Prevention and Detection: Unit 2
byVICTOR MAESTRE RAMIREZ
 

Adapting Agility: Getting your Agile Transformation Unstuck

  • 1.
    Adap%ng  Agility:  Ge0ng  your   Agile  Transforma%on  Unstuck   Camille  Bell   cbell@CamilleBellConsul0ng.com   Twi5er  @agilecamille   Agile  DC  2012                                                                                                                                                                                        October  23,  2012  
  • 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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    •  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.
    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.
    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