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.
 
-­‐	
  Towards	
  Facilitative	
  Project	
  Management	
  -­‐	
  
Source:	
  Managing	
  agile	
  projects	
  (Bert	
  ...
 
-­‐	
  Towards	
  Facilitative	
  Project	
  Management	
  -­‐	
  
needs	
  of	
  the	
  customer.	
  Even	
  though	
  ...
 
-­‐	
  Towards	
  Facilitative	
  Project	
  Management	
  -­‐	
  
	
  
Agile	
  governance	
  for	
  more	
  grip	
  on...
 
-­‐	
  Towards	
  Facilitative	
  Project	
  Management	
  -­‐	
  
• Scope	
  churn	
  is	
  a	
  measurement	
  of	
  t...
 
-­‐	
  Towards	
  Facilitative	
  Project	
  Management	
  -­‐	
  
Example:	
  project	
  in	
  7	
  sprints;	
  optimis...
Upcoming SlideShare
Loading in …5
×

Agile governance towards facilitative project management - article - fortes solutions

484 views

Published on

This paper discusses the changing role of project managers in agile projects, and how to organize a more facilitative approach in your (IT) projects when using agile as methodology.

Published in: Business
  • Be the first to comment

  • Be the first to like this

Agile governance towards facilitative project management - article - fortes solutions

  1. 1.   -­‐  Towards  Facilitative  Project  Management  -­‐   Source:  Managing  agile  projects  (Bert  Hedeman)   Towards  Facilitative  Project  Management   The  changing  role  of  project  managers  in  agile  projects     N.B.  This  article  was  originally  featured  in  ‘Projectie  08/2014’   Research  shows  that  (project)  managers  and  executives  experience  a  lot  less  control  in  projects  with  an  agile   approach.  After  all,  the  scope  of  the  project  is  not  fixed  and  the  teams  are  self-­‐directing.     Nevertheless,  it  doesn’t  have  to  be  that  agile  leads  to  less  control.  When  agile  is  implemented  correctly,  an   organization  retains  control  over  money,  time,  scope  and  quality.  However,  the  role  of  the  project  manager  will   have  to  change.  Instead  of  directing,  the  emphasis  will  be  on  facilitating  and  communicating.  Regular   measurement  of  and  reporting  about  the  quality  of  the  product  and  process  remains  important.  This  enables   organizations  to  ‘release  their  projects  in  a  controlled  way’  and  be  confident  about  the  execution  of  the  projects   by  the  self-­‐directing  teams.     Cultural  change   The  ‘8th  Annual  State  of  Agile  Survey’  shows  that  loss  of  management  control  and  the  lack  of  up-­‐front  planning   are  the  main  concerns  for  organizations  that  work  based  on  an  agile  philosophy.  The  survey  shows  that  30%  of   the  3,500  respondents  find  these  two  concerns  as  most  important.  Organizations  and  (project)  managers  are   primarily  used  to  being  directive  and  determining  everything  in  detail  before  the  execution  stage(s).  This  is   often  the  case  with  a  traditional  waterfall  approach.  This  approach  gives  organizations  often  more  sense  of  grip   and  control,  but  doesn’t  always  result  in  the  desired  final  product.  During  the  project  a  lot  of  things  can  change   because  of  external  factors  which  will  require  adjustments  in  the  final  product.     Apparently,  organizations  struggle  to  give  self-­‐directing  teams  enough  space  and  find  it  difficult  not  to   determine  the  final  product  in  advance.  In  many  organizations,  projects  with  an  agile  approach  require  a   cultural  change.  Besides,  PRINCE2  also  does  not  state  that  every  detail  must  be  covered  in  the  project  plan.   These  are  also  developed  further  in  the  stage  plan.   Agile  governance   It  is  therefore  a  misconception  that  agile  leads  to  less  control.   When  agile  governance  is  implemented  correctly,  an   organization  retains  control  over  money,  time,  scope  and   quality.  Governance  stands  among  others  for  management   and  supervision.  Determining  expectations,  delegating  tasks   and  verifying  performance  are  the  key  components  of   governance.  In  other  words,  this  is  the  role  of  a  project   manager  in  an  agile  project.  The  principles  of  Atern,  one  of   the  most  complete  agile  methodologies,  state  that  it  is   important  to  focus  on  the  business  needs,  continually   communicate  clearly  and  ensure  visible  control.     In  agile  projects,  a  prioritized  requirements  list  will  be   prepared  during  the  Feasibility  and  Foundation  stage  and  all   stakeholder  expectations  will  be  determined.  Subsequently,   the  Business  Visionary  or  Senior  User  has  to  approve  them.  The  requirements  list  will  be  developed  further   during  the  Exploration  and  Engineering  stages.  The  Business  Ambassador  or  Product  Owner,  in  agile  projects   part  of  the  Solution  Development  Team,  is  made  responsible  for  the  translation  of  the  business  needs  to  the  
  2. 2.   -­‐  Towards  Facilitative  Project  Management  -­‐   needs  of  the  customer.  Even  though  not  everything  is  captured  in  detail  in  advance,  there  is  up-­‐front  alignment   about  the  final  product.     Parameters  for  agile  projects   To  be  able  to  provide  self-­‐directing  teams  enough  room  to  maneuver  and  still  ensure  adequate  management   control  for  the  organization,  the  project  manager  has  to  provide  the  Project  Board  with  sufficient  progress   information.  By  reporting  regularly,  the  project  manager  ensures  that  self-­‐directing  teams  can  do  their  job.  In   addition  to  reporting  on  standard  parameters  such  as  hours,  costs  and  results,  the  Scope  Churn  (the  number  of   changes  in  the  back  log),  Effort  at  Risk  (item  has  been  built  or  supplied,  but  is  not  in  production  yet)  and  the   Earned  Value  (the  value  of  the  delivered  work)  are  parameters  the  project  manager  could  report  on.  (also  see   break-­‐out  section  on  ‘Agile  governance  for  more  grip  on  agile’  on  how  to  measure  agile  software  projects).   Other  techniques,  such  as  a  Kanban  board,  burn-­‐down  chart,  release  chart,  sprint  quality  and  code  quality  are   indicators  for  the  Solutions  Development  Team.  Some  project  management  tools  offer  this  kind  of  information   by  default.  The  information  will  help  the  team  to  get  insight  in  the  progress  during  the  sprint  and  in  the  quality   of  the  delivered  work.  It  also  helps  the  team  to  learn  and  improve  themselves  in  the  next  sprint.  These   parameters  are  less  interesting  for  the  Project  Board.     From  being  directive  to  being  facilitative   All  agile  methodologies  emphasize  that  project  managers  do  not  necessarily  need  to  have  sufficient  knowledge   of  the  actual  project  contents  (this  is  also  the  case  when  using  with  PRINCE2).  Too  much  knowledge  about  the   project  content  can  even  be  a  risk,  because  the  project  manager  will  then  take  the  place  of  the  Team  Manager   or  Team  Member.  The  emphasis  for  the  project  manager  in  agile  projects  is  more  on  facilitating  and   communicating.  The  project  manager  is  responsible  for  the  progress  of  the  project  as  a  whole  and  has  to  shield   the  team  from  the  rest  of  the  organization,  in  order  to  minimize  disruptions.  In  general,  self-­‐directing  teams  are   capable  enough  to  translate  the  business  needs  to  a  technical  solution  and  associated  planning  all  by   themselves.  The  project  manager  should  pay  special  attention  to  ensuring  that  the  right  conditions  are  in  place   –  conditions  which  enables  the  team  to  work  as  effectively  as  possible.     Moreover,  a  team  does  not  simply  become  self-­‐ directing.  This  requires  experience  and  time.  This  can   be  achieved  by  gradually  being  less  strict  and  directive   towards  a  team.  The  team  has  to  have  the  chance  and   room  to  learn  instead  of  being  criticized  or  regulated.   “Letting  go  is  to  fear  less  and  love  more”  according  to  a   famous  quote  by  Nelson  Mandela.  The  ‘controlled   letting  go’  is  vital  to  let  agile  projects  succeed.  When  a   team  is  ‘released’  too  fast  or  too  slow,  the  trust   between  the  Project  Team,  the  Project  Manager  and   the  Project  Board  will  be  put  under  pressure.  This   endangers  the  success  of  agile  projects.   Conclusion   Using  agile  governance  and  the  controlled  release  of  the  teams,  organizations  are  able  to  make  agile  projects  a   success  without  losing  control  over  the  projects.  Just  like  with  every  other  project  methodology,  it  is  important   to  continually  measure  the  progress  of  the  project  and  to  intervene  as  soon  as  one  of  the  parameters  is  likely   to  be  exceeded.  Clear  and  automated  reports  for  the  team  and  for  the  executives  are  crucial.  This  allows  the   Project  Manager  –  and  the  rest  of  the  organization  –  to  hand  over  the  project  to  the  self-­‐directing  team  with   confidence.      
  3. 3.   -­‐  Towards  Facilitative  Project  Management  -­‐     Agile  governance  for  more  grip  on  agile   Research  into  the  quality  of  software  systems  shows  that  ‘applying  agile’  often  stops  at  the  borders  of  the   Solution  Development  Team.  This  triggered  Professor  Joost  Visser  of  the  Software  Improvement  Group  to   investigate  ways  how  to  increase  control  over  agile  software  development  projects.  This  research  was   conducted  together  with  the  Radboud  University  Nijmegen  and  VU  University  Amsterdam,  and  resulted  in  a   new  Agile  Governance  Quality  Model.     Measurement  and  metrics  for  software  and  projects   Measuring  software  serves  two  purposes:     1. Internal:  to  give  members  of  the  Project  Team  insight  into  the  progress  of  their  work;  this  allows  for   adjusting  things  within  the  team  and  for  the  individual.     2. External:  to  give  the  Project  Team  the  possibilities  to  show  the  Project  Sponsors  the  progress  and   when  it  will  be  finished;  this  allows  for  adjusting  the  project.     These  are  two  scenarios  that  require  a  different  approach  and  different  metrics.  It  is  not  desirable  to  use   internal  metrics  (for  the  Project  Team)  without  the  team’s  approval,  outside  the  team.  This  may  result  in  a   team  losing  trust  and  the  measurements  to  become  less  valuable.     It  is  also  important  that  performing  the  measurements  requires  very  little  effort  from  the  individual  Project   Members,  so  they  can  stay  focused  on  their  work  as  much  as  possible.     The  Agile  Governance  Quality  Model     The  Agile  Governance  Quality  Model  utilizes  pattern  every  agile  or  scrum  project  offers  in  the  form  of  iterations   or  sprints.  Typically  at  the  end  of  every  sprint,  working  software  is  delivered  and  accepted.  At  the  beginning  of   a  sprint  the  back  log  is  updated  and  eventually  the  built  software  will  be  taken  in  to  production.     Using  the  available  information  in  the  sprints,  the  following  characteristics  for  an  agile  development  process   have  been  defined.          
  4. 4.   -­‐  Towards  Facilitative  Project  Management  -­‐   • Scope  churn  is  a  measurement  of  the  scope  of  the  project,  as  it  is  recorded  in  the  back  log.  The  back   log  can  change  because  extra  work  is  coming  in,  and  tasks  are  deleted,  modified  or  rejected  by  the   stakeholders.   • Value  is  a  measurement  for  the  amount  of  value  that  has  been  created  for  the  business,  relative  to  the   agreed  initial  value.  By  measuring  the  value  it  is  possible  to  regularly  test  whether  the  business  case  is   still  valid.     • Effort  at  risk  is  the  amount  of  work  and  costs,  that  have  already  been  made,  but  not  yet  resulted  in  a   working  software  product.  This  also  includes  the  effort  to  define  the  requirements.  Earlier  in  the   project  it  is  more  likely  that  a  requirement  will  not  be  implemented.  Later  in  a  project,  the  amount  of   effort  invested  in  building  a  requirement  will  be  much  higher.   • The  sprint  quality  indicates  how  well  the  team  executes  a  planned  sprint.  When  there  is  a  lot  of  failure   or  a  low  effectivity,  the  team  is  able  to  make  improvements.     • For  measuring  the  code  quality  models  have  been  designed  based  on  ISO  25010  for  software  quality.   With  this,  the  performance,  reliability,  security  and  maintainability  of  the  software  can  be  measured.   With  the  results,  which  are  expressed  on  a  scale  from  1  to  5  stars,  the  software  can  be  improved  these   specific  areas.     For  example,  for  determining  the  maintainability  of  the  software,  system  properties  are  measured  such  as  the   volume  (number  of  lines  of  code),  level  of  de-­‐duplication,  the  unit  size  and  the  unit  complexity.  The   measurements  are  compared  with  benchmark  figures,  where  the  score  is  calculated  relative  to  other  systems   in  the  benchmark.     From  the  start  of  the  project,  it  is  important  to  maintain  a  consistent  and  traceable  administration  in  the  back   log.  This  means  that  from  the  beginning  of  a  project  it  should  be  clear  what  units  of  work  are,  thus  which   functional    ‘parts’  the  Project  Sponsor  will  recognize.  These  can  be  epics,  stories  or  requirements;  in  practice   the  terminology  often  differs.  All  stories  should  be  unique,  even  when  changes  are  made  such  as  extensions,   separations  or  further  developments  at  a  later  stage.  Removed  and  rejected  stories  should  also  remain  in  the   back  log,  so  there  is  a  clear  picture  of  the  realized  scope  relative  to  the  initial  scope  of  the  project  in  every   stadium.  An  advantage  of  working  agile  is  the  flexible  scope.  However,  in  practice  the  initial  expectations  of  the   stakeholders  often  remain.  Especially  if  there  is  a  distance  between  them  and  the  Solution  Development  Team.     The  concepts  of  scope  churn,  value  and  effort  at  risk  are  translated  in  the  quality  model  in  11  metrics,  such  as   the  size  of  the  back  log,  the  extent  to  which  stories  are  added,  modified  or  expired,  and  the  extent  to  which   stories  are  transformed  in  working  software  and  the  effect  on  the  expected  lead  time  and  final  scope.  Changes   of  stories  can  be  the  content  (the  functionality  changes),  but  it  can  also  be  a  change  of  the  priority  (a  feature   has  become  more  important)  or  estimation  (the  story  takes  more  time  to  be  developed  then  originally   expected).      
  5. 5.   -­‐  Towards  Facilitative  Project  Management  -­‐   Example:  project  in  7  sprints;  optimistically  planned,  realism  sets  in   During  the  course  of  this  example  project  more  and  more  requirements  will  expire,  for  example  to  meet  a   deadline.  This  will  decrease  the  expected  value  upon  completion.  The  ‘effort  at  risk’  will  also  continue  to  grow   because  there  is  virtually  no  functionality  brought  to  production  useful  for  the  production.   A  possible  course  of  an  agile  project  in  7  sprints  will  look  like  this:     Benefits  for  the  Project  Manager   The  results  of  the  above  model  give  the  Project  Manager  insight  into  the  trends  and  behaviour  of  his  agile   project.  It  provides  objective  perspectives  on  the  shared  reality.  With  these  insights  it  is  possible  to  make   better  estimations  about  scope  and  end  date.  It  enables  the  Executive  and  Project  Manager  to  agree  about   what  can  be  done  to  increase  the  chance  of  success.  For  instance,  they  could  decide  to:   1. Add  more  people  to  the  project   2. Decrease  the  scope  of  the  project   3. Monitor  the  scope  in  the  backlog  better   4. Define  more  realistic  milestones   By  measuring  and  monitoring  agile  projects  and  their  software  characteristics,  more  control  over  the  projects   will  be  realized.  This  helps  avoid  undesirable  situations  in  an  early  stage.  During  the  alignment,  the  Project   Manager  will  continue  to  fulfill  a  crucial  role  between  the  Solutions  Development  Team  and  the  Stakeholders.         The  authors   Erik  Aalbersberg                        Niels  van  der  Zwan                              Fortes  Solutions       Software  Improvement  Group  

×