Successfully reported this slideshow.
Your SlideShare is downloading. ×

Agile contracts workshop martin kearns

Loading in …3

Check these out next

1 of 45 Ad

More Related Content

Slideshows for you (20)

Viewers also liked (20)


Similar to Agile contracts workshop martin kearns (20)

Recently uploaded (20)


Agile contracts workshop martin kearns

  1. 1. How to build an agile contract some steps to get you thinking in the right way •  Martin Kearns •  25th Apr 2016
  2. 2. What  problem  do  you  want  to  focus  on    
  3. 3. Incremental  change  will  not  be  enough  as  we  enter   this  new  era  of  agile  and  scrum  in  the  corporate   world.  
  4. 4. Complete  Exercise  ASAP   What  does  vendor  management  /  your   business  want  from  a  contractual   engagement?   What  is  preven:ng  them  and  you  from   achieving  their  goal?     •          •        •        •        •            •          •        •        •        •       
  5. 5. It  is  hard  or  maybe  even  impossible  to   extract,  codify  and  transfer  past   knowledge  in  a  way  that  makes  sense   outside  it’s  original  seCng     The  only  way  to  gain  such  knowledge  is   via  an  incremental  process  of  learning   by  pracEce     Projects  have  to  discover  their  own  way   Place  less  emphasis  on  best  pracEce    
  6. 6. You  can  never  direct  a  living   system,  you  can  only  disturb  it           Maturana  +  Varela  “  The  Tree  of  Knowledge:  The  Biological   Roots  of  Human  Understanding  1992”     A  system  will  only  be  disturbed  by  informaEon  based   on  what  is  going  on  inside  the  organisaEon  
  7. 7. We  really  need  to  shake  this  place  up!   Order  (Date,  Cost,  Time)  is  be[er   than  deep  complexity  regardless   of  informaEon  lost         It’s     MarEn     Time     NOT  !!!!!!!!!!!!!!!     Our  minds  incline  toward   the  instant  and  the   obvious  (Habit)  under  a   false  pretense  that  it  will   help  in  our  own  survival  
  8. 8. Be  wary  of  well-­‐walked  paths   Once  we  know  something,   that  knowledge  makes  it   nearly  impossible  to   remember  not  knowing.     We  become  a  prisoner  to  our   tacit  experience.     Agile  contracts  are  less  about  designing  to  get  it  right  first  Eme   and  more  on  learning  and  responding  to  new  informaEon  as  it   emerges  within  the  lifecycle  of  a  project  /  engagement  
  9. 9. Name  the  enemy     Meaning  of  so<ware     So`ware  means  a  right,  including  a  licence,  to  use  so`ware.  Expenditure  on  so`ware   includes  expenditure  you  incur  on  acquiring  or  developing  so`ware  or  in  having  another   person  develop  so`ware  principally  for  you  to  use  to  perform  the  funcEons  for  which  you   acquired  or  developed  the  so`ware.   Expenditure  in  relaEon  to  so`ware  projects  is  capitalised  and  depreciated  from  the  :me   you  use  the  so<ware  or  install  it  ready  for  use.       You  can’t  capitalise  a  fic::ous  Business  Case  and/or  a    Business  Requirements   Document  and/or  the  effort  you  place  into  wri:ng  a  crap  contract.       …..  End  of  story     h[ps://­‐to-­‐ depreciaEon-­‐2001/?page=24  
  10. 10. Construct  co-­‐opera:on   into  the  contract   The  more  important  thing  is   that  the  contract  represents   the  intenEon,  expected   behaviours  and  accountability   to  the  approach.         The  trick  is  to  encourage  co-­‐ operaEon,  by  making  sure   there  is  the  right  pressure  to   encourage  parEes  to   reciprocate.  
  11. 11. Principle  1.  Exploit  early  informaEon   by  front-­‐loading  the  process   The  pebbles  of  past  failures  grows  heavier  the   longer  you  keep  carrying  them  on  your  shoulders    
  12. 12. Design  in  the  price-­‐point  for  learning     Time Minimise  the  cost  of  learning   so  that  emoEons  can  be   controlled  and  raEonal   decision  making  is  the  norm   Value / $ cost Pay to learn The  ability  to  iterate  is  an   economical  decision.       Where  feedback  is  seen  to     shape  an  outcome  through              a)  Re-­‐enforcing              b)  AdapEng              c)  Serendipity                d)  Failing                e)  PivoEng     Iterate Acquisition of knowledge Prioritize on early value Re-purpose Funding learning   demonstrable value Incremental   Min. viable project  
  13. 13. An  Experimental  –  Learning  Cycle   STEP  4  –  Assess       Carefully  assess  the  tangible     evidence  of  the  sprint  and     determine  whether  to  Pivot  /   Fail  /  Persevere  /  Pause     Develop  understanding  of     cause  and  effect   STEP  1  -­‐  Discover     Run  workshops  where  focus    is  on  refining  concepts     through  idenEfying  new   informaEon  /  causaEon     Observe  risk  profile     STEP  2  -­‐  Conceptualise     Build  the  hypothesis  on  what   knowledge  is  required  to     assess  confidence  and  the     desire  to  proceed     Prepare  test  environment   STEP  3  -­‐  Execute     Use  sprints  to  prove  /     disprove  project     assumpEons  and  the     cohesiveness  of  the  team     Work  purposefully   Learning  by     Experimenta:on     Via  a  cross-­‐func:onal  team  
  14. 14. Step  1  –  Designing  your  process   of  discovery   STEP  1  -­‐  Discover     Run  workshops  where  focus    is  on  refining  concepts     through  idenEfying  new   InformaEon  /  causaEon     Observe  risk  profile     Discovery  requires  a  willingness  to  risk,  or  admit,  not  knowing   when  we  confront  directly  the  full  weight  our  confusion  or   dilemma  we  are  facing.      
  15. 15. We  need  to  broaden  our  perspecEve   Early  sprints  encompass  project  experimentaEon,  where   understanding  what  works  and  does  not  work  are  of  equal   importance  for  learning.  
  16. 16. Principle  2:      The  definiEon  of  done  is  a       strategic  decision   Roles / Functions   Infrastructure   Continuous Integration   Dev P.C.   Continuous Delivery   Predictive Analytics   Iterative Development   Digital Enabled   SME in team no automation   TDD/Build server   We  must  engineer  the  removal  of  interfaces  between  funcEonal   groups  in  order  to  speed  up  the  process  of  team  learning.  
  17. 17. TesEng  the  landscape   ©  SQS  So`ware  Quality  Systems  Ireland    |    Title  of  the  PresentaEon    |    February  2013    |   Business  Shared Services  IT   Shared Understanding   Incremental Value   Demonstrable Value   Empirical Evidence   By  working  to  a  shared  “definiEon  of  done”  we  have  the   ability  to  test  the  beliefs  around  collecEve  responsibility,   culture  and  required  behaviors  to  achieve  success.     Learning increases linked cause and effect without the normal organisation factors that obscure our ability to commit to an outcome. Done  
  18. 18. Outline  a  definiEon  of  done  for   your  scenario   Roles / Functions   Infrastructure  
  19. 19. Step  2  –  Engineer  rapid  feedback  to  shape  ideas  by  re-­‐ inforcing,  modifying  or  complemenEng     exisEng  knowledge   Retaining  cogniEve  diversity  is  a  required  capability  within   teams  to  allow  differenEaEon,  permiCng  the  emergence   of  new  thinking  and  new  realisaEons  of  what  is  possible.     STEP  2  -­‐  Conceptualise     Build  the  hypothesis  on  what   knowledge  is  required  to     assess  confidence  and  the     desire  to  proceed.     Prepare  test  environment.  
  20. 20. Principle  3:      Create  a  hypothesis  to  generate   variables  of  interest  
  21. 21. Steer  the  direcEon  to  what  and  where   you  wish  to  learn   Regardless of what backlog items are delivered the culture and capability of the team will be demonstrated. Experimentation Degree of intervention   Activity   Description   High   Some   Low   Exploration Observation A focus on interface and technical functionality to assess feasibility of the intended solution exceeds behavioral concerns. Regardless on what backlog items are delivered the culture and capability of the team will be demonstrated.
  22. 22. Set  your  hypothesis  NOW!   No  I  won’t  bring  back  that  other  slide.       The  learning  objecEve  is  for  you  to  create  the   focused  language  required  to  get  the  desired   behavior  and  purpose  across  to  others.  
  23. 23. Step  3  –    Test  intent  against  the  behaviours  and   velocity  achieved  via  MVP  Sprints     Provide  the  rapid  feedback  necessary  to  shape  behavior,  process   and  soluEons  by  reinforcing,  modifying  or  complemenEng  exisEng   knowledge.     STEP  3  -­‐  Execute     Use  sprints  to  prove  /     disprove  project     assumpEons  and  the     cohesiveness  of  the  team.     Work  Purposefully.  
  24. 24. Process  and  roles  limit  the  impact  that  technology   advancement  can  provide  through  excessive  organisaEon   interfaces  (gates)  and  normalised  behaviors  (roles)     Principle  4:      Enable  the  viability  and  resilience  of     systems  to  become  purposeful  
  25. 25. The  intent  of  M.V.P.  informaEon  is  to  off-­‐balance  norms   between  two  parEes  and  open  itself  to  new  and  more   meaningful  conversaEon   “Stretch  to  fit  “  
  26. 26. By  moving  away  from  command   and  control  to  one  of  “autonomy   to  outcome”  you  create  a  self-­‐ determinisEc  system.       The  gap  between  raEonal  and   behavioral  viewpoints  can  spell  the   difference  between  project  success   and  failure.   Focus  on  the  individual  integrity  
  27. 27. OrganisaEonal  norm  can  impede  adapEon  &     arEculate  principles  as  a  form  of  control     Compliance   Externalisa:on   Internalisa:on   Conformance  to  principle     Explicit  Prac:ces   Educa:on   Collec:vely  responsible   Self  determined   Behavioral  norm   Create  an  agreed  set  of  fundamental  truths  around  a  project  that   are  the  foundaEons  for  system  belief,  individual  intuiEon  and   decision  making.  
  28. 28. Values Principles Practices Methods •  New information will be identified and valued when change is seen as a necessity for preservation and/or creativity •  Maintain a higher sense of purpose within the team •  People must be empowered to make their own decision as to “How” they can achieve a goal •  A team must consist of all the skills needed to achieve the “Definition of Done” •  Team takes collective responsibility for their processes and outcomes My  Scrum  Principles  
  29. 29. Define  some  control/common  principles   for  the  engagement  you  have  defined   You  have  guessed  it,  I  am  not  going  to  share  the  previous   slide  -­‐  work  on  your  own  language.     Try  to  see  how  you  can  explicitly  state  the  expected   behavior  of  two  parEes  into  a  common/shared   understanding  of  how  value  is  created.      
  30. 30.  STEP  4  –  Assess       Carefully  assess  the  tangible     evidence  of  the  sprint  and     determine  whether  to  Pivot  /   Fail  /  Persevere  /  Pause     Develop  understanding  of     cause  and  effect   Provide  the  rapid  feedback  necessary  to  shape  behavior,  process   and  soluEons  by  reinforcing,  modifying  or  complemenEng  exisEng   Knowledge.     Step  4  –  test  intent  against  the  behaviours  and     velocity  achieved  via  MVP  sprints  
  31. 31. The  iteraEon  allows  for  any  system  variable  to  be  created,   disrupted,  corrected  &  destroyed  by  creaEng  pa[erns  at   scale  that  make  contract  levers  tangible  and  used.     Principle  5:  You  must  prepare  and  sustain  the   required  energy  to  observe  and  measure   To see patterns, we need to step back from the problem and gain perspective System fractals are created as individuals exercise both freedom and responsibility towards some simple rules.
  32. 32. Create  guiding  values  to  outcome   What  we  don’t  want  in  a  contract:   People  use  their  shared  sense  of  idenEty  to   maximise  their  unique  contribuEon     to  project  success.   Your   responsible   for     How  I  will   decide  to   punish   -­‐-­‐-­‐-­‐-­‐   -­‐-­‐-­‐-­‐-­‐   -­‐-­‐-­‐-­‐-­‐   Deliverables   Output   Input   We  focus  on     achieving     a  shared    outcome     CollecEve     Responsibility  
  33. 33. IteraEons  help  small  differences  amplify  into  powerful  and  unpredicted   system  variables  in  non-­‐linear  systems  that  no  model  or  methodology  could   achieve  -­‐  the  system  feeds  back  onto  itself  through  the  learning  cycle.   Don‘t  ever  forget  what  an  iteraEon  is  for  
  34. 34. Some  simple  but  powerful  stories   Assessing  the  levels  of  maturity   being  achieve  with  the  backlog  over   Eme  and  a  commitment  to  a  fixed   deliverable.   Visualizing  the  movements  within  a   product  backlog  with  velocity  and  a   predicted  trajectory  of  progress  /   compleEon.    
  35. 35. Making  contract  deviaEons  visible   !
  36. 36. Produce  some  visualisaEons  of  a  known   problem   Feel  free  to  reuse  some  of  what  you  have  learnt  today.     However,  if  you  want  to  really  impress  me,  come  up  with   some  new  ideas  on  how  you  can  influence  your  systems   through  new  forms  of  measurement  and  visualisaEon.  
  37. 37. Individual  raEonality  leads  to  a  worse   outcome  for  both  than  what  is  possible   Project variation Change request Over spend Leads to Best price Recover Unhappy customers Prisoners  Dilemma  –  players  cannot  get  out  of  the  dilemma  by   taking  turns  exploiEng  one  another.  The  struggle  to  establish   one’s  reputaEon  can  be  a  major  feature  of  intense  conflicts.  
  38. 38. Shared   Experience   Hands   On   ConstrucEve   Feedback   Transparency   Shared   Success   Stories   Strong   Metric   Legal   Contract   Co-­‐created   AdapEng   to  Change   Embedded   Team   Evidence   Based   CollaboraEve   Framework   CollecEve   Responsibility  Partnership   In  any  partnership,  we  recognise  that  we  all  have  know-­‐how,   skills  and  insights  to  offer,  and  we  all  have  the  opportunity  to   learn  and  grow  from  one  another.  This  is  why  we  know  that  we   will  be  co-­‐creaEng  with  you  the  approaches  that  work  for  the   ATO   Enlarge  the  shadow  of  the  future  via  Partnering   When  the  probability  to  work  with  one  another  is  high,  co-­‐ operaEon  based  on  reciprocity  is  high  bringing  stability  to   future  delivery.  
  39. 39. An  effecEve  strategy  must  be  able  to  take  into   account  the  history  of  iteraEon  /  interacEon  to  far   MVP Discount parameter MMF W Enable multiple exit clauses   With  the  opportunity  for  future   sprints  /  interacEons  co-­‐operaEon   can  emerge  from  a  system.     Mutual  co-­‐operaEon  depends  on  their  being   a  good  chance  of  a  conEnuing  relaEonship,  as   measured  my  the  size  of  w.   Co-­‐operaEon  can  be  accelerated  by  making   interacEons  more  frequent  and  the  ability  to   recognise  defecEon  more  readily.  
  40. 40. Dialogue   Real  dialogue  is  where  two  or  more  parEes  become  willing  to  suspend   their  certainty  in  each  others  presence.     David  Bohm     My  hope  is  that  I  have  opened  a  door   through  which  you  can  walk  into  a  greater   understanding  how  contracts  can  be  framed.