Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile Program Management Process

61 views

Published on

Applying Agile principles, principles, and processes to the CODE
program. Building the Release Plan for each program event and the deliverables for that review.

Published in: Technology
  • DOWNLOAD FULL BOOKS, INTO AVAILABLE FORMAT ......................................................................................................................... ......................................................................................................................... 1.DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Agile Program Management Process

  1. 1. WSRI  Agile  Program  Management   Process   Applying  Agile  principles,  prac8ces,  and  processes  to  the  CODE  program.   Building  the  Release  Plan  for  each  program  event  and  the  deliverables  for  that  review.  
  2. 2. Agile  at  WSRI     •  Standard  Agile  processes  focus  on  soFware   development,  with  emerging  requirements  in  a   product  development  context.   •  The  WSRI  domain  conducts  research  trade   studies  and  produces  outcomes  from  Modeling   and  Simula8ons  to  determine  best  solu1on   architectures  and  algorithms  for  the  CODE   domain:   –  Along  with  a  small  amount  of  coding   •  Our  needs  are  not  the  same  as  web  site   developers  for  the  local  pizza  shop.   2  
  3. 3. The  BAA  Says  …   •  DARPA  strongly  encourages  the  use  of  the  Agile   methodology  to  expedite  soFware  development   and  keep  up  with  this  test  schedule.   •  Performers  should  use  best  commercial  prac8ces   for  rapid  soFware  development,  such  as  Agile   methodology,  and  leverage  the  simula8on   environment  developed  in  Phase  1  for  frequent   and  progressive  valida8on  of  the  soFware.   3  
  4. 4. Our  Glossary   4   DODI  5000.02   Agile   WBS  –  displays  and  defines  the  product,  or   products,  to  be  developed  and/or  produced.   Backlog  –  a  list  of  deliverables  which  the  team   maintains.   Deliverable  –  a  tangible  outcome  delivered  to  the  Government  from  the  program   Task  –  lowest  level  work  ac8vi8es  on  the  program,  where  budget  and  resources  assigned  to   produce  deliverables.   Program  Event  –  An  assessment  point  that   occurs  at  the  culmina8on  of  significant   Program  Event  in  the  Integrated  Master  Plan.   Release  –  on  CODE:  CoDR,  SRR,  DS-­‐Interim,   PDR  maturity  assessments.   Rolling  Wave  (RW)–  Conver8ng  planning     packages  into  detailed  work  packages  so  that   near-­‐term  effort  is  always  detailed.   IteraBon  –  a  1me  box  in  which  development  of   deliverables  tasks  place   Rolling  Wave  Planning  –  with  current   defini8zed  RW,  planning  for  upcoming  RW’s  no   further  than  the  planning  horizon.   IteraBon  Planning  –  the  teams  plan  for  work   by  selec8ng  items  from  the  Backlog  and   commiYng  them  to  an  itera8on.   Program  Event  Planning  in  IMP/IMS   Release  Planning  –  planning  assignment  of   deliverables  to  specific  itera8ons  and  staff.  
  5. 5. Agile  Management  Process  Flow   5   WBS   IteraBon  1   IteraBon  2   IteraBon  3   …   IteraBon  n   Close  Out   §  Deliverables   §  Tasks   §  Tasks   §  Deliverables   §  Deliverables   §  Deliverables   § Tasks   § Tasks   CA   CoDR   …   PDR   WBS  basis  of  deliverables  Backlog,  per  MIL-­‐SRTD-­‐881C,   decomposed  into  Release  Backlog,  then  into  Itera8on  Backlog   for  delivery  by  Stories  and  Tasks.  
  6. 6. CODE  Program  Life  Cycle   Each  Program  Event  is  a  Release,  with  Itera1ons  (Sprints)  producing   deliverables  for  that  Release  to  increase  maturity  of  outcomes   6   Release  2  Release  1   Release  3   Release  4   Final  Capabili8es  
  7. 7. Agile  Program  Rhythm   7   Completed   Deliverable   Requirement,   Develop,  Deliver   Requirement,   Develop,  Deliver   Requirement,   Develop,  Deliver   Requirement,   Develop,  Deliver   Completed   Deliverable   Completed   Deliverable   Completed   Deliverable   Increasing   Maturity   Program  Maturity   Assessment  Event   Program  Maturity   Assessment  Event   Program  Maturity   Assessment  Event   Program  Maturity   Assessment  Event   IteraBon  Management   Increasing   Maturity   Increasing   Maturity   Increasing   Maturity   §  WBS    defines  deliverables  in  the  Backlog.   §  Allocate  Backlog  items  to  Releases  and  start  Release  Management   Release  Management   Itera8on  Management   Release   Itera8on  
  8. 8. Performance  Assessment     On  a  Weekly  Basis   8   Deliverable   Task   Task   Task   Task   Planned   240  Hrs   %  Complete   100%   100%   0%   0%   Remaining   80  Hours   Actual     200  Hrs   DelTek   GCS   Week  1   Week  2   Week  3   Week  4   20  Day  Itera8on   Every  Thursday  Status   § Physical  Percent  Complete   § Hours  remaining  to  100%  
  9. 9. Agile  for  WSRI  and  the  CODE  Program   •  Enable  program  planning  and  controls  with   agile  process  to  support  emerging  paths  of   research  within  the  Statement  of  Work  for  the   program.   •  Maintain  the  integrity  of  the  cost  and   schedule  baseline  for  a  DARPA  procurement   contract.   •  Assure  delivery  of  winning  solu8ons  on-­‐8me   and  on  budget.   9  
  10. 10. Agile  Principles  for  WSRI   •  Individuals  and  interac/ons  over  processes  and  tools.   –  Teams  of  individuals  will  perform  work  in  the  SOW  for  each   deliverable.   –  This  work  will  be  assessed  at  each  itera8on,  release,  and  Program   Event   •   Working  so6ware  over  comprehensive  documenta/on.   –  Since  documents  are  the  product  of  the  effort,  both  soFware  and   documenta8on  will  be  needed   •   Customer  collabora/on  over  contract  nego/a/on.   –  The  rela8onship  with  the  customer  is  done  through  TIMs  as  defined  in   the  SOW   •   Responding  to  change  over  following  a  plan.     –  Incremental  development  of  the  OS,  DS,  and  Open  Architecture   deliverables     WSRI  adap1on  of  the  Four  Agile  Manifesto  Statements   10  
  11. 11. HANDS  ON  EXAMPLE   Let’s  puts  some  Hands  On  for  the  1st  Release  and  the  3  Itera8ons  of  the   1st  release.   Define  the  Deliverables  for  CoDR  from  the  WBS   Define  the  contents  of  the  Itera8ons   Breakdown  the  Tasks  inside  the  Deliverables   Es8mate  to  hours  of  work  for  the  Tasks   11  
  12. 12. Release  Planning   •  For  1st  Release,  using  the  WBS   – Define  what  Deliverables  are  assigned  to  the   Release  from  the  WBS   – The  defini8on  of  Done  for  each  Deliverable  is   stated  in  the  SOW     •  For  example  CoDR  has  an  agenda  to  review  the  work  to   date   – Determine  the  Resources  needed  for  each   Deliverable  from  the  Resource  Pool   12  
  13. 13. Itera8on  Planning   •  For  the  Itera/ons  in  the  1st  Release,  using  the   WBS   – Assign  Deliverables  to  each  Itera/on   – Determine  staff  needed  for  each  Deliverable   – Determine  the  Tasks  performed  to  produce  the   Deliverable   – Es8mate  the  hours  to  produce  the  Deliverable   within  that  Itera/on  for  each  Task   13  
  14. 14. Weekly  Planning   •  Every  Thursday  status  the  work  progress  to   date   – What  is  the  Physical  Percent  Complete  for  each   Task  –  0%  or  100%   – Capture  actual  costs  from  Time  Sheets  completed   daily,  from  GCS   – Report  the  es8mated  Remaining  Work  for  each   Task   •  Program  Controls  will  produce  an  analysis   14  
  15. 15. NOW  FOR  HANDS  ON   15  
  16. 16. WBS  Items  Are  the  Backlog  of  all   Planned  Work     16   Deliverable  1     Deliverable  2   Deliverable  3   Deliverable  4   Deliverable  5   IteraBon  1   Backlog   Items  From     WBS    
  17. 17. Tasks  Items  Developed  from  each   Deliverable  for  the  WBS   17   Task  1     Task  2   Task  3   Task  4   Task  5  Deliverable  1     Delivery   Manager  
  18. 18. CONDITIONS  FOR  SUCCESS  WITH   AGILE  PROCESSES   Research  shows  there  are  several  condi8ons  for  success  in  deploying   Agile  on  DOD  (DARPA)  programs.   We’ll  need  to  assure  these  condi8ons  are  in  place  for  CODE.  
  19. 19. Agile  Success  Factors   19   Success  Factor   Evidence  Success  Factor  Being  Applied     Delivery  Strategy   §  Regular  delivery  business  rhythm   §  Plan  the  delivery  of  important  capabili8es  first   Agile  techniques   §  Well  defined  standards  of  produc8on   Team  Capability   §  Competence  and  exper8se   §  Managers  knowledgeable  of  agile   §  Adap8ve  management  style   Project   Management   §  Agile  requirements  analysis  and  project  management   §  Process  tracking   §  Face-­‐to-­‐face  communica8on   §  Regular  working  schedule   Team  Environment   §  Coloca8on  of  team  members   §  Coherent,  self-­‐organized  teams   §  Small  teams  working  on  weekly  cycle  of  deliverables   §  No  mul8ple  independent  teams,  close  coordina8on  of  work   Customer   Involvement   §  Good  customer  rela8onships   §  Progress  visible  to  customer  on  fine  grained  boundaries  
  20. 20. Defining  What  Done  Looks  Like   in  an  Agile  Process   •  Done  for  Itera8on  is  different  than  Done  for  the   Release   •  Acceptance  criteria  for  the  itera1on  defined  in  the   itera8on  planning  session   –  Agreed  to  by  the  team   –  Defined  in  the  WBS  Dic8onary  from  the  SOW   •  Acceptance  criteria  for  the  release  defined  in  the   release  planning  session   –  Agreed  to  by  the  team   –  Defined  in  the  SOW  for  each  Program  Event   •  Itera8on  retrospec8ve  assesses  progress  to  plan   –  Debt  is  accumulated  when  planned  work  is  not  completed   as  planned.   20  
  21. 21. Condi8ons  for  Success   •  Program  Lifecycle   •  Team  Environment   •  End  User  Access   •  Training  And  Coaching   •  Oversight   •  Incen8ves   •  Team  Composi8on   21  
  22. 22. Program  Lifecycle   •  The  Agile  mindset  starts  early  in  the  program  lifecycle   •  Determining  how  to  meet  program  milestones  is  the   first  step:   –  OS  CoDR      –  Release  1  (3  Mo)   –  DS  SRR/CoDR      –  Release  2  (6  Mo)   –  DS-­‐Interim      –  Release  3  (9  Mo)   –  DS  PDR      –  Release  4  (14  Mo)   •  Create  expecta8ons  and  criteria  to  reflect  the  level  and   type  of  documenta8on  acceptable  at  these  milestones   –  Tradi8onal  levels  of  documenta8on  are  not  produced  by   Agile   –  CODE  defines  contents   22  
  23. 23. Team  Environment   •  Self  organiza8on  is  an  Agile  paradigm   •  Centralized  func8ons  s8ll  needed   –  Systems  engineering   –  Configura8on  control   –  Integra8on  and  Test   –  Interface  management   •  These  centralized  func8ons  are  consider  constraints  in   the  DOD  Agile  paradigm   –  Boundaries  for  defining  limits  on  choice  and  interac8ons   –  These  are  system  boundaries  that  define  edges  of  the  agile   teams.   23  
  24. 24. End  User  Access   •  End  use  access  is  pragma8c  in  many  DOD   environments.   •  Single  voice  of  the  user  is  needed   –  Recurring  TIMs  and  monthly  mee8ng  can  provide  this   voice   •  DOD  acquisi8on  community  is  usually  a  proxy  for   the  customer   –  This  is  not  likely  the  case  for  CODE   –  But  rapid  and  recurring  feedback  on  deliverables  is   needed  to  stay  agile  in  absence  of  specific   requirements  management   24  
  25. 25. Training  and  Coaching   •  Subtle8es  and  nuances  will  cause  confusion   and  divert  energy  from  the  agile  process   •  A  training  Program  Management  Office   delivers  agile  training  and  coaching   •  Ini8al  and  ongoing  training  is  a  cri8cal  success   factor   25  
  26. 26. Oversight   •  Agile  has  less  defined  over  sight  func8ons   •  Management  is  a  team  func8ons  rather  than  an   overseer   •  Day  to  day  func8ons  need  to  be  defined  in  a   business  rhythm  for  all  team  members   •  Process  documenta8on  is  minimal  on  agile  teams   and  replaced  with   –  Big  Visible  Charts  –  showing  process  flows  on  weekly,   monthly,  and  quarterly  boundaries   –  Guidance  Cards  –  to  remember  the  words   –  Check  lists  –  for  each  status  process   26  
  27. 27. Incen8ves   •  Early  delivery  of  useful  material  is  a  primary   incen8ve  in  the  Agile  paradigm   •  In  the  end,  the  deliverables  must  provide   compliant  content,  but  focusing  on  cost  and   schedule  is  secondary  to  value  produced   27  
  28. 28. Team  Composi8on   •  And  Agile  advocate  is  the  anchor  for  success   •  While  end-­‐user  representa8ves  are  not  likely   for  CODE,  a  proxy  for  those  will  be  needed   •  Keeping  the  team  together  long  enough  to   achieve  high  performance  is  needed   – Mul8-­‐tasking  needs  to  be  minimized   – Key  technical  leads  under  a  collec8ve  organiza8on   28  
  29. 29. EFFECTIVE  PRACTICES  OF  AGILE   Effec8ve  Agile  prac8ces  are  nearly  iden8cal  to  effec8ve  engineering  and   tradi8onal  project  management  prac8ces.   The  only  difference  is  in  the  business  rhythm  cycles.   Short,  compact,  completely  formed  outcomes  produced  on  a  regular  basis.  
  30. 30. Effec8ve  Prac8ces  of  Agile   •  Planning   •  Organiza8onal  Commitment   •  Prepara8on   •  Execu8on   •  Evalua8on   30  
  31. 31. Planning   •  Think  agile,  not  just  follow  agile  prac8ces   •  Allow  gradual  migra8on  to  agile   •  Observe  and  communicate  with  other   program  members   •  Follow  organiza8on  change  discipline   •  Be  prepared  for  difficul8es   •  Start  with  Agile  guidance  and  an  Agile   adop8on  strategy   31  
  32. 32. Organiza8onal  Commitment   •  Ensure  all  components  involved  in  Agile   projects  are  commimed  to  the  organiza8on’s   Agile  approach.   •  Iden8fy  an  Agile  champion  within  senior   management.   •  Ensure  all  teams  include  coaches  or  staff  with   Agile  experience.   •  Empower  small,  cross-­‐func8onal  teams.   32  
  33. 33. Prepara8on   •  Train  en8re  organiza8on  in  Agile  approach  and  mindset,   and  train  Agile  prac88oners  in  Agile  methods.     •  Ensure  subject  mamer  experts  and  business  team  members   have  required  knowledge.   •  Enhance  migra8on  to  Agile  concepts  using  Agile  terms  and   examples.     •  Create  physical  environment  conducive  to  collabora8on.     •  Iden8fy  measurable  outcomes,  not  outputs,  of  what  you   want  to  achieve  using  Agile.     •  Ensure  that  the  defini8on  of  how  a  story  will  be   determined  to  be  done  is  comprehensive  and  objec8ve.   33  
  34. 34. Execu8on   •  Use  same  dura8on  for  each  itera8on.     •  Capture  itera8on  defects  in  a  backlog  tool.     •  Test  compliance  with  planned  maturity  of   deliverables  early  and  oFen  throughout  the   life  cycle.   34  
  35. 35. Evalua8on   •  Obtain  stakeholder  /  customer  feedback   frequently  and  closely  monitor  correc8ve  ac8ons.   •  Con8nuously  improve  Agile  adop8on  at  both  the   project  level  and  organiza8on  level.     •  Iden8fy  and  address  impediments  at  the   organiza8on  and  project  levels.     •  Gain  trust  by  demonstra8ng  value  at  the  end  of   each  itera8on.     •  Track  progress  using  tools  and  metrics.     •  Track  progress  daily  and  visibly.   35  
  36. 36. Agile  Management  Process  Flow   36   WBS   IteraBon  1   IteraBon  2   IteraBon  3   …   IteraBon  n   Close  Out   §  208hrs  /   Itera8on   §  12   Deliverables /  Itera8on   §  Deliverables   §  Deliverables   §  Deliverables   § Tasks   § Tasks   CA   CoDR   …   PDR   WBS  basis  of  deliverables  Backlog,  per  MIL-­‐SRTD-­‐881C,   decomposed  into  Release  Backlog,  then  into  Itera8on  Backlog   for  delivery  by  Stories  and  Tasks.   §  Resources  ~  25  engineers,  with  100  hours  /  month  capacity  for  work   §  ~31,000  hours  budget  over  18  months  at  1,700  hours  /  year  absorp8on   §  2,500  hours  capacity  per  itera8on  (20  work  days)  
  37. 37. Rules  of  Engagement   •  Planning  takes  place  on  Itera8on  and  Release   boundaries   – No  work  crosses  a  20  work  day  increment   – No  work  crosses  a  90  calendar  day  assessment  of   progress  to  plan   •  Status  progress  to  plan  done  every  Thursday     – DCAA  daily  8me  sheet   – Physical  percent  complete  of  tasks  in  Deliverable   37  
  38. 38. Rules  of  Engagement  (Concluded)   •  All  work  to  produce  a  deliverable  is  measured   as  0%  /  100%  complete   •  This  means  the  planning  of  that  work  has  to   follow  the  0/100  rules   38  
  39. 39. 7  STEPS  TO  OUR  RESOURCE   LOADED  BASELINE   The  key  to  success  for  CODE  and  beyond  is  Tools  Follow  Process   We’ll  develop  the  process  than  adapt  the  tools  to  fit  that  process.   As  a  start  the  processes  shown  here  are  the  top-­‐level  framework  for   conduc8ng  the  programma8c  ac8vi8es  of  the  program.   39  
  40. 40. Steps  to  Loading  the  Baseline  Into  the   Program  Management  Tools   1.  Establish  Releases   2.  Establish  Itera8ons  within  each  release   3.  Establish  Stories  from  the  WBS  and  allocate   them  to  each  release   4.  Assign  resources  to  each  Story   5.  Es8mate  work  effort  –  in  hours  –  to  each  story   6.  Assess  if  capacity  for  work  ≥  demand  for  work     7.  Repeat  Steps  4,  5,  and  6  un8l  demand  equals   capacity   40  
  41. 41. Establish  Releases   •  The  current  release  plan  is   –  CoDR   –  DS-­‐SRR/CoDR   –  DS-­‐Interim  DR   –  DS-­‐PDR   –  Phase  1  Final  Report   •  Each  release  will  have  itera8ons  to  produce  the   outcomes  of  those  “Events”   41   Releases  are  “mini-­‐projects”  and  treated  as   “deliverables”  of  fully  formed  outcomes  
  42. 42. Establish  Itera8ons  Inside  Releases   •  Itera8ons  are  planned  for  20  work  days  each   and  fit  inside  the  Release  Cycle   – CoDR  =  3  Itera8ons   – DS-­‐SRR/CoDR  =  3  itera8ons   – DS-­‐Interim  DR  =  3  Itera8ons   – DS-­‐PDR  =  3  Itera8ons     42   Daily  standups  confirm  not  only  work  for  the  day,   week,  and  Itera1on,  but  impediments  to  progress   that  must  be  removed  “today”    
  43. 43. Establish  Stories  Inside  Itera8ons   •  Stories  deliver  terminal  node  WBS  elements   •  Walking  the  WBS,  the  program  team  layouts   out  the  Stories  against  the  WBS  elements   •  Each  story   – Produces  a  single  outcome  of  a  WBS  element   – Takes  up  to  20  working  days  to  complete   – Is  100%  complete,  no  revisi8ng  the  Story   43   Requirements  Churn  is  just  as  much  a  problem  in   Agile  as  it  is  in  Tradi1onal  projects  
  44. 44. Assign  Resources  to  Stories   •  With  Stories  laid  into  Itera8on  assign  staff  to   perform  the  work   –  Named  resources  assigned  to  each  story   –  Can  have  mul8ple  staff  assigned  to  a  Story  for  its   comple8on   •  Assure  staff  availability  in  the  resource  calendar   –  Commitment  to  perform  is  a  Cri8cal  Success  Factor   44   Resource  commitments  for  the  period-­‐of-­‐ performance  assure  sustainable  “throughput”  
  45. 45. Es8mate  Work  Effort  for  Those   Resources   •  Use  proposal  BOE’s  as  a  start  of  effort   es8ma8on   •  Revisit  those  to  confirm  understanding,   es8mates,  and  outcomes   •  Load  the  work  effort  es8mates  into  the   project  management  tool     45   All  es1mates  need  to  be  adjusted  for  naturally   occurring  variance  and  event-­‐based  risk  
  46. 46. Assess  Capacity  for  Work  Against   Demand  for  Work   •  Compare  demand  for  work  against  capacity  for   work   •  Assure  sufficient  capacity  for  the  demand  before   proceeding   •  If  demand  higher  than  capacity,  re-­‐plan  work  to   level  demand   •  The  Grooming  of  the  Backlog  is  cri8cal  to   controlling  the  progress  to  plan   46   Closed  loop  control  of  demand  versus  capacity  has   a  weekly  sampling  interval  
  47. 47. BACKUP     47  
  48. 48. Vocabulary   Work  Breakdown  Structure   •  MIL-­‐STD-­‐881-­‐C  tells  us  …   –  All  por8ons  of  the  program  are  covered.     –  This  all-­‐in  requirement  assures  all  deliverables  are   iden8fied  in  the  WBS.   –  The  WBS  facilitates  collabora8on  between  the  team   members  by  tying  performance,  cost,  schedule,  and   risk  informa8on.     –  The  WBS  facilitates  the  required  technical  rigor  and   integrated  test  and  evalua8on  throughout  the   acquisi8on  process.   –  The  WBS  is  the  first  loca8on  to  define  the  risks  to   achieving  the  above  items  in  this  list   48  
  49. 49. Vocabulary  (Con8nued)   Deliverables   •  Agile  focuses  on  outcomes  rather  than  ac8vi8es   •  Our  outcomes  are  listed  in  the  BAA  (and  SOW  from  the   contract)   –  Trade  studies   –  Open  Architecture   –  Transi8on  Plan   –  MOP  defini8ons   –  Various  reports   •  The  agile  planning  process,  won’t  detail  how  to   produce  these,  just  that  they  are  produced.   •  The  agile  planning  process  is  not  a  schedule   49  
  50. 50. Vocabulary  (Con8nued)   Release  Planning   •  Release  planning  is  not  scheduling   •  The  backlog  of  Deliverables  from  the  WBS  are   assigned  to  Itera8ons  within  a  Release   •  The  Team  …   –  Comprehends  the  work  of  the  Release   –  Shares  the  understanding  of  what  it  takes  to  produce   the  release   –  Agrees  on  the  ac8ons  needed  to  formalize  the  plan   –  Baselines  this  confidence  with  all  the  stakeholders     –  Results  in  collec8ve  ownership  of  the  plan,  any  need   to  replanning,  and  communica8on  within  the  team   50  

×