The  case  of  Agile  project:  processes  and  benefits    This  article  is  intended  for  managers  of  products  and  technologies.  It  describes  the  elaboration  of  Agile  on  the  example  of  using  flexible  methodology.  Using  this  process  we  managed  to  produce  a  high  quality  product  in  a  short  time.    At  the  same  time  nobody  was  hurt  or  overworked.  If  only  a  little  and  with  pleasure.  

About  us  We  are  a  small  elaboration  company;  we  lead  4-­‐6  projects  monthly.  Our  specialization  is  mobile  applications,  but  we  also  develop  backends  and  interfaces  for  the  loyal  clients.  We’d  been  working  for  a  long  time  on  the  Russian  market;  this  project  is  one  of  several  Western  cases.  

About  the  project  Daily  Present  is  Austrian  Startup  in  the  field  of  content  marketing.  They  propose  to  accommodate  the  story  in  iOS  application  and  website  to  the  brands,  and  provide  game  service  and  awards  for  training  and  sharing  content  to  users.  Our  challenge  was  to  elaborate  Android  application  with  the  same  functions  and  integrate  it  with  the  existing  service.    

Challenges  of  the  project:  - hard  deadline  release  –  9  weeks  from  the   date of  commencement  of  works  - we  don’t  have  much  information,  but  what  we  have  is  in  German  - we  could  speak  with  the  team  before  starting  but  they’ve  moved  into  another  project  

and  didn’t  support  existing  solution.    

 

 

Methodology  Fortunately  we  had  an  expertise  in  gamification  and  we  had  some  idea  about  operating  principles  of  such  application.  But  we  still  had  to  study  the  situation;  we  saw  all  technical  details,  which  could  be  opened  up  in  the  process  of  elaboration.  Maybe  it  was  the  main  reason  why  we  began  to  frame  the  application  for  Agile.    

It  would  allow  us  to  save  our  face  in  the  date  of  release.  For  9  week  releases,  even  if  we  hadn’t  realized  all  functions,  we’d  see  the  weakest  points  from  the  very  beginning  but  not  in  a  week  before  release.    

Assessment  and  project  plan  So,  the  client  asked  us  to  give  the  assessment  of  application  (at  least  approximately).  There  were  no  technical  assignments  except  for  existing  application  iOS.  Then  we  wrote  the  functions  of  application,  in  terms  understandable  for  users,  in  our  terminology  user  story.  The  formula  is  simple:  as  (type  of  use)  I  want  (function  description)  to  (description  benefit).  

 

Thereafter  we  thought  from  the  viewpoint  of  development  and  management  of  application  and  finished  writing  more  stories  in  Backlog.  Such  method  of  describing  problems  isn’t  correct  enough.  But,  what  is  important,  that  could  be  understandable,  prioritize  and  have  a  freedom  in  choice  the  variant  in  selecting  embodiment  (from  hours  to  weeks).  We  appreciated  and  pitched  it  in  stages.  We  saw  that  1  creator  isn’t  enough,  and  we  added  another  one  to  the  team.  The  last  2  weeks  we  left  on  polish  –  animation  interface,  debugging  the  errors,  and  preparation  for  publication.    

Team  and  Tools  Totally  6  persons  participated  in  the  project  –  I,  as  a  Product  Manager,  2  Android  developer,  QA  (tester),  the  designer  has  adapted  graphics,  service  station  helped  to  integrate  the  server  and  analyzed  the  old  code  on  iOS.  For  the  project  management  we  used  Jira,  test  cases  worked  in  a  text  editor.  We  have  adopted  OC  Android,  for  the  test  we  had  devices:  lg  nexus,  Samsung  galaxy  s3  and  s4,  and  also  noname  the  Chinese  device.  We  chose  a  week  as  a  period  of  the  sprint  for  this  project.  

Backlog  refinement  meeting  Before  starting  the  operation  the  team  had  a  very  superficial  understanding  of  the  nature  and  objectives  of  the  project.  In  order  to  understand  the  details  of  the  problems  we  organized  Sprint  Refinement  Meeting  (1hour)  before  starting  the  work  and  every  month  before  new  version.  The  goal  of  the  meeting  was  to  check  with  the  product  manager  and  be  more  exact  in  questions  about  user  story.  The  result  of  this  meeting  is  goals  clear  to  everybody,  override  in  the  ticket  tracker  on  priorities  and  taking  into  account  the  issues  raised.  

Sprint  planning  meeting  Directly  on  the  day  of  the  sprint  we  organize  Sprint  Planning  Meeting  (1  hour)  -­‐  there  the  team  views  the  labor  costs  for  feature  and  determines  the  content  of  the  sprint.  For  the  assessment  we  use  Story  Points  –  the  abstract  units  (1,  3,  7…)  which  allow  to  estimate  the  complexity  of  the  goal.  For  more  pleasure  of  the  process  we  bought  special  cards  with  these  values,  for  all  the  participants  to  be  able  to  show  their  assumptions  simultaneously.    

 

 

Initially,  imagine  that  1  point  =  1  hour,  but  the  result  of  the  work  of  our  team  in  this  case  was  on  the  level  35  –  48  points  for  2  programmers.  The  point  is  in  combining  the  results,  debugging  errors,  additional  data  collection.  With  this  approach  we  focus  not  on  the  working  hours  but  on  the  contribution  to  the  value  of  the  application.  It  also  displays  the  progress  on  our  list  of  stories  more  realistic:  

 

 

The  content  of  the  sprint  and  daily  scrum      When  a  set  of  the  stories  was  selected  and  the  team  (which  is  important)  vouched  them  to  do  during  the  sprint,  everybody  starts  the  work.  The  Jire  story  includes  such  stages:  new,  in  working,  test  and  ready-­‐made.  The  stories  which  are  in  the  status  of  “test”  can  already  be  tested  and  returned  for  revision,  if  the  problem  is  found.  

Our  service  station  controls  minimizing  developers’  multitasking  –  in  one  time  for  1  developer  should  be  1  task  in  1  ideally.  Otherwise,  when  there  are  many  tasks  in  the  work  –  it  is  impossible  to  test  them  or  to  understand  the  progress.    

To  analyze  the  progress  and  difficulties  every  day  our  team  meet  for  5  minutes  and  share  about  what  has  been  done,  what  I’m  working  on  now  and  if  there  are  any  problems.  

Using  this  approach,  the  team  is  always  informed  and  assembled  as  a  team  in  rugby.  

 

 

Sprint  Retrospective  +  Reports  When  the  week  passes  away  the  team  collects  the  version  and  reports  about  the  made  function.  Our  client  in  this  project  is  CEO  and  he  is  very  busy.  In  order  to  help  him  to  control  I  just  recorded  the  video  review  of  the  new  version  and  showed  on  the  device  what  we  have  added  in  this  version  and  told  what  we  plan  to  do  next.  

From  time  to  time  we  succeeded  to  do  a  little  more  or  less  than  had  been  planned.  

At  the  same  time  we  have  never  had  finished  functional  in  version.  Just  what  is  useful  works  fully  and  can  be  checked.  For  example,  the  developers  often  set  the  goal  “develop  the  architecture”  the  manager  can’t  check  it.  When  you  need  to  invite  your  friends  and  you  can  see  the  least  of  your  friends  –  it  is  visually  and  precisely.    

Documentation    According  to  the  plans  we  have  one-­‐year  support  and  development  of  application.  But  we  weren’t  idle  and  had  made  the  documentation  in  English.  There  is  a  good  rule  for  programmers  when  making  a  decision.  If  this  project  is  for  someone  to  promote  tomorrow  what  he’ll  think  about  the  previous  developer.  If  we  have  the  words  of  gratitude  –  the  decision  is  right.  

Conclusion  1.  It  Works  and  is  Released  in  Time  First  of  all,  as  a  product  manager,  I  really  appreciated  working  soft  from  the  first  week  of  operation.  Even  when  it  is  1-­‐2  final  screen,  it  is  better  than  a  large  volume  but  in  the  process.    

If  we  suddenly  saw  that  we  didn’t  have  time  or  we  had  the  resource  dropped  out  (people  get  sick,  computers  break  down,  etc.)  we  would  pass  a  good  application  in  time.  We  could  get  less  money  for  the  less  volume  of  work  and  functions.  But  it  is  incomparable  with  fever  and  Epic  Fail  in  the  night  before  the  deadline.  

Conclusion  2.  Transparency  of  progress  We  are  fortunate  to  have  professionals  who  love  their  work.  And  our  expectations  were  often  exceeded.  At  the  same  time  it  is  very  easy  to  see  the  contribution  to  the  project  of  each  member  of  the  team,  for  example  in  closed  point  story.  

Conclusion  3.  Harmony  in  the  team  by  the  end  of  the  project  One  of  the  principles  of  Agile  is  self-­‐organizing  of  the  team.  In  complex  project  directory  management  isn’t  the  best  solution.  The  participants  shared  their  knowledge,  supported  each  other  and  found  common  approaches  in  solving  problems.    

If  your  team  is  involved  in  the  project  –  give  them  an  opportunity  to  react  and  you’ll  see  the  motivation  to  do  the  best  work.  

Improvement  of  existing  functions  A  very  common  mistake  in  the  construction  of  the  product  is  overloaded  with  functions.  The  result  is  ugly  and  not  usable  monsters.  

 

 

Intermediate  versions  allow  to  see  the  imperfections  of  the  current  system  and  put  their  improvement  into  a  process.  Google  says  that  they  spend  80%  on  the  improvement  of  current  functional  and  only  20%  on  the  addition  of  a  new.  On  the  market  the  solution  with  5-­‐6  ideal  functions  bypass  other  with  100  but  raw  and  undesirable  ones.  

 

Client  Quote  ______________________________