Introduction to Agile with Scrum

Agenda  

•  Short  introduc,on  to  Agile      •  Scrum  

– Overview  – How  it  works  

2  

Tradi4onal  So7ware  Project  Failures  

•  Nearly  2  /  3  of  the  projects  are  significantly  over  budget  

•  64%  of  the  features  in  a  product  are  rarely  used  

•  An  average  project  exceeds  its  schedule  by  100%    

3  

Main  Causes  

•  Planning  for  comple4on  of  ac4vi4es  rather  than  features.  

•  Progress  not  transparent  to  customers,  and  focus  on  ac4vi4es  leading  to  missing-­‐forgoRen  features.  

•  Specializa4on  leading  to  island  culture  and  reduced  involvement.  

•  Do  not  work  on  the  basis  of  client  priority,  but  o7en  technical.  Team  starts  late  with  important  business  needs  

•  Ignore  uncertainty  (changing  insights  /  requests?)      

Limita4ons  of  Waterfall                                      "Waterfall"  project  approach  is  only  possible  if      

•  Problem  is  clear;  •  Solu4on  is  known;  •  Technique  familiar;  •  Problem  has  not  changed;                                                                                                                                                                    •  A  sufficient  knowledge;  •  Priori4es  constant.  

Agile  Manifesto  

   

Suppor4ng  Agile  “Sentences”  1.  Our  highest  priority  is  to  sa4sfy  the  customer  through  early  

and  frequent  delivery  of  valuable  so7ware.  2.  Deliver  working  so7ware  frequently,  from  a  couple  of  

weeks  to  a  couple  of  months,  with  a  preference  for  the  shorter  4me  scale.  

3.  Working  so7ware/product  is  the  primary  measure  of  progress.  

4.  Welcome  changing  requirements,  even  late  in  development  5.  Business  people  and  developers  work  together  daily  

throughout  the  project.  6.  Build  projects  around  mo4vated  individuals.    Give  them  the  

environment  and  support  they  need,  and  trust  them  to  get  the  job  done.  

   

Agile  Methodologies  

•  Extreme  Programming  (XP)  •  Scrum  •  Feature-­‐Driven  Development  (FDD)  •  Adap4ve  So7ware  Process  •  Crystal  Light  Methodologies  •  Dynamic  Systems  Development  Method  (DSDM)  

•  Lean  Development  

Scrum  

    A scrum is a term from rugby.

Scrum is a way of re-start after minor violation, where a group of players tries to push the ball obtain control.

Scrum  Flow  

Sprints  

•  Scrum  projects  consist  of  a  series  of  "sprints"  •  Typically  2-­‐4  weeks  in  length.  •  A  fixed  constant  length  gives  a  beRer  work  rate.  •  Features  are  designed,  built  and  tested  during  a  sprint.  

•  Customer  can  not  change  job  during  a  sprint.  •  Have  a  sprint  goal.  A  brief  statement  about  the  focus  of  the  work  of  the  upcoming  sprint.

   

Scrum  Framework  

   

Product  Owner  

•  Is  the  voice  of  the  customer.  •  Defines  the  features  of  a  product.  •  Determines  the  release  date.  •  Responsible  for  the  profitability  of  a  product.  •  Its  mandate  is  to  make  decisions.  •  Priori4zes  the  product  features  based  on  market  value  

•  Change  features  and  priority  every  itera4on,  if  desired.  

•  Accepts  or  approves  work  results.    

Team  

•  Complete  (all  skills)  •  Self  and  self-­‐learning  •  No  permanent  jobs  •  5  to  9  people  •  Work  together,  not  individually.  •  Involved  •  Produc4ve  and  fun  •  Preferably,  cross-­‐func4onal.      

Scrum  Master  •  Is  not  a  project  manager!  Facilitates  the  team.  •  Responsible  for  the  importa4on  and  compliance  with  Scrum  

values  ��and  prac4ces.  •  Solves  problems  for  the  progress  of  projects  iden4fied  by  the  

team,  so  that  the  goal  of  Sprint  and  the  deliverables  are  met.  •  Ensures  that  the  team  is  fully  focused,  opera4onal  and  

produc4ve.  •  Ensures  that  all  roles  and  func4ons  work  together.  •  Shields  the  team  from  external  disturbances  during  the  sprint.

   

Scrum  Framework  

   

Sprint  Planning  

Sprint  Planning  

Daily  Scrum  •  Daily,  15  minutes,  standing.  •  Not  meant  to  solve  problems.  •  Anyone  outside  the  team  may  be  present,  only  team  

members  are  ac4ve  part  (speaking).  

•  Helps  to  avoid  unnecessary  mee4ngs  (e  g  weekly  progress  mee4ng)  

•  Are  not  intended  to  state  the  progress  or  management.  – What  did  you  do  yesterday? – What  you  are  going  do  today? –  Are  there  any  restric4ons  that  the  comple4on  of  the  sprint  at  risk?

   

Daily  Scrum  

Sprint  Review(Demo)  

•  The  team  presents  the  results  of  the  last  sprint  through  a  demonstra4on  of  the  func4onality  built.  

•  Informal,  no  slides,  max  2  hours.  •  The  whole  team  takes  part  in  the  demonstra4on.  

•  Stakeholders  and  managers  are  welcome  to  aRend.

   

Sprint  Retrospec4ve  •  Is  held  a7er  each  sprint  •  Consider  what  works  and  what  does  not  work.  •  Priori4za4on  of  the  improvement.  •  Ac4on  items  are  defined  to  ensure  that  real  improvements  takes  place  in  the  next  sprint  (s).  

•  The  whole  team  takes  part  (Scrum  Master,  Product  Owner,  Team).  

•  Dura4on  vary  depending  on  the  retrospec4ve  approach,  team  size,  length  sprint.

•  Usually  30-­‐60  minutes  

   

Scrum  Framework  

Product  Backlog  •  The  requirements  •  To  Do  list  of  all  the  work  required  in  the  project.  •  Expressed  from  the  user  /  client.  •  Not  how  but  why.  •  By  priority  (by  product  owner.)  •  Itera4ve  (changes  ok,  for  each  sprint).  •  Visible.  •  Items  es4mated  effort  required  (by  team).  •  User story format: As <type of user> I want<some goal> so

that <some business reason>.

   

Product  Backlog  

Sprint  Backlog  

•  List  of  work  done  in  the  next  sprint.  •  Breakdown  of  features  into  tasks  (1-­‐16  hours).  •  Tasks  are  not  assigned  to  team  members.  (More  variety  and  crea4vity.  No  knowledge  islands)  

•  Tasks  are  es4mated  by  the  team  with  Planning  Poker.  

•  Tasks  are  picked  based  on  the  right  priori4es  and  the  skills  of  team  member.  

•  Is  usually  visualized  by  a  Scrum  board

   

Planning  Poker  

Scrum  Board  

Scrum  Board  

Itera4on  Burn-­‐down  Chart  

Release  Burn-­‐down  Chart  

Defini4on  of  Done  

•  Is  determined  by  the  team  •  Completed  work  must  meet  this  defini4on    •  Elements  to  consider  include:  

–  Coding style –  Code comment –  Peer review –  Units tests –  Document –  Manual –  ???

   

Scrum  Flow  Summary  

Summary  •  Scrum  is  (almost)  'Magic':  

– Timely  feedback. – Focus  on  working  product. – Priori4ze  on  added  value. – Not  plan  ahead  in  detail. – Self-­‐management  and  responsibility. – Clear  roles  and  responsibili4es.

   

To  be  con4nued…