Mobile  AMO  Intern  3rd  Year  Internship  Report  

Enterprise

 

Juan  Alejandro  MOYA  GRAJALES  3rd  Year  student  Promotion  2012  

School

     

  2  

Acknowledgements  First  I  would  like  to  thank  the  Universidad  de  Los  Andes  for  giving  me  not  only  the  opportunity   to   participate   in   a   double   degree   exchange   program,   but   also   for  providing  me  a  strong  academic  basis  that  allowed  to  succeed  abroad.    On  the  other  hand,  by  integrating  the  École  des  Mines  de  Saint-­‐Étienne,  I  was  able  to  broaden  my  knowledge  through  its  vision  of  generalist  engineering,  making  of  me  an  integral  professional.    As  for  my  internship  experience,  I  thank  my  colleagues  that  welcomed  me  from  the   first   day,   considering   me   as   another   member   of   the   team.   I   give   special  thanks  to  Betty  Prima,  my  enterprise  tutor,  who  trusted  me  with  responsibilities  that  promoted  my  professional  growth.    Finally,  I  would  like  to  express  my  feelings  of  gratefulness  to  my  family  that  has  supported  me   in  every   step  of  my   life.   In   spite  of   the  distance,   they  have  been  unconditional   to   me,   giving   me   the   strength   to   overcome   the   most   difficult  situations  and  joining  me  in  joy.        

 

  3  

Abstract  I  worked  as  an  intern  at  Air  France  during  6  months.  I  was  assigned  to  the  team  in  charge  of  the  main  mobile  application  and  I  had  the  position  of  AMO  (Assistant  à  la  Maîtrise  d'Ouvrage).  There  are  3  sub  teams  in  the  project:  the  IT  in  charge  of  development,  the  AMO  in  charge  of  functional  specifications  and  testing,  and  the  Business   in   charge   of   the   definition   business   requirements.    We  work   in   agile  method,   specifically   using   Scrum.   The   sprints   have   duration   of   three   weeks,  where   daily   meetings   are   held   every   morning   as   well   as   weekly   meetings   of  Refinement.  In  order  to  have  an  effective  communication  we  made  constant  use  of  phone  and  videoconference  as  well  as  face-­‐to-­‐face  meetings  at  the  end  of  each  cycle.      As  general  mission,  I  participated  in  evolutions  of  the  next  version  of  the  mobile  application,   this   time   including   a   format   for   tablets.   My   assignments   as   AMO  were   divided   in   two   phases.   First,   in   the   upstream   phase,   I   had   to   gather   the  business   requirements   and   then   define   the   User   Stories   and   User   Acceptance  cases.  Later,   in   the  downstream  phase,   I  would  perform  functional   tests  on   the  application,  taking  as  support  the  User  Acceptance  cases.  Then,  according  to  the  tests,   the  User  Story  was  reopened  or  validated.  This   task  demanded  synthesis  capability,  good  writing  skills  as  well  as  rigor  when  testing.  During  my  internship  I   participated   to   7   entire   sprints  where   some   of   the  main   functionalities  were  developed,   including   but   not   limited   to   the   booking   management   page,   the  booking  search  page,  the  dashboard  for  Flying  Blue  accounts  and  the  Home  Page.  Throughout  my   time   as   intern,   three   alpha   versions  where   released.   Although  my  internship  ends  before  the  beta  release,  I  can  say  it  is  the  combined  effort  of  all  the  sprints  containing  all  the  ‘must  have’  features  and  it  will  represent  the  so-­‐called  Minimum  Valuable  Product.    Additionally,  I  was  assigned  on  a  specific  mission  concerning  the  implementation  of   the  Check-­‐in  process   through  an  API  developed  by  KLM.  This  was  held   as   a  POC  (Proof  of  Concept)  because  the  API  is  still  in  development.  The  objective  was  to  make  an  assessment  on  whether  the  API  was  ready  to  be  consumed  or  not.  It  was   also   the   opportunity   to   develop   the   check-­‐in   process   in   native,   given   that  currently  we   used   an   embedded  web   view.   In   this   project   I   was   given   almost  total  autonomy  and  I  had  to  work  together  with  a  developer  in  front  end  and  a  developer   in   back   end.   This   mission   drove   me   through   three   different   roles.  Firstly,  acting  as  Business  I  had  to  define  the  requirements  and  the  mockups  for  the   check-­‐in  process   in  native.  Then   as  AMO   I  wrote   the  User   Stories  with   the  corresponding  Acceptance   cases   and   I  performed   tests   in  order   to  validate   the  development.  Finally,  as  Project  Manager,  I  organized  weekly  meetings  and  I  had  interactions  with  KLM’s  API  team.  As  result,  there  are  the  User  Stories  and  User  Acceptances  cases  that  were  formalized,  there  were  also  factorizations  made  to  the  check-­‐in  process  making   it  adapted   for  mobile  devices  and   finally  we  were  able   to   prove   the   state   of   immaturity   of   the   API,   making   it   impossible   to   be  consumed  today.        

  4  

Table of contents  Glossary  ..............................................................................................................................................  5  Introduction  ......................................................................................................................................  7  Enterprise  ..........................................................................................................................................  8  General  presentation  ........................................................................................................................................  8  Digital  strategy  ...................................................................................................................................................  8  Mobile  team  ..........................................................................................................................................................  9  

Agile  method:  Scrum  ....................................................................................................................  10  Origins  ..................................................................................................................................................................  10  Development  lifecycle  ....................................................................................................................................  11  Benefits  ................................................................................................................................................................  12  Scrum  ....................................................................................................................................................................  13  Scrum  Roles  ........................................................................................................................................................  13  Scrum  Artifacts  .................................................................................................................................................  14  Scrum  Events  .....................................................................................................................................................  18  

General  mission  .............................................................................................................................  21  The  project  .........................................................................................................................................................  21  Methodology  approach  .................................................................................................................................  22  Assignments  .......................................................................................................................................................  27  Results  ..................................................................................................................................................................  29  

Specific  mission  .............................................................................................................................  32  The  project:  POC  Internet  Check-­‐In  .........................................................................................................  32  Methodology  approach  .................................................................................................................................  33  Challenges  ...........................................................................................................................................................  33  Responsibilities  .................................................................................................................................................  36  Results  ..................................................................................................................................................................  37  Areas  of  improvement  ...................................................................................................................................  40  

Professional  analysis  ...................................................................................................................  42  Personal  analysis  ..........................................................................................................................  44  References  .......................................................................................................................................  46  Annex  A:  ICI  flow  comparison  ......................................................................................................  i  

  5  

Glossary  AMADEUS  It  is  a  Global  Distribution  System  for  travel  and  tourism.  It  was  created  in  1987  by  Air  France,  Iberia,  Lufthansa  and  SAS  with  the  objective  of  connecting  travel  agencies   and   consumers   in   real   time.   AMADEUS   IT   Group   was   formally  established   to   be   in   charge   of   the   system’s   administration,   having   its  headquarters  in  Madrid,  Spain;  and  its  data  center  in  Erding,  Germany.  Currently,  it  constitutes  Air  France  IT  provider  for  flight  search,  booking  and  pricing.    AMO  Assistant  à  la  Maîtrise  d'Ouvrage  (in  English:  Project  Management  Assistant)  is  a  position  specific   to  French  enterprise  organization.   Its  objective   is   to  assist   the  Project  Manager  in  the  definition,  management  and  exploitation  of  a  project.  His  functions  are  only  from  the  management  point  of  view  and  they  do  not  concern  development  itself.    API  An  API  or  Application  Programming  Interface  is  a  set  of  functions  and  protocols  that   are   used   to   provide   an   IT   service.   An  API   describes   a   software  module   in  terms  of   its   inputs  and  outputs  as  well  as  the  types  handled.  It  should  facilitate  programming  by  providing  the  necessary  building  blocks  to  fulfill  a  service.        Back  end  The  back  end  is  the  part  of  the  architecture  that  holds  all  the  logic  to  provide  the  services  of  an  information  system.  This  is  the  part  in  charge  of  manipulating  the  information   in   the   database.   It   also   takes   into   account   all   the   business   rules  established  for  a  certain  service.    Build  A  build   is   the  executable   file   that  results   from  the  compilation  of   the  code.   It   is  also  referred  as  a  binary  because  only  a  machine  can  read  it.   It  contains  all   the  necessary  resources  like  images  and  modules  to  run  properly.    Front  end  The  front  end  is   the   interface  between  the  user  and  the  back  end.   It   is   in  other  words  a  presentation  layer  and  usually  little  logic  is  implemented  at  this  level.  A  mobile  application  represents  itself  the  front  end  because  it  is  the  one  that  is  in  direct  contact  with  users.  The  connection  to  a  back  end  is  not  always  necessary,  but  it  is  highly  recommended  for  digital  services.    Flying  Blue  It  is  the  Frequent  Traveler  fidelity  program  of  Air  France  and  KLM.  A  client  can  create   an  account   in   the  Flying  Blue  program   to   save  his  personal   information  and  also  to  earn  ‘miles’  for  discounts.      

  6  

Mockup  A  mockup   is   a   scale   or   full   size  model   of   a   design.   In  mobile   applications   they  refer   to   a   graphic   preview   of   the   user   interface,   which   takes   into   account  functional  scenarios.  It  is  a  form  to  visualize  UX  (User  Experience)  and  UI  (User  Interface)  design.    PNR  The   PNR   or   Personal   Name   Record   is   the   main   object   used   in   the   AMADEUS  system.  It  is  passenger's  travel  file  and  contains  all  the  necessary  information  to  identify  a  passenger  on  a  specific  travel.  It  allows  handling  groups  of  passengers,  reservation  states,  special  remarks,  connections,  migratory  information  and  any  other  information  concerning  a  booking.          

 

  7  

Introduction  As  part  of  the  academic  program  at  the  École  de  Mines  de  Saint  Etienne,  I  worked  as   intern  at  Air  France  during   six  months,  where   I  was   assigned   to   the  mobile  team  of  the  Digital  department.  More  specifically,  I  contributed  to  project  of  the  main  mobile  application  of  the  company.    In  this  document  I  will  describe  the  experience  I  had  during  my  internship  and  it  is  divided   in  5   sections.   First,   the   enterprise   and   its   field  of   activity   are  briefly  explained.  Then  I  will  dedicate  a  section  to  explain  in  detail   the  Scrum  method,  used   in   the  development  of  our  project.  Later  on,   I  describe   the   two  missions   I  was   assigned   on,   the   tools   employed,   the   tasks   I   was   trusted   with   and   the  corresponding   results.   Afterwards,   I   will   do   a   professional   analyze   about   the  work   environment   in   organizational,   social   and   human   terms.   Finally,   I   will  conclude  with  a  personal  analyze,  where  I  expose  some  personal  thoughts  on  the  dynamics  of  huge  enterprises  and  the  upcoming  wave  of  post  capitalism.      

 

  8  

Enterprise General presentation Air  France  was  founded  in  1933  from  the  union  of  the  five  operating  airlines  at  the   time:   Air   Orient,   Air   Union,   Compagnie   Générale   Aéropostale,   Compagnie  Internationale  de  Navigation  Aérienne  (CIDNA),  and  Société  Générale  de  Transport  Aérien  (SGTA).     Since   then   it   has   served   as   the   national   flag   carrier   until   2003  when  it  merged  with  KLM.  Nowadays,  it  is  still  the  primary  airline  in  France  and  one  of   the  major   in  Europe.   It  makes  part  of   the  group  Air  France  –  KLM  along  with  KLM,  Hop!,  Transavia  and  the  services  of  Cargo  and  Maintenance.  The  union  of  Air  France  and  KLM  reinforced  each  company  by  joining  most  of  their  services  into  a   joint  solution  and  preserving  the  prestige  of  each  trademark.  It  was  with  without  a  doubt  a  big  step  forward  and  it  has  marked  their  development  during  the  last  decade.    Air  France  –  KLM  main  activity  concern  passenger   transportation  representing  about   80%   of   total   revenue.   However,   the   group   is   also   implicated   in   cargo  delivery,  aeronautics  maintenance  and  even  catering  services.  The  group  counts  with  a   fleet  of  593  airplanes  –  mostly  Boeing  and  Airbus  aircrafts  –  and  serves  240  destinations  of  about  105  countries  around  the  world.  Air  France  introduced  its   first   A380   airplane   in   2009,   diversifying   its   long-­‐haul   destination   and  introducing  a  brand  new  business  travel  class.  Currently,  Air  France  counts  up  to  65000   employees   for   the   exploitation   of   their   activities.   Frédéric   Gagey   is   the  current  Chairman  and  CEO  of  Air  France,  replacing  in  2013  Alexandre  de  Juniac,  who  in  turn  became  CEO  of  the  group  Air  France  –  KLM.      Recently,   Air   France   has   been   confronting   a   financial   crisis   that   is   originated  from  the  high  exploitation  costs  that  concurrent  companies,  especially   low-­‐cost  airlines,  seem  to  manage  better  or  simply  do  not  have.  To  stay  competitive,  Air  France  had  launched  the  plan  Transform  2015  as  a  first  step  to  restructure  the  company.  It  was  followed  by  the  plan  Performance  2020  with  regard  to  close  the  existing   breach  with   the   other   competitors   in   terms   of   costs   of   operation.   The  plan  is  based  on  three  main  axes:  competiveness,  client  experience  enhancement  and  working  performance.  However,  this  plan  has  received  a  wide  criticism  due  to  its  drastic  measures  to  reverse  the  trend,  as  the  group’s  current  net  revenue  is  negative.  One  of  the  biggest  polemics  concerns  the  cancelation  of  10  to  12  long-­‐haul  flights  that  are  not  longer  rentable  for  the  company,  which  may  implicates  the  suppression  of  about  3000  jobs.      

Digital strategy In  spite  of  the  financial  crisis  that  Air  France  is  currently  facing,  the  Information  Systems  Direction,   keeps   strong  by   showing   increasing   revenues   and   lowering  costs  through  better  performance  every  quarter.  Air  France  is  investing  in  digital  solutions  because   there   is   a  proven  belief   that   they  will  help   to   take  afloat   the  finances.  There  are  three  main  development  lines:  mobility,  social  networks  and  

  9  

big   data.   Mobility   is   understood   for   both   internal   and   external   clients,   with  projects   like   PilotPad,   intended   for   crewmembers,   contributes   to   transforming  the  businesses,  improving  pro-­‐activeness  and  efficiency.    On  the  other  side,  with  about  70%  of  passengers  in  possession  of  smartphones,  mobile  applications  play  a   strategic   role   to   stay   in   constant   touch   with   the   client,   providing   them   the  information  they  need,  when  they  need  it.  Social  Networks  on  their  side,  offer  the  possibility   of   new   channels   of   information   and   interaction  with   costumers.  Air  France   is   in   the   top   5   airlines   on   Facebook   and   is   also   present   on   Twitter,  Google+,  Pinterest  and  YouTube.  Finally,  big  data  refers  to  the  analysis  of  all  the  information  produced  through  digital  channels  like  websites  and  mobiles  apps.  It  offers  a  window  to  better  know  the  costumers  and  market  trends,  consequently  making  better  decisions.      The  Digital  department  makes  part  of  the  support  activities  and  is  regroups  the  website   –   formerly   referred   as   B2C   –,   the   mobile   website,   the   mobile   app  applications   as   well   as   the   social   networks   and   all   other   kind   of   e-­‐Commerce  related   activities.   The   projects   held   by   the   department   are   usually   oriented  towards  external  clients,  which  implies  that  all  the  customer  chain  is  carried  out  from  searching,  booking  and  paying  a   flight   to  online   check-­‐in   and  operational  notifications  of  his  flight.      

Mobile team The   mobile   team   was   originally   dedicated   to   the   mobile   responsive   website,  referred   as   BMW,   that   allowed   to   cover   the   new   offer   of   mobile   phones.  However,  it  could  not  stop  there  and  in  2012  the  project  for  a  mobile  application  on   iOS   and   Android   platforms   was   launched.   The   application   fit   better   the  mobility  needs,  shifting  traffic  from  the  B2C  and  the  mobile  website.  In  addition  to   the   main   app,   there   is   also   the   Air   France   Press   mobile   application   that  broadens   the   digital   offer   by   proposing   multimedia   content   like   journals,  magazines  and  podcasts  to  the  costumers.  In  the  reports  from  the  second  quarter  of  2015,  the  mobile  app  represents  3,4%  of  total  revenue  for  digital  channels,  but  counts  with  an  annual  growth  of  about  150%.    The  team  in  charge  of  the  mobile  application  is  composed  of  three  sub  teams:  the  IT   (Information   Technology),   the   AMO   (Assistance   à   Maîtrise   d’Ouvrage   or  Project  Management  Assistance)  and  the  Business.  The  IT  is  located  at  Toulouse  and  Valbonne  while  the  last  two  are  at  the  headquarters  of  Air  France,  at  Roissy  Charles  de  Gaulle.  They  are  conformed  by  10,  4  and  2  members  respectively,  a  total  of  16  persons  directly  implicated  in  the  project.  Additionally,  there  is  also  a  manager  taking  the  lead  of  each  of  them.        

  10  

“

Agile method: Scrum  Within  the  project  I  was  assigned  on  during  my  internship,  we  were  based  on  the  agile  method  Scrum,  which  is  why  I  will  explain  it  in  detail  in  this  section.  First  I  will  introduce  agile  methods  by  describing  its  origin  as  well  as  its  benefits.  Then  will  deeply  explain  the  Scrum  method   itself.  The  approach  taken  by  the  mobile  team  will  be  explained  in  the  section  corresponding  to  the  General  Mission.    

Origins The   history   of   informatics   traces   back   to   the   conception   of   the   first   calculator  based   on   mechanical   switches   and   it   was   boosted   by   the   invention   of   the  transistor  in  the  middle  50’s.  However,   it  only  acquired  great  magnitude  by  the  end   of   the   20th   century   with   the   revolution   of   personal   computers   and   the  deployment   of   Internet.   As   computers   advance   in   processing   power,   software  development   projects   increased   in   complexity.   Companies   from   all   industries  suddenly  had  a  great  appetite  to  integrate  computing  solutions  to  their  economic  activity,  the  potential  of  informatics  was  no  longer  questionable,  nobody  wanted  to  be  left  behind.  From  the  other  side,  the  developers  met  new  challenges  and  the  complexity   of   the   projects,   along  with   the   increasing   exigencies   of   the  market,  drove   them   to   integrate   concepts   of   project   management   into   software  development.  Therefore  in  the  middle  90’s,  in  order  to  break  with  the  traditional  “waterfall”  -­‐oriented  methods,  new  lightweight  methods  like  Scrum  and  Extreme  Programing  emerged  and  proved  their  efficiency,  as  can  be  seen  in  figure  3.    They  set  the  basis  of  what  we  refer  today  as  the  agile  methods.    

The  Agile  Manifesto  In   February   2001,   17   software   developers   from   Extreme   Programing,   Scrum,  DSDM,   Adaptive   Software   Development,   Crystal,   among   others,  met   to   discuss  about  the  future  of  these  lightweight  methods.  They  published  the  Manifesto  for  Agile  Software  Development:      

We   are   uncovering   better   ways   of   developing  software   by   doing   it  and  helping  others  do  it.  Through  this  work  we  have  come  to  value:    

Individuals  and  interactions  over  processes  and  tools  Working  software  over  comprehensive  documentation  Customer  collaboration  over  contract  negotiation  Responding  to  change  over  following  a  plan  

 That   is,  while   there   is   value   in   the   items   on  the   right,  we   value   the  items  on  the  left  more.       Kent  Beck  Mike  Beedle  

James  Grenning  Jim  Highsmith  

Robert  C.  Martin  Steve  Mellor  

  11  

” Arie  van  Bennekum  Alistair  Cockburn  Ward  Cunningham  Martin  Fowler  

Andrew  Hunt  Ron  Jeffries  Jon  Kern  Brian  Marick  

Ken  Schwaber  Jeff  Sutherland  Dave  Thomas  

   ©  2001,  the  above  authors  this  declaration  may  be  freely  copied  in  any  form,  but  only  in  its  entirety  through  this  notice.  

     In  addition  to  the  four  values  stated  in  the  manifesto,  they  also  wrote  a  dozen  of  principles   that  would  conform  a  group  of  good  practices   to   take   into  account.   I  will   not   quote   them   here   but   in   general,   they   make   allusion   to   thoughts   like  promoting  collaboration  environment,  welcoming  changes,  focusing  on  working  software,  self-­‐organization,  among  others.      Some  evolutions  have  been  made  since,  but  the  manifesto  sets  a  standard  for  any  agile  method.   It   is   important   to  clarify   that   the  values  and  the  principles  of   the  manifesto  constitute  a  mindset  rather  than  a  set  of  rules.  This  means  that  it  can  be  adapted   to  each  project   according   to   its   specify  needs  or   constraints,   and   it  can  even  be  applied  for  non  software-­‐related  projects.    

Development lifecycle Agile   methods   usually   break   with   the   traditional   sequential   development   by  organizing  the  project  in  iterative  and  incremental  cycles.  In  other  words  instead  of  seeing  the  project  as  a  whole,  it   is  divided  into  smaller  parts  that  are  usually  independent   between   them   and   each   of   them   contribute   to   the   value   of   the  project.      In  traditional  projects  we  might  find  the  following  general  roadmap:  

 Figure  1  Traditional  lifecycle  

 On   the   other   hand,   as   we   can   see   in   figure   2,   agile   method   outlines   the  integration   of   all   the   phases   for   each   cycle,   at   the   end   of   which,   a   potentially  deliverable   increment  of   the  product   is  obtained.  The  number  of   iterations  and  their  duration  are  defined  according  to  the  complexity  of  the  project  and  the  size  of  the  team.        

Business  requirements   Developement   Tests   Production  

  12  

   

 

 

Benefits The  approach  taken  by  the  agile  method  encourages   flexibility  and  at   the  same  time  it  allows  a  better  performance  since  every  team  contributes  throughout  the  entire  project.  Each  team  is  slightly  shifted  in  time  according  to  its  upstream  or  downstream   participation   on   a   cycle.   For   instance,   the   business   team   will   be  most   likely   implicated   in   the   upstream   section   since   they   define   the   business  requirements  but  they  also  take  part  in  the  downstream  by  deciding  whether  the  new   increment   goes   to   production   or   not.   Given   the   frequency   of   iterations,  teams  are  seamlessly  distributed  into  different  cycles.  Additionally,  as  there  is  a  continuous   assessment,   it   gives   the   opportunity   to   change   the   direction   of   the  project  and  thus,  greater  success  rates  than  conventional  methods  are  achieved  as  the  graphic  below  demonstrates.  

 Figure  3  Waterfall  vs.  Agile  success  rates    

 Furthermore,  as  the  increment  at  the  end  of  each  cycle  is  potentially  deliverable,  added   value   is   driven   right   from   early   stages   of   the   project   and   thus   risk   is  considerably  reduced.  

Source:  The  CHAOS  Manifesto,  2013  

Production

Production

Production

Development Development Development Client

Figure  2  Agile  lifecycle  

  13  

 

 

In   the  graphic  above  we  can  appreciate  on  the  right  side   that   the  project  using  the  waterfall  method  accumulates  the  risk  over  time  because  it  depends  on  the  very   last  delivery   to  estimate   its  value.  On  the   left  side  we  can  observe   that  by  delivering   small   parts   almost   from   the   beginning,   the   value   raises   because   the  project   starts   showing   some   results   and   consequently,   towards   the   end,   with  only  a  few  functionalities  still  missing,  the  project  is  no  longer  threatened  of  total  failure.    In   simple  words,  Agile   is   an   iterative  and   incremental  methodology   for  project  management   with   a   mindset   that   promotes   flexibility   while   ensuring   added  value  to  the  final  product.    

Scrum Scrum  can  be  defined  as  a  framework  within  which  people  can  address  complex  problems  and  productively  and  creatively  deliver  product  of  the  highest  possible  value.   The   word   has   its   origin   in   rugby,   where   a   scrum   is   a   tight   packed  formation   of   players   trying   to   gain   possession   of   the   ball.   However,   it   is  more  related   to   the   way   of   working   of   one   cross-­‐functional   team   through   different  phases  trying  to  go  the  distance  as  a  single  unit.    

Scrum Roles Product  Owner  The   product   owner   represents   the   business   and   the   stakeholders.   This   is   the  person  accountable  for  the  Product  Backlog,   leading  the  way  of  the  project  and  ensuring   that   the   team  delivers   business   value.   The   product   owner   is   also   the  bridge   of   communication   between   the   team   and   the   stakeholders;   he   is   then  responsible   for   the  prioritization  of   the   items   in   the  backlog  according   to   their  relevance.  He   sets   the  milestones   in   the   roadmap,   announces   the   intermediate  releases  and  reroutes  the  direction  of  the  project  when  needed.    

RIS

K

time

value delivery

value

valu

e

RISK

time

value delivery

Figure  4  Waterfall  vs.  Agile  risk  over  time  

Source:  Scrum  Foundations,  2015  

  14  

Scrum  Master  His   main   responsibility   is   to   understand,   facilitate   and   coach   the   team.   He  removes   obstacles   and   impediments,   facilitates   communication   and   creates   a  beneficial  environment  for  the  team  self-­‐organization.  He  is  also  the  guardian  of  the   Scrum   process   by   organizing   the   meetings,   keeping   the   team   focused,  collecting  and  analyzing  project  indicators  in  order  to  improve  over  time.  He  also  helps   the  product  owner   to  maintain   the  product  backlog   in  a  way   that   allows  the  project   to  advance  at  a  constant  pace.   It   is   important   to  say   that   the  scrum  master  does  not  necessarily  have  project  management  responsibilities;  his  main  role  is  to  be  a  facilitator.    

Development  team  This   is   where   actual   work   occurs.   They   commit   with   the   product   owner   for  delivering  potentially   shippable   increments   at   the   end  of   each   cycle.   The   team  must   be   cross-­‐functional,   in   other   words,   they   must   posses   all   the   necessary  skills   to   develop   the   final   product.   It   is   also   recommended   the   team   to   be  conformed  by  no  more  than  9  people.  Another  characteristic  is  that  the  team  is  self-­‐organized,   despite   the  hierarchically   superior   figure  of   the  product   owner.    This  means  that  the  team  only  negotiates  the  commitments  with  product  owner  but  the  way  of  achieving  those  commitments  is  entirely  up  to  them.  Development  teams  are  usually  more  successful  when  long-­‐term  full-­‐time  members  integrate  them.    

Scrum Artifacts Product  Backlog  It   is   an   ordered   list   of   requirements   that   constitute   the   final   product.   It   is  conformed  by  functionalities,  bug  fixed,  non-­‐functional  requirements  and  every  other   specification   that   makes   part   of   the   definition   of   the   product.   It   is   the  product  owner  that  orders  the  items  in  the  backlog  considering  the  risk,  business  value,  dependencies  and  date  needed.    Items   in   the   backlog   are   usually   written   as   a   user   story.   They   also   have   a  business  value  that   is   just  a  number  indicating  its  relevance  to  the  project.   It   is  recommended   to   choose  numbers   from   the  Fibonacci   series   (1,2,3,5,8,13….)   as  they   avoid   the   ambiguities   for   high  numbers,   for   example   choosing   between  8  and   9.   It   helps   to   create   a   true   separation   between   items   that   are   really  important   from  those  that  are  not.  On  the  other  hand,  we  can  also  assign  story  points  to  an  item  to  express  the  difficulty  for  its  development.  In  this  case  it  is  the  team   that  votes  during   the  Poker  Planning,  which   I  will   explain   later,   and   they  are  measured  as  well   in  number   from   the  Fibonacci   series.  The  business  value  and   the   story   points   serve   to   the   product   owner   for   the   organization   of   the  backlog,   prioritization   of   items   by   estimating   their   risk   or   by   calculating   their  return  on  investment  as  the  ratio  between  the  business  value  and  the  estimated  effort.    

  15  

The   product   backlog   is   the   main   tool   that   contains   all   requirements   of   the  changing   product.   It   is   important   to   establish   clear   rules   about   how   to   add   or  modify   items   in   the  backlog.  This   is  also  a  window   for   the   team  to  see  what   is  coming  next,  so  items  on  top  of  the  list  are  those  that  will  be  taken  into  account  in  the  next  cycle  and  therefore  they  should  be  well  defined  whereas  items  at  the  bottom  of  the  list  are  not  for  immediate  development  and  are  less  refined.    

User  stories  A  user  story  is  a  specific  way  of  describing  an  item  of  the  backlog.  A  user  story  is  usually  written  in  the  following  format:    In  order  to  <benefit>  As  a  <role>  I  want  <feature>    This  format  allows  to  clearly  seeing  who  the  target  client  is,  what  is  the  feature  that  will  be  developed  and  why  it  is  important.  The  how  is  not  explained  in  the  user  story,  it  is  the  development  team  that  decides  how  it  is  done.  Furthermore,  in   order   for   a   user   story   to   be   considered   well   defined,   it   should   follow   the  INVEST  guidelines:    

Independent  –  it  has  value  on  its  own  Negotiable  –  it  is  no  a  fixed  statement  Valuable  –  it  drives  business  value  Estimable  –  the  effort  needed  can  be  estimated  Small  –  the  team  can  afford  it  during  one  development  cycle    Testable  –  it  can  be  tested  and  validated  

 The  last  condition  constitutes  the  way  to  validate  a  user  story  and  considered  it  as  shippable.  To  do  so  a  table  of  Acceptance  Criteria  can  be  used,  containing  an  extensive   list  of  all   the   tests   to  be  performed.  The  use  of  explicit   tests  disrupts  any   ambiguity   that   is   contained   in   the   description   of   the   user   story   and   thus  allows  the  team  to  clearly  say  when  the  delivered  work  is  acceptable  or  not.    

Sprint  Backlog  The  sprint  backlog  is  the  list  of  items  that  are  going  to  be  developed  during  the  current  cycle  or  sprint.  The  list  of  the  sprint  is  filled  with  the  elements  on  top  of  the  product  backlog,  since  those  are  the   items  that  have  been  prioritized  by  he  product  owner.  The  items  are  added  one  by  one  during  the  poker  planning  until  the   development   team   considers   they   cannot   commit   to  more.   The   final   list   of  items   on   the   sprint   backlog   represents   the   team’s   commitment   towards   the  product  owner   for   the  current  sprint.  Once   the  sprint  has  begun,  no  additional  functionalities   can   be   added   to   the   sprint   backlog   except   by   the   development  team  itself.  When  the  sprint  finishes,  a  balance  is  made  and  if  there  are  still  items  that  have  not  been  validated  or  developed,  they  are  reported  to  the  next  sprint.      

  16  

During   the   sprint,   the   team   carries   out   a   single   dashboard   in   order   to   have   a  trace  of  the  progress  of  the  tasks  they  committed  to.  With  regards  to  promoting  self-­‐organization,  each  member  freely  chooses  the  tasks  he  feels  more  confident  with.  The  board  is  usually  composed  by  four  columns,  in  which  tasks  are  stacked.  The  first  column  is   ‘To  Do’,  constituted  the  sprint  backlog  at  the  beginning.  The  second  one   is   ‘In  Progress’  and  contains  the  elements  that  are  being  developed  and  have   already  been   auto   assigned  by   one   of   the  members   of   the   team.  The  third   column,   ‘To   Validate’,   comprehends   the   items   that   have   been   developed  and  are   ready   to  be   tested.  The   last   column   is   ‘Done’,   regrouping   the  elements  that  have  been  approved  and  therefore  that  are  considered  as  shippable.  In  the  following  picture  we  can  see  a  typical  sprint  board  using  post-­‐its,  each  of   them  representing  an  item  of  the  sprint  backlog.  

   

Figure  5  Scrum  Board  using  Post-­‐Its  

Increment  Is  the  sum  of  all  the  user  stories  that  are  considered  as  done,  and  therefore  they  constitute  a  potentially  shippable  increment  to  the  product.  Moreover,  it  should  be   backwards   compatible,   not   conflicting   with   previous   developments.   The  product   owner   has   then   the   decision   to   release   it   or   not,   in   any   case,   the  increment  adds  up  value  to  the  final  product.    

Definition  of  Ready  This   is   the   list  of  conditions  that  are  clearly  set  to  consider  that  a  user  story   in  the   product   backlog   is   prepared   enough   to   start   the   development   phase.  Therefore,   all   user   stories   should   meet   the   definition   of   ready   before   the  beginning  of  the  sprint.  It  demands  the  necessary  information  such  as  the  degree  of   detail   of   the   description,   the   user   acceptance   criteria   already   declared,   the  

Source:  http://pragmaticscrum.info/bigvisiblecharts    

  17  

prototypes   or   graphical   content   and   any   other   kind   of   support   that   will   be  needed   to  deliver   the  user  story.   It   is   important   to  notice   that   the  definition  of  ready   can   –   and   most   likely   will   –   change   over   time   according   to   the   team’s  needs,  but  when  it  happens  all  members  of  the  team  must  be  told  and  consulted  about  it.    

Definition  of  Done  Whereas   definition   of   ready   intervenes   at   the   beginning   of   the   sprint,   the  definition  of  done  closes  the  cycle  by  establishing  the  standards  of  validation  of  any  user  story.  Although  acceptance  criteria  already  accounts  for  a  list  of  tests  to  be  performed  on  a  user  story,  the  definition  of  done  sets  a  general  agreement  of  when   something   can   be   considered   as   finished.   It   allows   al   the   participants   to  have   a   common   meaning   of   the   expected   result.   The   definition   of   done   may  demand  not  only  that  the  acceptance  criteria  have  been  validated,  but  also  that  the   code   is   commented,   that   the   documentation   is   delivered   or   even   the  deployment  on  different  test  environments.    

Sprint  Burn-­‐down  chart  In  order  to  trace  down  the  progress  of  the  sprint,  a  burn-­‐down  char  is  often  used.  It  allows  visualizing  the  amount  of  work  remaining  that  needs  to  be  done  before  the  end  of  the  sprint,  hence  its  name  ‘burn-­‐down’.  The  chart  is  updated  everyday  by  subtracting  the  effort  of  the  items  –story  points–  that  where  validated  by  each  member.   Additionally,   the   chart   offers   us   some   indicators   on   how   the   team   is  dealing   with   the   work   charge.   For   example,   a   team   who   delivers   most   of   the  tasks  at  the  beginning  of  the  sprint  would  indicate  a  light  work  charge  and  thus  the   team   should   be   able   to   take   greater   commitments   for   each   sprint.   On   the  other  side,  if  most  of  the  effort  is  delivered  towards  the  end  it  would  suggest  that  the  team  is  overcharged  and  thus  commitments  must  reevaluated  in  order  to  be  able  to  work  at  a  constant  pace.  Finally,   if  there  is  huge  jumps  in  the  curve  this  would  reveal  that  the  items  are  not  detailed  enough  and  they  should  be  split  in  smaller  parts.    

   

Figure  6  Burndown  chart  

Source:  https://fr.wikipedia.org/wiki/Burndown_chart    

  18  

 

Scrum Events Preparation  and  Kick-­‐off  meeting  Before  launching  a  team  to  work  in  agile  method,  some  preparation  needs  to  be  done.  During  this  time,  the  approach  the  team  is  going  to  take  is  clearly  defined.  This  means  setting  up  the  duration  of   the  sprint,  writing  the  definition  of  done  and  definition  of  ready,  assigning  the  roles  to  each  member  of  the  team  and  any  other  decision  regarding   the  organization.  Once   the   teams  has  all   the  elements  that  constitute  the  basis  of  work,  the  Kick-­‐of  meeting  takes  place,  making  clear  to  everyone  general  rules  and  the  methodology  adopted.    

Sprint  A  sprint  or  iteration  is  the  basic  unit  of  development  in  scrum.  It  is  a  time-­‐boxed  event  with  duration  between  on  week  and  one  month,  typically  2  weeks.  This  is  the  clock  that  keeps  the  team  advancing  at  a  constant  pace  and  it  should  not  be  changed  throughout  the  project.  It  is  useful  as  it  allows  the  team  to  measure  the  effort   they   can  provide  during  a   sprint   and   consequently   they   can   forecast   the  quantity   of   sprints   remaining   before   finishing   the   project.   As   it   has   a   constant  frequency,  the  team  can  calculate  its  velocity,  which  is  an  indicator  based  on  the  amount  of  effort  delivered  during  a  sprint.    Scrum  emphasizes  on  the  work  that  is  really  ‘done’,  which  in  the  case  of  software  that  is  fully  integrated,  documented,  tested  and  potentially  shippable.      Each  sprint  begins  with  the  sprint  planning  and  ends  with  the  sprint  review  and  retrospective.   Usually,   as   one   sprint   starts   immediately   after   the   other,   the  closure   of   the   previous   and   the   opening   meeting   for   the   new   sprint   are   held  together.      

Sprint  Planning  The  sprint  planning  is  held  at  the  beginning  of  the  sprint.  During  this  meeting  the  team  sets  a  goal   for   the  sprint  and  decides  which   items  of   the  product  backlog  are  going  to  be  developed  in  the  commencing  iteration.  The  selection  of  items  is  done   through   the  poker  planning,  as  explained  below.  This  meeting  should  not  be  very  long;  usually  4  hours  for  a  2-­‐week  sprint  are  enough.      

Poker  planning  Poker  planning   is   the  process   through  which   items   in   the  product   backlog   are  transferred   to   the   sprint   backlog,   and   thus   developed   in   the   current   sprint.   In  this   process   the   development   team   starts   with   an   amount   of   points   that  represent   amount   of   work   they   can   deliver   during   the   sprint.   Then,   all   the  members  of   the  development  team  vote  with  a  number  concerning  the  amount  of  effort  it  is  going  to  take  to  develop  a  particular  item.  If  the  votes  differ  largely,  then  a  discussion  takes  place  in  order  to  clarify  why  some  of  the  members  think  it   will   be   easy   to   develop   while   others   consider   the   opposite.   The   votes   are  

  19  

counted  again  after  the  discussion  and  when  they  coincide  towards  a  value,  then  a  number  is  chosen,  for  example  the  median,  and  the  story  points  are  assigned.  This  process  continues  until  the  development  team  has  spent  all  the  points  they  estimated  for  current  sprint.      

Daily  scrum  Everyday  at  the  same  time,  the  team  holds  a  meeting  during  which  each  member  of  the  team  answers  to  these  three  questions:    

• What  did  I  do  yesterday  in  order  to  achieve  the  sprint  goal?  • What  will  I  do  today  to  meet  the  sprint  goal?  • Do  I  see  any  impediment  or  obstacle  that  prevents  the  goal  to  be  met?  

 This   meeting   should   not   be   longer   than   15   minutes.   It   is   recommended   that  everyone  is  standing-­‐up  so  the  person  who  is  speaking  catches  the  attention  of  the   others   and   the   communication   becomes   fluent.   When   an   obstacle   is  identified,  the  people  concerned  set  up  a  meeting  later  in  the  day  to  analyze  the  problem  in  detail.    

Backlog  Refinement  In  addition  to  the  daily  scrum,  a  weekly  meeting  can  be  scheduled  to  prepare  the  items   that  will   be   developed  during   the  next   sprint.   It   is   a   preparation   for   the  sprint  planning  so  when  the  time  comes  there  is  only  the  final  details  missing  to  be  discussed.  During  this  meeting  items  in  the  backlog  are  split  into  smaller  parts  if   necessary   and   the   definition   of   ready   is   checked   to   ensure   that   the  development  can  start  without  obstacles.  It  helps  to  keep  all  the  team  informed,  to  anticipate  impediments  and  to  alleviate  the  burden  of  the  sprint  planning.  The  refinement  sessions  should  take  no  more  than  10%  of  the  time  of  the  sprint.    

Sprint  review  and  retrospective  At   the  end  of   the  sprint,   a   closure  meeting   is  held   in   two  parts.  First,   the   team  reviews  the  work  that  was  completed  and  the   items  that  where  still  missing  to  develop  or  validate.  This  is  also  the  opportunity  to  present  to  the  stakeholder  the  work  done  and  what  would  represent  the  product  increment  resulting  from  the  sprint.  However,  incomplete  work  cannot  be  demonstrated.      During   the   second  part,   a   retrospective  of   the  progress  of   the   sprint   is   carried  out.    The  objective  is  to  identify  the  positive  points  and  areas  of  improvement  for  the  next  sprint.  This  is  where  continuous  improvement  takes  place;  hence  all  the  members  of  the  team  are  encouraged  to  participate  actively.    

  20  

The   following   picture   illustrates   the   whole   cycle   of   development   in   scrum  method,  from  taking  an  item  from  the  product  backlog  until  it  constitutes  a  new  increment  of  the  final  product.    

Figure  7  Scrum  lifecycle  

Source:  Scrum  Foundations,  2015  

  21  

General mission The project Back   in   may   2013,   Air   France   decided   to   launch   a   project   to   create   its   own  mobile   application.   The   app  was   going   to   be   developed   internally   for   Android  and   iOS   platforms.   The  mobile   team,  which   by   then  was   dedicated   only   to   the  mobile  website,  had  just  acquired  a  new  responsibility,  splitting  them  in  two.  The  team  had   to   develop   a  mobile   application   from   scratch,   and   so   they   organized  almost   like   a   start   up.   To   reduce   the   complexity   and   thus   the   time   to  market,  some  of  the  most  complex  processes  such  as  the  ticket  purchase,  were  integrated  through   a   web   view,   embedding   the   mobile   website   within   the   app.   After   9  months   of  work   the   app  was   finally   launched   on   January   2014.   It  was   a   huge  success  for  the  whole  team,  but  they  could  not  stop  right  there.  The  next  version  of   the   app   was   already   on   the   plans   and   this   time   the   team   would   go   even  further.    

There  were  several  important  points  for  this  new  version,  one  of  them  being  the  integration   of   even  more   processes   in   native.   The   problem   of   integrating  web  views  in  the  application  is  that  the  user  interface  elements  are  not  optimized  for  tactile   screens.   Moreover,   as   the   all   the   resources   must   be   downloaded,   the  navigation  between  one  page  and  another  becomes  significantly  slow  compared  to   native   solutions.   On   the   other   side,   the   earlier   version   of   the   app  was   only  

Version 5 released in 2014 Version 6 to be released in 2016

Figure  8  Mobile  Application  comparison  

  22  

adapted  for  smartphones  thus,  one  of   the  major  goals   for   the  new  phase  of   the  project  was  to  prioritize  the  conception  of  the  app  for  tablets.  Finally,  it  was  also  the   opportunity   to   give   the   app   a   new   fresh   design   that   would   go   along  with  changes  happening  on  the  website  and  other  suggestions  from  the  Brand  Image  department.    Additionally,   it   is   important   to   understand   the   architecture   of   the   information  system,  as  shown  in  the  graphic  below.  In  the  front  end  we  can  find  the  mobile  application,  the  mobile  website  as  well  as  the  desktop  website,  not  shown  in  this  graphic.   On   the   second   level   there   is   the   integration   layer,   called  DALLAS   that  integrated  all  the  other  web  services  from  the  backend  into  a  single  one.  This  has  been  a  recent  change  and  although  some  direct  connections  to  the  web  services  still   exist,   the   idea   is   for   all   front-­‐end   applications   to   start   consuming   the  application   layer.   Finally   on   the   back-­‐end   there   are   all   the   information   system  that   actually   hold   the   processes   of   ticketing,   booking,   check-­‐in,   Flying   Blue  accounts,  among  many  others.        

 From  the  point  of  view  of  the  mobile  application,  there  are  two  direct  relations.  First  with  the  mobile  website,  as  we  have  integrated  some  processes  embedded  in  web  view,  we  have  to  coordinate  the  communication  of  information  between  them.   Second   there   is   DALLAS,   which   is   the   direct   back-­‐end   of   the   app.   They  provide  the  main  services  used  in  the  mobile  application,  which  is  why  we  are  in  constant  communication  with  them.      

Methodology approach In   this   section   I  will   describe   the   approach   of   the   scrum  method   taken   by   the  team.  To  do  so   it   is   important   to   take   into  account   the   internal  organization  as  describe  in  the  enterprise  section.  

Mobile app Front-end

Integration Layer

Back-end

DALLAS

AMADEUS

COMET Travel DB

CIS <…>

Mobile website

Figure  9  Information  System  architecture  

  23  

 

Scrum  roles  Some  adaptations  were  made  to  the  regular  scrum  organization,  from  which  we  can  highlight:    

• The  product  owner  is  one  person  from  the  AMO  • The   scrum   master   is   one   person   from   the   IT,   which   is   helpful   as   he  

constitutes  the  main  communication  bridge  • The   IT   team   is   considered   as   the   development   team,   working   on   both  

platforms,  Android  and  iOS  • The   total   size   of   the   team   exceeds   9   people,   but   the   complexity   of   the  

project  demands  it  • The   Business   team   is   in   charge   of   defining   the   requirements   and  

providing  the  respective  mockups  • The   AMO   is   in   charge   of   writing   the   user   stories,   definition   of   user  

acceptance  and  testing  before  validation    

Scrum  Artifacts  -­‐  Tools  To  manage  the  product  backlog  and  the  sprint  backlog  we  use  the  tool  JIRA,  from  the  software  provider  Atlassian.  It  is  an  issue  tracking  solution  that  offers  project  management  functions,  particularly  supporting  scrum  projects.  JIRA  allows  us  to  create  user  stories,  to  keep  track  of  improvements  as  well  as  bugs  and  to  handle  the  product  backlog  and  the  sprint  backlog.  Additionally,  there  is  a  scrum  board  where  the  current  sprint   is  managed  as  well  as  reports,   including  a  burn  down  chart,   that  are  automatically  generated.   In   the   following  picture,  an  example  of  the  scrum  board  can  be  observed.    

Figure  10  Scrum  board  in  JIRA

  24  

As  a  complement  to  JIRA,  there  is  Confluence  also  provided  by  Atlassian.  This  is  solution   with   a   more   traditional   approach   that   plays   the   role   of   a   wiki.   The  particular  use  we  give  to  Confluence  is  to  save  the  tables  for  the  user  acceptance  cases  related  to  each  user  story.  Due  to  its  role  of  wiki,  it  helps  us  keeping  a  trace  of  new  versions  of  user  acceptance  criteria  or  any  other   important   information  about  the  project,  for  example  the  definition  of  done  and  the  definition  of  ready.  The  mutual   use   of   JIRA   and  Confluence   has   been   key   to   our   performance   as   a  team,   pointing   out   that   the   table   of   user   acceptance   cases   is   aligned   to   the  business  requirements  and  represents  at  the  same  time  the  commitment  of  the  IT.  Furthermore,  it  acts  as  a  double-­‐edged  sword  for  the  IT  and  the  Business  and  as  a  shield  for  the  AMO.  From  one  side  it  allows  the  AMO  to  demand  from  the  IT  all   the   specifications   that  were   agreed   upon.   From   the   other   side,   it   gives   the  AMO   the   support   to   argue   with   the   Business   in   case   their   expectations   were  different   than   what   was   discussed.   It   is,   without   a   doubt,   the   AMO’s   greatest  ownership.  This  is  the  reason  why  we  spent  a  significant  amount  of  time  writing  down  table  of  user  acceptance  before  the  sprint  begins.  

 As  I  said,   the  definition  of  ready  and  the  definition  of  done  are  accessible  to  all  the   members   of   the   team   in   Confluence.   The   original   versions   are   written   in  French,  so  I  will  translate  them  hereby:      

Definition  of  Ready    

• Title  containing  keywords  (android,  iOS,  POC,  Draft)  • Detailed  description  (+  mandatory  information:  url,  password,  account)  • Business  value  defined  • Validated  mockups  

Figure  11  User  Acceptance  in  Confluence  

  25  

• Dallas  modules  delivered  in  UAT  (test  environment)  • Test  scenarios  (and  test  cases  ready)  • If  US  is  ‘not  simple’,  then  it  should  contain  User  Acceptance  tests  • Story  points  assigned  • Tagging  (analytics,  capptain,  etc…)  

   

Definition  of  Done    

• IT  development  finished  • Integration  of  all  modules  done  • Stories  deployed  (Available  on  the  last  build)  • Tests  passed  • Technical  documentation  completed  • JIRA  updated  with  build  number  of  Bamboo  • US  validated  by  AMO  

 

Scrum  Events  In   terms   of   events,   the   daily   scrum   is   held   every   morning   through  videoconference,   including   the  participation  of   the   technical   responsible   of   the  integration  layer  the  app  is  connected  to.  The  refinement  sessions  are  scheduled  once  a  week  and   they   last   for  one  hour.  During   this  meeting   there   is  always  at  least  one  person  that  represents  the  AMO,  one  person  of  the  Business  team,  one  person  for  each  platform,  Android  and  iOS,  and  the  Scrum  master.    At  the  end  of  each  sprint,  a  full-­‐day  meeting  takes  place  at  Toulouse.  In  order  to  keep  a  balance  as  for  refinement  reunions,  there  is  at  least  one  person  from  the  AMO  and  another   from   the  Business   that  will   physically  meet   the   IT   team  and  have  a  face-­‐to-­‐face  discussion.  During  the  first  half  of  the  day,  the  sprint  review  and  retrospective  are  carried  out.  In  this  part,  all  the  members  are  encouraged  to  speak   up   their   minds   about   the   positive   or   negative   situations   and   some  improvement  points  are  taken  into  account  for  the  next  sprint.  In  the  afternoon,  the  sprint  planning  takes  place.  Since  a  huge  part  of  the  work  has  been  shifted  to  the   previous   refinement   sessions,   the   user   stories   are   presented   in   their   final  state.  This  is  to  say  that  all  major  discussions  have  already  occurred  and  changes  will   rarely  happen  at   this   stage.  Afterwards,   the   selection  of   items   through   the  poker  planning  is  carried  out  and  the  scope  of  the  sprint  is  then  defined.      

Challenges  One  of  the  most  evident  challenges  is  the  distance,  since  the  AMO  and  Business  teams  are   located  at   the  headquarters  but  the  IT   is   located  at  Toulouse.  This   is  the   very   first   contradiction   to   the   agile   method   recommendations,   which  indicates  that  all  the  members  of  the  team  should  be  on  the  same  installations    –the  same  room  if  possible–  to   facilitate  communication.  The  balance  was   found  by   an   intense   use   of   communication   media   such   as   videoconferencing   and   a  telephone   number   dedicated   to   each   platform.   However,   as   face-­‐to-­‐face  communication  still  seemed  necessary,  it  was  arranged  that  every  three  weeks  at  

  26  

the  end  of  the  sprint  the  AMO  and  the  Business  teams  would  travel  to  Toulouse.  Even   though   these   measures   are   sufficient   to   break   down   the   distance,   I   am  persuaded  that  working  in  the  same  physical  space  would  significantly  enhance  performance.  Anyhow,  this   is  not  something  that   is  going  to  change  in  the  near  future  due  to  the  heavy  structural  organization  of  a  huge  enterprise  such  as  Air  France.   It   is   a   phantom   of   the   late   20th   century,   where   the   technique   was  underestimated   and   the   administrative   teams   were   congregated   at   the  headquarters;  I  will  keep  the  reflection  for  later.      On  the  other  hand,  besides  the  large  size  of  the  team,  there  is  also  the  separation  of  roles  between  the  AMO,  the  Business  and  the  IT,  where  the  scrum  suggests  a  cross   functional   team.   The   problem   lays   on   the   implicit   hierarchy   that   derives  form   the   separation   of   responsibilities,   where   a   vertical   communication   is  predominant.  The  challenge  consists  in  breaking  apart  this  traditional  structure  and  getting  all  members  of  the  team,  specially  the  Business  and  the  IT,  to  discuss  together  as  a  single  team.    Another   delicate   point   is   the   one   regarding   the   complexity   of   the   app   and   the  high  quality  standards  at  Air  France.  This  slows  down  the  development  process  as   we   often   confront   really   complex   and   particular   –   not   to   say   outdated   –  business  rules  for  each  process  that  must  be  implemented  as  well  in  the  app.    Last  but  not  least,  there  are  also  all  the  internal  and  external  dependencies  of  the  project.  Although  the  integration  layer  was  deployed  with  the  objective  of  having  a   single   access   to   the   information   system,   other   dependencies   such   as   web  services  and  API’s  may  still  have  an  impact  on  the  front  end,  not  only  in  terms  of  quality   but   also   in   terms   of   planning.   To   avoid   tight   situations   the   team   has  adopted   the   politic   of   not   including   a   new   service   until   it   has   been   tested,  approved   and   deployed   in   production.   This   can   be   justified   with   our   working  method,  where,  in  theory,  our  time-­‐to-­‐market  can  be  as  short  as  3  weeks.    

Project  Lifecycle  In  order  to  achieve  our  goals,  we  start  working  on  the  items  two  sprints  before  the  development  begins.   In   the  sprint  N-­‐2   the  Business   is   in  charge  of  defining  the  needs  with  the  corresponding  graphic  supports  (done  in  cooperation  with  an  external   contractor)   and   briefing   the   AMO   so   we   are   able   to   define   the   user  stories   and   the   user   acceptance.   In   the   sprint   N-­‐1,   during   the   refinement  sessions,   the  user   stories   are   reviewed   in  detail  with   the   IT   and   the  necessary  modifications  are  made  in  negotiation  with  the  Business.  Finally,  when  the  actual  sprint  N  takes  place,  the  items  are  developed  and  tests  are  performed  based  on  the  user  acceptance  cases  and  the  user  story  if  finally  validated.                  

  27  

 

Assignments My  contribution  to  the  project  comes  in  two  rounds.  Being  part  of  the  AMO  team,  I   collaborate  writing   the  user   stories  and   the  user  acceptance  cases  during   the  upstream   phase   of   iteration,   and   doing   the   testing   and   validation   of   the   user  stories  during  the  current  sprint.  I  will  explain  more  in  detail  these  assignments  along   with   other   minor   tasks   that   are   not   planned   on   a   regular   basis.   It   is  important  to  say  that  before  having  autonomy  on  any  of   these  tasks,   there  was  an  up  skilling  period  of  about  one  month,  during  which  I  did  not  only  get  used  to  the  agile  method,  but  also  to  the  universe  of  airlines.  I  received  capacitation  from  my   colleagues   on   how   to   use   AMADEUS,   the   central   information   system   for  booking,  pricing  and  ticketing  of   flights.  This  was  key  to  my  autonomy  because  the   application’s   main   services,   such   as   buying   a   ticket,   showing   the   flights  information,  showing   the  reservation  status,  check-­‐in,  among  others;  are  based  on  bookings.      

Definition  of  User  Stories  and  User  Acceptance  As   I  mentioned  before,   the  user   stories  and  user  acceptance  are  defined   in   the  sprint   N-­‐2.   During   this   period   the   Business  must   have   delivered   the  mockups  and   defined   their   requirements.   Once   it   is   done,   they   communicate   the   AMO  team  their  requests  with  as  many  details  as  possible,  but  there  is  also  place  for  discussion  in  case  the  feasibility  appears  to  be  compromised  and  a  negotiation  is  held   if   necessary.   At   this   moment   the   AMO   takes   over   by   transforming   the  Business   needs   into   user   stories   and   user   acceptances.   It   is   very   important   to  write   them   in   a   clear   and   exhaustive   way   as   they   will   allow   everyone   –   the  Business,  the  AMO  and  the  IT  –  to  be  on  the  same  page.    

Figure  12  Project  lifecycle  

  28  

Later  during  the  sprint  N-­‐1,  the  user  stories  are  discussed  with  the  IT  during  the  refinement  meetings.  The  objective   is   to   go   review   in  detail   each  aspect  of   the  user  story,  in  order  to  make  it  meet  the  definition  of  ready.    Through  this  process  we   ensure   that   the   development   phase   will   happen   without   any   major  difficulties  and  that  the   increment  delivered  at  the  end  of   the  sprint  will  match  the  expectancies  of  the  Business.    By  preforming  these  tasks,  I  made  use  of  my  synthesis  capability  and  at  the  same  time  I  was  able  to  improve  my  writing  skills.  On  the  other  hand,  when  defining  the   user   acceptance   cases,   in   addition   to   having   a   full   understanding   of   the  subject,   I   had   to   foresee   every   possible   scenario   but   staying   focused   on  functional  cases.    

Testing  and  validation  Afterwards,  during  the  actual  sprint  in  which  the  user  stories  were  developed,  I  contributed   to   the   testing   and   validation   of   items.   Within   the   AMO   team,   we  often  alternated  the  user  stories  so  the  person  testing  is  different  from  the  one  who  wrote  the  user  acceptance  cases.  Having  a  second  point  of  view  of  the  same  subject  is  important,  as  we  make  sure  of  avoiding  miscomprehensions  made  by  a  single  person.  As  I  mentioned  before,  the  user  acceptance  is  the  set  of  tests  that  allows  us  to  objectively  validate  or  reject  a  user  story.    As  I  said  before,  to  keep  track  of  the  sprint  progress  we  use  the  sprint  board  on  JIRA.   Then,   when   the   IT   has   finished   developing   one   item,   they   pass   it   to   the  section   ‘To  Validate’  along  with  the  corresponding  number  of  build  from  which  the   feature  will   be   available.   Once   it   is   available   for   testing,   one   person   of   the  AMO  will  self-­‐assign  the  user  story  and  start  the  corresponding  work.  The  results  from  the   tests  are   integrated   to   the  comments  of   the  user  acceptance   file.   If  all  the  tests  are  successful,  the  AMO  closes  the  user  story  by  passing  it  to  the  ‘Done’  column  of  the  board  and  it  is  not  longer  modified.  In  case  there  tests  cases  that  were  not  in  conformity  with  the  acceptance  criteria,  the  user  story  is  reopened,  meaning  that  it  is  stacked  back  in  the  ‘To  Do’  column.      This   assignment   demanded   to   be   rigorous   by   performing   exhaustive   tests   and  making   sure   there   is  nothing  missing.  Validation   is   a   great   responsibility,   even  more   considering   that   it   is,   in   a   certain  way,  our   seal  of  quality.  Additionally,   I  confronted   management   problems   when   there   were   unconformities   during  testing   and   I   had   to   discern   whether   it   corresponded   to   a   non-­‐fulfilled  commitment,  incoherencies  in  the  user  story  or  an  ambiguity  not  defined  clearly  by  the  Business.   In  the   last  case  a  negotiation  could  take  place,  but  the  balance  will  often  fall  in  favor  of  the  IT,  backed  up  by  the  AMO.    

Minor  tasks  When  a  new  release  to  production  is  scheduled,  then  a  full  non-­‐regression  test  is  performed.   All   the   features   of   the   application   must   be   tested   in   order   to  guarantee  the  quality  of  service,  making  sure  that  everything  is  still  working  fine  in  the  new  release.  The  same  happens  when  there  is  a  back-­‐end  release;  a  partial  

  29  

non-­‐regression  test  is  performed,  regarding  only  the  functionalities  that  concern  the  back-­‐end  services.    

Results All  along  my  internship  I  participated  from  sprint  30  to  sprint  38,  where  7  entire  sprints  in  total.  During  this  time  the  following  features  where  defined,  developed  and  validated:      

• Engine  Booking  Tool  search  (EBT1)  This   is   first  step  when  making  a  reservation.   It  allows   the  user   to   fill  all  the   information   needed   to   search   a   flight   through   a   user-­‐friendly  interface.   It   incorporates   departure   and   destination   airport   search,   a  calendar   to   choose   the   dates,   all   the   passenger   typologies   and   even   a  special  option  for  clients  with  subscriptions.      

• Engine  Booking  Tool  confirmation  (EBT9)  It  makes  reference  to  the  confirmation  page  at  the  end  of  the  reservation  process.   Two   functional   cases   are   possible,   a   booking  with   a   confirmed  payment  or  waiting  for  payment  within  the  next  24  hours.    

• Internet  Check-­‐In  search  (ICI1)  This  page  is  conformed  by  two  sections.  The  first  showing  the  next  flight  eligible  for  check-­‐in  and  the  second  allowing  a  manual  search.  The  middle  of  the  process  is  held  through  web  view.    

• Internet  Check-­‐In  confirmation  (ICI22):  It  is  the  final  page  of  the  check-­‐in  process  and  is  done  native.  There  are  two  functional  cases,  rather  the  boarding  passes  of  all  the  passengers  have  been  emitted  or  not.    

• Manage  My  Booking  (MMB):  This  feature  allows  the  user  to  import  his  PNR’s   in   the   application   and   offers   access   to   the   main   actions   over   a  booking   such   as   modifying   a   flight   and   check-­‐in   as   well   as   important  information   like   a   cancelled   flight.   Two   sprints   were   dedicated   to   this  functionality.    

• Recovery  password:  This   is  the  process  that  allows  the  user  to  recover  the  password  of  his  account   in   case   it  has  been  blocked  or   the  user  has  simply  forgotten.  

 • Flights  Status:  It  has  to  do  with  the  search  and  display  of  information  of  a  

flight,  including  but  no  limited  to  arrival  and  departure  time,  punctuality,  terminals,  cancellation  and  scales  deviations.    

• Dashboard  FB/MyA:  It  gives  access  to  the  users  account  (Flying  Blue  or  My  Account)  detailed  information.  It  includes  travel  documents,  payment  methods,  miles  status  and  last  transactions.      

  30  

• Accengage   integration:   Accengage   offers   Customer   Revenue  Management  solutions  for  mobile  applications.  The  integration  of  this  tool  allows  us   to  keep   track  of   clients  by   tagging   their  actions.  Therefore  we  are   able   to   do   market   segmentations   and   for   instance,   sending  commercial  notifications  only  to  potential  costumers.      

• Boarding   Pass:   The   boarding   pass   has   been   redesigned,   this   time  counting  with  a  format  for  tablets.    

 • Air   France   Press   in-­‐app   advertising:   In   order   to   promote   downloads  

and   usage   of   the   multimedia   application   Air   France   Press,   some   links  where  added  at  strategic  places.  

 • Contacts:   It   is   the   page   that   shows   the   user   all   the   possible   ways   of  

contacting  Air  France,  including  social  networks.  It  takes  into  account  the  Costumer  Service  specific  options  for  each  client.    

 • Home  Page:  The  home  page  has  been  completely  redesigned  for  the  new  

app.   It   will   offer   the   client   a   contextualized   experience   by   showing   the  right   information   at   the   right  moment.   It   concentrates   all   the   bookings  information   as   well   as   the   status   of   his   Flying   Blue   account.   The   home  page,  being  the  most  complex  and  most  important  feature  of  the  app,  has  been   developed   during   three   different   sprints.   The   following   picture  shows  a  preview  of  the  Home  Page  in  smartphone  and  tablet  formats.  

Figure  13  Home  Page  in  Smartphone  and  Tablet  formats  

  31  

 Throughout   my   time   as   intern,   three   alpha   versions   where   released.   These  versions  are   transmitted   to   internal  personal  of  Air  France   to  have  a  very   first  feedback.  They  can  also  be  used  to  showcase  the  progress  of   the  project   to   the  managers.  In  addition  to  alpha  versions,  some  real  user  tests  were  conducted  in  collaboration  with  an  external  agency,  allowing  us  to  have  a  true  feedback  from  our  future  costumers.  Although  my  internship  ends  before  the  beta  release,  I  can  say   it   is   the   combined   effort   of   all   the   sprints   containing   all   the   ‘must   have’  features   and   it   will   represent   the   so-­‐called   Minimum   Valuable   Product.   For  precautious  reasons,  this  version  will  be  kept  internal.        

  32  

Specific mission The project: POC Internet Check-In Besides  my  participation  in  the  main  branch  of  development  of  the  application,  I  also  took  charge  of  the  Proof  Of  Concept  (POC)  for  the  feature  Internet  Check-­‐In  (ICI).  The  project  was  scheduled  for  3  months,  starting  from  July  2015.    

The  Check-­‐in  API  It   is   important   to   say   that   the   check-­‐in   process   is   carried   out   by   KML   and  currently   we   pass   through   a   web   view.   Recently,   KLM’s   information   systems  direction   decided   to   transform   their   main   digital   processes   by   implementing  Application  Programing  Interfaces  (APIs)  for  internal  clients  as  well  as  external.  This  decision   is  a  huge  step   forward  as  APIs  have  become  a  standard  of  digital  services,  offering  wide  spread  use  for  different  platforms,  keeping  total  control  of  the  back-­‐end  implementation  without  compromising  the  interface  and  therefore  without  affecting  the  consumers  of  the  service.    From  the  foundation  of  the  group  Air  France  –  KLM,  a  commercial  alliance  was  created  but  a   common  structuration  never   took  place.  Later,   they   realized   that  doing  joint  projects  would  be  the  way  to  better  exploit  the  expertise  from  each  other   as   well   as   reducing   costs.   Then,   they   launched   so-­‐called   e-­‐Convergence  plan  that  pretends  to  unify  most  of  the  digital  services  of  Air  France  and  KLM.  As  part   of   this   plan,   the   implementation   of   APIs   takes   all   its   sense,   being   in   the  interest   of   both   companies.   The   ideal   is   that   the   APIs   become   the   service  provider   of   not   only  mobile   applications,   but   also   every   digital   channel   of   Air  France   or   KLM.   However,   KLM’s   API   teams   will   take   all   the   responsibility   as  providers,  while  Air  France  as  well  as  other  KML  teams  act  only  as  consumers.  This   is   just   to   make   clear   the   difference   between   collaboration   and  responsibility.      

Mobile app Front-end

Integration Layer

Back-end

DALLAS

AMADEUS CIS <…>

APIs

Check-in API

Figure  14  System  architecture  with  API  

  33  

Why  a  POC?  From   the   project   management   point   of   view,   we   must   first   understand   that  changing  from  the  web  view  to  a  native   implementation  is  not  a  priority   in  the  roadmap  of  the  main  mobile  application.  Second,  since  the  check-­‐in  API  is  still  in  development   and   it   has   no   been   validated,   we   cannot   compromise   quality  changing   to   the  API  when   there   is  already   the  web  view  process  working.   It   is  then   in   the   framework   of   the   e-­‐Convergence   and  promoting   collaboration   that  we  were  assigned  to  start  consuming  the  API  in  spite  of  its  immature  state.    When  we  do  a  POC,  we  do  it  in  a  separate  branch  of  development  and  even  with  a  different   team.   In   fact,   there   is   a   special   IT   team   dedicated   to   this   kind   of  missions.   This   structuration   allows   us   to   innovate   without   compromising  performance  on  the  main  project.  Another  important  rule  is  that  POCs  are  never  directly  integrated  in  the  main  project  and  they  can  even  be  thrown  away  if  the  results   are   not   satisfactory.   They   exist   not   only   to   prove   a   point,   but   also   to  prepare   the   field  before   taking   the  decision   to   integrate  a  new  functionality.   In  this  case,  even  though  we  know  the  switch  over  APIs  will  be  imminent,  it  lets  us  know   the   progress   rate   and   raise   the   corresponding   problems   by   positioning  ourselves  as  future  consumers  of  the  API.    

The  team  There  were   three   of   us   assigned   to   this   project,   one   developer   of   the   backend  service  DALLAS,   one  developer   in   front-­‐end  and  myself   representing   the  AMO.  There   were   also   our   respective   superiors   overseeing   the   project   and   taking  charge  of  major  impediments  that  would  need  to  be  escalated.    

Methodology approach Although   in   this   case  we  where  not  able   to   stick   follow   the  Scrum  method,  we  still  used  some  elements  of  it.  This  is  because  this  project  is  so  small  in  scope  and  time   that   all   the   structure   recommended  by   Scrum   results  not   adapted.   Scrum  events  were   totally  disregarded,   even   though  we   still   had  a  weekly  meeting   to  discuss   the   progress   rate,   highlighting   the   issues   that   were   found   and   still  unresolved.  On  the  other  hand,  sprints  did  not  make  any  sense  due  to  the  size  of  the   project.   Nonetheless,   we   preserved   the   figure   of   user   stories   and   the  formalization   through  user  acceptance  criteria.   In   terms  of   tools,  we  continued  using   JIRA   and   Confluence,   defining   each   page   as   a   user   story.   The  communication  was  entirely  held  by  phone  or  by  video  conferencing.  As  we  can  see,  the  methodological  framework  was  really  light,  allowing  us  to  rely  more  on  flexibility.    

Challenges Process  complexity  The   Internet   Check-­‐In   process   constitutes   the   end   of   the   information   chain  before  the  passenger  actually  takes  the  flight.  It  takes  place  from  30  hours  before  

  34  

the   departure   of   the   flight.   It   is   important   to   keep   it   simple,   but   as   robust   as  possible.  The  simplest  case  scenario  is  a  client  checking-­‐in  in  for  his  flight  where  he   obtains   the   boarding   pass   at   the   end   of   the   process.   However,   there   are  several  alternate  scenarios  that  must  be  taken  into  account.    In  order  to  better  understand  what  I  was  facing,  I  worked  in  close  collaboration  with   the   ICI   team   in   charge   of   the   check-­‐in  process   through   the  website.   They  provided   me   a   detailed   list   of   functional   tests   they   perform   on   the   current  implementation.   This  would   allow  me   to   get   an   overview  of   all   the   alternative  scenarios   besides   the   regular   check-­‐in.   Within   these   particular   cases   we   can  highlight:    

• Check-­‐in   redirect:   When   the   flight   is   handled   by   another   operating  company,  a  redirection  link  to  the  partner’s  website  is  shown  to  the  user.  

• Go   Show:   It   is   a   special   option   for   clients   in   high   contribution   fares   or  frequent  travelers  of  the  top  tier  level.  It  allows  the  clients  to  check-­‐in  for  a  different  flight  than  the  one  they  reserved  at  no  extra  cost.  

 • Day   Return:   If   the   client   has   a   round   trip  with  no  more   than  24  hours  

between  the  two  flights,  it  qualifies  as  a  same  day  return.  At  the  moment  of  check-­‐in,  the  return  flight  is  also  proposed,  allowing  the  client  to  check-­‐in  for  both  flights  through  a  single  process.    

 • Unaccompanied  Minor  (UM):  Children  can  only  travel  alone  if  they  have  

acquired  the  UM  service.  Therefore,  there  is  a  control  on  whether  all  the  passengers  are  children  with  the  UM  service  or  not.  This  does  not  apply  when  there  is  an  adult  traveling  in  the  group.  

 • Infant:   It  refers   to  children  between  0  and  2  years  old.  They  are  always  

attached  to  and  adult  passenger  for  the  check-­‐in  process  and  they  do  not  have  a  seat  number  assigned.  

 • Multi-­‐pax   check-­‐in:  When   travelling   in   a   group,   it   is   possible   to   select  

which  passengers  to  check-­‐in  and  the  boarding  passes  are  then  generated  only  for  those  passengers.  When  the  user  launches  again  the  process,  he  sees  all  of  the  passengers  and  the  mention  “Already  checked-­‐in”  over  the  corresponding  ones.  

 • Advance   Passenger   Information   System   (APIS):   It   is   a   regulatory  

measure  taken  by  some  countries  to  ask  for  additional   information  each  passenger.   Usually,   the   full   information   of   the   passport   is   demanded.  However,  if   it   is  a  flight  to  the  United  States  the  client  must  also  provide  his   destination   address.   This   is   demanded   only   on   international   flights  and  depends  on  each  couple  origin-­‐destination  countries.  For  instance,  it  is  not  required  for  flights  within  the  European  Union.  

 • Special   Fares:   When   a   client   has   acquired   a   ticket   at   a   special   fare,  

including   Family,   Junior   and   Senior   fares,   he   must   present   legal  

  35  

documents  to  justify  it.    The  client  is   informed  again  during  the  check-­‐in  process  by  accepting  an  additional  line  of  terms  and  conditions.  

 • Train  Leg:  When  there  is  a  booking  with  a  connection  by  train,  there  are  

special  terms  and  conditions  to  be  shown.      

• Eligible   for  Boarding  Pass:  Normally  the  check-­‐in  process  finishes  with  a  digital  version  of  the  boarding  pass  of  each  passenger.  

 • Not  eligible  for  Boarding  Pass:  When  a  passenger  has  a  special  remark  

on   his   reservation,   such   as   a   motor   incapacity   or   a   pet   in   cabin,   his  boarding  pass  cannot  be  emitted.  This  happens  as  well  for  certain  origin  airports  where  check-­‐in  is  only  available  at  the  check-­‐in  desk.  

 • Send  out  options:  The  client  might  as  well  receive  the  boarding  passes  or  

the  check-­‐in  confirmation  document  in  pdf  format  through  e-­‐mail.    In   addition   to   this,   there   are   also   the   rules   regarding   the   paid   options,   seat  change  and  additional  baggage.  However,  I  will  not  describe  them  here  because  they  were  not   in   the  scope  of   the  POC.  Nonetheless,  we  can  already  appreciate  the   complexity   of   the   process  with   the   cases   exposed   above.   In   order   to   keep  track   of   them,   I   added   the   necessary   test   cases   to   the   user   acceptance   file   for  each  of  these  scenarios.      

API  not  delivered  Another  major  impediment  was  the  immature  state  of  the  API.  Normally,  during  a  POC  we  study  the  feasibility  of  integration  of  a  proven  technology.  Nonetheless,  as   I   said   before,   this   POC   is   developed   within   the   framework   of   the   e-­‐Convergence.   Throughout   the   development   phase   we   encountered   plenty   of  issues   with   the   API.   The   very   first   impediment   was   due   to   inconsistencies  between  the  documentation  and  the  actual  implementation  of  the  API.  Acting  as  future   consumers   of   the   API,   we   stop   development   until   the   provider   solved  these  issues;  it  caused  two  weeks  of  delay  in  the  planning.      Afterwards,   when   we   entered   the   regular   development   phase,   we   noticed   the  API  misbehaved   for   specific   scenarios.   In   these   cases,  we   escalated   an   alert   to  KLM  team  and  most  of  the  times  it  was  confirmed  to  be  a  bug.  At  other  times,  it  was  no  even  delivered  by  the  API,  meaning  that  it  would  implicate  an  evolution  in  order  to  have  the  demanded  feature.    This   was   certainly,   the   greatest   challenge   throughout   the   development   of   the  POC.   It  demanded  high  rigor   in   testing   to  determine   the  origin  of   the  problem,  with   three   systems   in   development   at   the   same   time:   front-­‐end,   back-­‐end   and  the   API.   If   the   source   of   the   problem  were   the   front-­‐end   or   the   back-­‐end,   we  would   solve   internally.   However,   when   it   was   an   issue   of   the   API,   we   would  consult   it  with  KLM.  Finally,  we  needed  to  be  objective  to  restrain  the  scope  of  the  POC,  by  developing  as  much  as  we  could  and  leaving  apart  the  features  that  were  not  delivered  by  the  API.  This  strong  position   let  us  deliver  results   to  the  

  36  

managers  within  the  scheduled  time.  The  features  missing  and  other  bugs  of  the  API   were   noted   down   and  will   be   followed,   with   regards   to   having   a   trace   of  these  items  and  being  able  to  decide  when  to  integrate  it  in  the  application.      

Responsibilities Since  this  was  a  project  in  a  small  team,  I  was  given  almost  total  autonomy  on  it,  evidently,   with  my   boss   providing   guidance  when   needed.   Moreover,   I   had   to  fulfill  several  roles   for  which  I  had  to  make  proof  of  my  polyvalent  skills.   I  will  explain  them  hereby:  

As  Business  The  very  first  role  that  came  naturally  was  as  Business.  My  first  assignment  was  to   get   informed   on   the   ICI   process   and   all   the   business   rules   behind   it.   As   I  mentioned   before,   the   ICI   team   in   charge   of   the   website   enlightened   my  understanding  on  the  subject.  They  provided  me  the  list  of  functional  tests  they  perform   on   the   website,   which   I   used   as   support   to   define   the   business  requirements,   keeping   the   functional   cases   while   adapting   the   process   to   a  native  mobile  interface.      Additionally,   I   worked   on   the   mockups   for   the   process   on   smartphone.   Even  though   it  was   not   requested   to  me,   I   volunteered  with   the   conviction   that   the  User  Experience   (UX)  design  has   a  deep   impact   in   functional   cases.  One  of   the  main   changes,   as   you   will   later   see,   is   the   regrouping   of   pages,   making   the  process  much  shorter  than  the  current  one.  It  implies  showing  the  user  the  right  information   at   the   right   time.   Then   there   is   User   Interface   (UI)   design,   which  refers   to  what   the  user   sees.   In   this   case,   I   got   inspired   from   the  graphic   chart  that  is  already  in  use  in  the  main  application  and  I  reused  those  UI  elements  to  fulfill  the  functional  requirements.      

As  AMO  Two   weeks   later,   when   the   business   requirements   were   clear   and   the  corresponding  mockups  were   in  place,   I  could  take  the  position  of  AMO.  First   I  transformed  the  business  needs  into  formal  user  stories  with  the  respective  user  acceptance  cases.  Then,  when  development  started,   I  was  able   to   test   it,   follow  the  bugs  that  were  found  and  doing  the  corresponding  iterations  until  all  the  list  of  functional  tests  was  validated.      

As  Project  manager  Since   I   was   given   autonomy   during   a   great   part   of   the   project,   I   confronted  several   project   management   challenges   for   which   I   recalled   my   soft   skills.   I  conducted  the  weekly  meetings,  during  which  we  recapitulated  the  main  issues  we  were  following  and  the  progress  status  of   the  project.   I  had  as  well  a  direct  contact   with   KLM   regarding   the   bugs   and   misbehaviors   found   in   the   API,   it  demanded  the  ability  to  carry  out  multiple  subjects  at  the  same  time.  I  also  had  to  keep  a  strong  position  face  to  KLM,  in  the  sense  that  I  needed  to  be  strict  and  objective  on  whether  a  problem  was  due  to  a  wrong  implementation  in  front-­‐end  

  37  

or  misbehavior  of  the  API.  If  it  happened  to  be  the  second,  then  it  would  be  put  out  of  scope  for  the  POC  in  order  to  continue  advancing  and  therefore,  allowing  us  to  achieve  some  results.  I  must  recall  that  our  objective  was  only  to  make  an  assessment  of  the  API’s  maturity  state  in  order  to  decide  whether  to  consume  it  or  not.    Since  it  was  a  smaller  team,  I  was  in  contact  with  the  front-­‐end  and  the  back-­‐end  developers  on  a  daily  basis.  Furthermore,  we  were  able  to  establish  a  trust  and  collaboration  environment.  This   implies   that  we   favored  direct   communication  through  a  call  instead  of  an  email  when  we  faced  any  issue.  Nevertheless,  we  still  used  emails  to  keep  track  of  the  subjects,  but  always  as  a  support  and  not  as  the  main  communication  mean.            

Results User  Stories  and  User  Acceptance  cases  Although   it   is   not   often   the   case   for   a   POC,   formal   user   stories   with   user  acceptance  cases  were  written,  specifying  as  many  scenarios  as  possible  for  the  check-­‐in  process.  There  are  two  reasons  behind  this  decision.  Firstly,  because  the  aim  of   the  POC  was  to  provide  a  review  of   the  API   from  the  functional  point  of  view,   it   was   necessary   to   be   detailed   and   extensive   in   our   tests.   The   user  acceptance  constitutes  then  the  ideal  support  during  the  development  of  the  POC  as   well   as   facilitating   the   recompilation   of   results   for   the   report   document.  Secondly,  since  the   integration  of   the  API  will  come  rather  sooner   than   later,   it  will   be   of   great   help   for   the   team   to   have   the   user   acceptance   cases   already  written  and  adapted  for  the  mobile  application  functional  scenarios.  They  will  be  retaken  during  the  phase  of  formalization  into  an  integrating  part  of  the  app.    

Simplified  and  adapted  process  Since  the  project  was  carried  out  within  the  framework  of  a  POC,   its  scope  was  flexible  and  we  were  allowed  to  make  any  changes  we  considered  appropriate,  still  responding  to  the  business  requirements.  One  of  the  major  changes  was  in  the  flow  of  the  check-­‐in  process.  The  current  process  through  the  web  browser  being   too   long  was   in  contradiction   to  mobile  devices  best  practices  where   the  objective   is   to   have   process   as   light   as   possible.   In   order   to   make   a   process  adapted   to   a   mobile   application,   we   mapped   the   entire   flow   of   the   check-­‐in  process   and   regrouped   as   many   steps   as   the   process   permitted.   Two  factorizations  were  made:      

• Flights  &  Pax  page  In   the   original   flow,   there   was   a   page   to   select   the   flights   and   the  passengers,   then   optionally   a   page   to   show   special   fare   conditions   and  later  a  page  to  fill  the  basic  information  of  each  passenger.  Since  both,  the  first  and  the  third  page,  showed  information  related  to  the  passengers,  it  was   an   evident   indication   of   a   possible   factorization.   Regarding   the  

  38  

second  page,   it   appeared  only   in   certain   cases   and   served  only   to   show  special   fares   conditions   for   each   passenger.   Then,   we   analyzed   the  possibility  of  holding  these  three  steps  in  one  single  page.  Once  feasibility  was   confirmed   in   discussions   with   the   IT,   we   proceeded   to   make   the  corresponding  changes  in  the  user  stories.  

   

   

 • Confirmation  Page  

The   confirmation   page   notifies   that   user   that   his   check-­‐in   has   been  successful   and   allows   him   to   print   his   boarding   passes.   Originally,   the  confirmation   page   was   shown,   followed   by   the   print   page   allowing   the  user   to   send   his   documents   through   email   and   ending   by   a   send   out  confirmation   page.   This   extensive   flow   seemed   unnecessary   as   little  information   is   shown   in   each   page.   There   was   a   debate   regarding   the  print  page  as  it  was  of  minor  importance  given  the  fact  that  the  boarding  passes   will   be   available   in   the   application.   However,   we   decided   to  include  it  to  give  users  the  option  of  receiving  their  boarding  documents  by   email   and   therefore   being   able   to   eventually   print   them.   The   final  decision  was  to  combine  the  confirmation  and  the  print  page,  and  to  hold  the  send  out  confirmation  as  a  pop-­‐up.  

 

Figure  15  Flights  &  Passengers  page  

  39  

   Furthermore,   there  were  also  changes   in  the  user   interface   in  order  ensure  the  use   of   adequate   interface   components   for   a   mobile   device.   As   I   mentioned  earlier,  I  relied  on  the  graphic  chart  of  the  application  to  make  the  mockups,  with  regards  to  being  congruent  with  the  rest  of  the  app.      The  image  in  the  Annex  A  shows  a  comparison  of  the  original  flow  and  the  one  proposed   for   the   native   integration   of   the   check-­‐in   process.   It   is   important   to  notice   that   the   Seats   &   Baggage   page   was   not   in   the   scope   of   the   POC   and  therefore   it  was  not  developed.  However,  we  estimate   to   carry  out   this   step   in  one  page,  as  it  currently  is.      

POC  Report  The  POC  will  conclude  with  a  report  of   the  state  of   the  API  and  the  viability   to  consume  it.  Unfortunately,  we  have  not  yet  reached  that  phase  of  the  project  and  I   can   only   do   but   describe   what   the   document   will   contain   and   the   possible  course  the  project  is  going  to  take.    The  report  will  recompile  all  the  issues  found  that  had  origin  in  the  API,  using  the  user  acceptance  files  as  support.  Each  issue  will  be  described  in  detail,  specifying  whether  it  has  been  confirmed  as  a  defect  or  an  evolution.  As  of  today,  we  count  3   confirmed   defects,   3   not   delivered   functionalities   and   2   issues   pending.  

Figure  16  Confirmation  page  

  40  

Additionally,  we  have  performed  some  tests  regarding  the  response  time  via  the  current  web  process  and  via  the  API.  The  mean  time  for  the  current  service  is  4  to  5  seconds  whereas  API’s  mean  time  is  between  10  and  12  seconds,  so  2  to  3  times   slower.   This   is   already   enough   to   say   that   the   API   is   not   ready   to   be  consumed.   This   report   will   be   send   to   KLM   team   in   charge   of   the   API   and  development   will   be   frozen   on   our   side   until   a   new   release   of   the   API   that  corrects  all  the  issues  found.          

Areas of improvement Favor  upstream  work  I  was  not  assigned  from  the  beginning  of   the  project.  Therefore  when  I  arrived  the   beginning   of   the   development   phase   was   scheduled   within   three   weeks.  During   this   time   I   was   in   charge   of   defining   the   business   requirements   by  retaking  the  functional  cases  of  the  ICI  team.  I  ignored  however,  the  complexity  of   the   process,   and   given   that   I   considered   mockups   were   useful,   I   was  overloaded  by  the  third  week.  I  dedicated  only  half  of  the  time  to  this  project  but  with   time   I   noticed   that   it   required   a   deeper   implication   in   order   to   be   in  schedule.    The   work   done   during   the   first   three   weeks   conforming   the   conception   and  requirement  definition  phase  was  indeed  of  great  importance  to  the  project  as  it  set   the   basis   for   development.   Moreover,   as   it   determines   the   course   of   the  project  it  self,  it  is  essential  to  spend  as  much  time  as  needed  during  this  phase.  It  showed  up  its  results  during  the  development  phase,  where  most  of  the  subjects  were  completely  understood  and  some  of   the  questions  were  already  resolved.  However,  as  I  did  not  have  enough  time  to  think  through  every  subject,  as  soon  as  we  began  working  on  those  that  were  not  really  detailed  we  saw  our  rhythm  slowed  down.    In   brief,   this   is   just   to   prove   the   relevance   of   early   phases   in   the   rest   of   the  project.  Design  and  conception  are  as  important  or  even  more  than  development  is.   This   implies   that   from   the   definition   of   business   requirements  we   have   the  opportunity   to   improve   the   performance   of   the   team   by   taking   the   right  decisions  at  the  right  time,  as  well  as  solving  most  of  the  questions  and  clarifying  ambiguities  beforehand.    

Develop  on  validated  technology  In  spite  of  the  fact  that  the  API  was  still  in  development,  we  began  developing  the  POC  because   it  makes  part   of   the   e-­‐Convergence  plan  between  Air   France   and  KLM.   Nonetheless,   it   was   demonstrated   that   it   is   not   viable   to   develop   over  technology   that   is   still   in   development   phase.   It   brings   up   many   unexpected  impediments  and  therefore  delays   in   the  planning.  As  a  general  rule,  especially  when   working   with   third   parties   but   also   applicable   for   internal   providers,   it  would   be   recommendable   to   work   only   with   technologies   that   have   gone  

  41  

through  a  validation  phase  to  avoid  the  problems  of  being  what  we  could  call  a  ‘too  early’  adopter.      

Kanban  In  terms  of  project,  the  Kanban  methodology  would  have  fit  us  better.  This  is  as  well   an   agile   method,   but   much   less   prescriptive   than   Scrum.   For   instance,  Kanban   does   not   prescribe   the   use   of   time-­‐boxed   iterations   –sprints–   while  Scrum   does.   It   is   as  well  more   flexible   in   terms   of   organization   as   it   does   not  impose   roles   to   the   team   and   therefore   the   current   organization   can   be   kept.  Kanban  is  based  on  the  following  principles:    

• Visualize  work  A  visual  model  of  the  work  should  be  used  to  be  able  to  observe  the  flow  of  the  work.  In  this  case  we  can  use  a  dashboard,  similar  to  the  one  used  in   scrum.  The  dashboard  will   contain   all   the   steps  necessary   to   take   an  item  from  the  ‘To  Do’  columns  until  ‘Done’,  which  might  even  include  the  release   in   production   as   part   of   the   flow.   Everyone   can  work   in   one   or  more  of  the  different  phases.    

 • Limit  work  in  process  

The  Work  In  Progress  (WIP)  is  the  measure  equivalent  to  the  velocity  of  the  team.  As  it  is  specific  to  each  sub  process,  each  column  has  a  limit  on  the  number  of  items  in  progress  simultaneously.  This  is  why  usually  two  sub  columns   for  each  phase,  one   for   the  on  going  work  and  another   for  the  work  done.  The  persons  of  each  team  pass  the  items  in  the  previous  phase  to  their  own  ‘on  going’  stack.  When  the  limit  has  been  reached  and  all  the  work  has  been  done,  it  indicates  that  there’s  an  obstruction  in  the  next   phase.   In   this   way,   Kanban   helps   to   detect   bottlenecks   in   the  downstream  flow.  

 • Focus  on  flow  

By  adjusting  WIP   limits,   the  Kanban  system  can  be  optimized  to  allow  a  smooth   flow  of  work.   The   flow   acts   like   a   pipeline   because  when   items  enter  the  flow,  they  go  through  all  the  process  until  the  other  side.  Taking  a   look  at   it   and  collecting   some  metrics  will   allow  detecting  bottlenecks  easily  and  preventing  future  problems.    

• Continuously  improve  Kanban  promotes  continuous  improve,  encouraging  the  team  to  measure  the   effectiveness   and   making   an   auto   analysis   in   order   to   change   and  adjust  the  system  in  favor  of  the  team’s  performance.  

 As  we  can  see,  Kanban   is  more  adapted   to  small  projects   that  do  not  require  a  formalized   infrastructure   around.   It   also   fits   better   the   idea   of   a   POC   since   it  cannot  be  divided   in  sprints  but   it   rather  promotes  a  continuous  development.  Moreover,   in   a   POC   the   number   of   tasks   are   limited   and   known   from   the  beginning,  therefore  the  progress  rate  can  be  easily  seen  by  taking  a  look  at  the  dashboard  containing  all  the  tasks.    

  42  

Professional analysis  From  the  organizational  point  of  view  we  are  rather  a  small  team  in  comparison  with   teams   from   other   departments.   Although   the   team  was   conformed   by   15  persons,  from  whom  more  than  half  of  them  are  not  in  the  same  site,  it  felt  like  we   were   close.   This   is   in   great   part   thanks   to   the   agile   method   that   imposes  communication   on   a   daily   basis   plus   the   ceremonial   events   at   the   end   of   each  sprint.    On  the  other  hand  there  is  also  the  experience  of  the  team  that  accounts,  as  most  of  the  members  have  been  working  together  for  at  least  2  years,  which  has  allowed  establishing  a  collaboration  environment.    From  the  key  factors  of  success  I  would  highlight  the  following:  the  established  trust,  the  3-­‐week  cycle  frequency  and  the  use  of  user  acceptance  tables.  First  of  all  there  is  trust,  although  it  is  not  measurable,  it  can  be  experienced  when  you  are  integrated  in  a  team.  In  my  opinion,  even  though  the  team  is  not  completely  harmonious,  a  good  level  of  maturity  has  been  reached.  It  makes  possible  having  an  open  dialog  on  any  subject,  having  a  faster  reactivity,  judging  less  the  others,  favoring  face  to  face  communication,  relying  on  others  in  times  of  need,  amongst  other   several   benefits.   All   of   these   values,   although   intangible,   are   already  present   in   the   team   environment   and   each   member   should   embrace   them.  Furthermore,  it  allows  us  to  be  more  efficient  as  a  team  and  therefore  to  improve  our  performance.    On   the   other   hand,   the   3-­‐week   rhythm   is   above   all   a   challenge,   as   it   is   really  demanding  to  everybody.  Nevertheless,  it  is  also  a  major  asset  by  letting  us  work  at   a   constant   pace   and   consequently   sticking   closer   to   the   planning.   It   is   also  important   because   every   cycle   constitutes   a  milestone   in   the   roadmap,   where  added  value   is  driven  and  the  risk  of   the  project   is  reduced.  Finally,   it  presents  another   major   advantage   by   virtually   lowering   our   time-­‐to-­‐market   to   only   3  weeks.    Regarding  the  user  acceptance  cases,   they  have  demonstrated  to  be  the  perfect  support   during   and   after   development.   As   I   said   before,   they   allow   avoiding  misunderstandings,   keeping   everyone   on   the   same   page.   They   are   useful   to  maintain   the   balance   between   the   IT,   AMO   and   Business   teams   by   objectively  stating  what  was  the  commitment  of  the  IT  and  limiting  the  expectancies  of  the  Business.  Moreover,  since  we  are  exhaustive  when  describing  the  functional  test  scenarios,  they  constitute  in  a  certain  way  our  proof  of  quality.    Nonetheless,  there  is  always  room  for  improvement.  I  would  recommend  to  keep  working  on  human  relationships,  as  there  are  still  barriers  to  overcome  in  order  to   become   a   single   team.   As   a   second   advice,   I   would   suggest   to   give   more  importance  to  the  upstream  phase  done  by  the  business  team,  not  by  enlarging  the   scope   but   rather   by   developing  more   the   ideas   and   going   deep   into   every  subject   before   it   is   transformed   into   an   user   story.   It   would   facilitate   the  integration   to   the   project   in   the   form   of   user   stories   as   well   as   avoiding  unnecessary   reiterations.   One   ideal   solution   would   be   to   have   an   additional  

  43  

person  with  mobile  design  skills  to  complement  our  team,  contributing  to  cross  functionality.   A  more   immediate   solution  would   consist   in   gathering   the   AMO  and   the   Business   team   together   through   joint   tasks   such   as   the   definition   of  business  requirements.  This  could  be  achieved  for  instance,  by  taking  one  person  working  half  time  as  AMO  and  half  time  as  Business.  In  any  case,  having  another  person   in   the   Business   team,   would   enable   them   to   think   through   each  requirement   and   consequently   having   a   stronger   implication   in   the   project.  Furthermore,   a   better   performance   would   be   perceived   in   the   downstream  phases  and  the  overall  value  and  quality  of  the  product  would  be  increased.      To  conclude,  my  experience  as  inter  at  Air  France  was  really  rich  and  fulfilling.  It  drove  me   through   really   diverse   subjects   and   allowed  me   to   better   know   the  world   of   airlines.   Moreover,   I   was   able   to   put   into   practice   my   project  management   skills,   for  which   I   have   a   keen   interest.   It  was   also   a   privilege   to  work   in   team   that   has   appropriated   the   agile   method   as   it   let   me   better  understand  the  potential  behind  it.  On  the  other  hand,  I  confirmed  my  appetence  for   mobile   applications,   field   on   which   I   expect   to   continue   developing   my  professional  career.    

  44  

Personal analysis  Are   we   ready   to   innovate?   History   has   shown   us   that   we   live   in   a   changing  society,  changes  have  happened  for  good  or  for  bad,  but  they  have  happened.    Technology  has  always  been  a   reference   to  measure   the  progress  of  humanity,  from   the  discovery  of   fire   and   the   invention  of   the  wheel;   passing   through   the  development   of   metallurgy,   the   internal   combustion   motors   for   cars   and   the  deployment  of  electricity  networks;  followed  by  the  recent  the  boom  of  the  era  of  informatics   and   microelectronics.   However,   we   might   not   be   looking   wide  enough.    In   addition   to   technology,   there   are   social   and   economic   changes   taking   place.  Empires   and  monarchies  were   once   a   successful   social   organization,   everyone  knew  their  place  and  –  barely  –  no  one  wondered  why  things  were  the  way  they  were.  This  lasted  for  centuries  until  the  oppressed  began  to  ‘think  out  of  the  box’  and   could   not   remain   silent   any   longer.   Empires   fell,   kings   were   beheaded,  slavery   was   abolished,   women   were   recognized   the   same   rights   as   men,  nowadays  homosexual  marriage   is  being   legalized  all  around  the  world;   just   to  mention  a  handful  of  examples  of  the  greatest  social  changes  throughout  human  history.    Now,   if   we   take   a   closer   look   at   the   economic   changes,   we   can   notice   huge  fluctuations  as  well.  For  instance,  feudalism  was  the  basis  of  economy  during  the  High  Middle  Ages,  opening  the  door  for  nobles  to  participate  in  the  economy  of  the  Crown.  Afterwards,  the  industrial  revolution  came  and  capitalism  was  set  as  the  new  paradigm.  It  did  not  only  bring  ‘prosperity’,  but  also  a  new  way  of  living.  Soon,  enormous  monopolies  rose  all  over  the  industrialized  countries,  so  big  and  so  powerful  that  they  even  surpassed  governments.      Today,  experts  rumor  that  the  era  of  ‘post  capitalism’  has  begun.  They  state  that  capitalism  is  a  system  based  on  scarcity,  so  one  can  get  the  outmost  of  a  product  because  its  value  is  measured  by  its  rareness.  In  the  recent  years  industries  have  leaned   on   information   technologies   to   improve   the   performance   of   their  economic   activities.   Nowadays,   we   can   clearly   see   that   information   itself  represents   great   part   of   the   added   value   to   a   product.   However,   information  cannot   be   given   a   price   within   the   paradigms   of   capitalism,   yet   it   is   of   great  value.   Furthermore,   with   knowledge   being   more   abundant   everyday,   the  principle  of  scarcity  is  contradicted.  The  moment  we  understand  that  we  live  in  an  information-­‐based  economy,  it  becomes  clear  that  capitalism,  as  we  know  it,  will  not  continue  existing  for  long.      Currently,  there  are  thousands  of  startups  created  every  day  around  the  world,  offering  a  large  set  of  alternatives.  Some  of  them  are  so  successful  that  they  can  even  compete  with  big  companies  and  give  them  a  hard  time.  This  has  only  been  possible   with   the   popularization   of   knowledge   and   the   adoption   of   new  organizational   mindsets.   It   was   once   to   huge   enterprises   to   lead   the   way   of  

  45  

progress,   it   might   be   time   for   them   to   learn   something   from   startups   or   be  condemned   to   a   progressive   disappearance.   But   to   be   as   performing   and  innovative  as  their  smaller  counterparts,  many  social  changes  must  occur  so  they  can  be  freed  from  the  chains  of  bureaucracy.    Part   of   the   solution   might   include   performing   a   structural   flattening,   which  consists   in   removing   levels   in   the   hierarchy   of   an   enterprise.   This   measure  enables   communication   to   be  made   horizontally   rather   than   in   the   traditional  vertical  way.   It  also  increases  the  motivation  of  the  team  and  the  managers  get  more  implicated  in  all  the  processes.  Nonetheless,  there  is  still  great  challenge  in  taking  people  out  of  their  comfort  zone.        On  the  other  hand,  we  must  learn  to  value  the  technical  development.  Although  it  had  great  importance  during  the  early  20th  century  where  knowledge  was  highly  valued,  it  was  later  trivialized  with  the  spread  of  information  as  anyone  with  the  sufficient  education  could  perform  the  same   job  and  priority  was  given  to  high  command  executives.  We  passed  then  from  a  bottom-­‐up  to  a  top-­‐down  approach.  Maybe  it  is  time  to  give  technical  development  the  importance  it  deserves,  after  all   it   constitutes   the   base   of   any   product,   especially   for   digital   services.   In  my  opinion  a   ‘sides-­‐to-­‐center’  approach  will  be  the  most  convenient  for  being  truly  efficient   and   innovative.   It   means   to   stop   seeing   organization   as   a   vertical  structure   but   rather   as   a   circular   one,   where   everyone   is   as   important   as   the  other  and  only  true  added  value  can  be  found  in  combining  everyone’s  skills.  A  good  example  of  this  is  startups,  where  we  can  often  find  a  mixed  group  of  high  talented  entrepreneurs,  working  together  for  a  common  goal.      Innovation   shall   not   rely   only   on   technology;   it   should   transcend   as   well   the  social  and  economic  spheres.  Are  we  ready  to  innovate?    

 

  46  

References    Training  session:  Scrum  Foundations  (V  6.4).  2015.  Air  France  –  KLM.        Agile  Manifesto.  2001.  Consulted  on:  http://agilemanifesto.org      The   CHAOS   Manifesto.   2013.   The   Standish   Group   International,   Incorporated.    Consulted  on:  https://larlet.fr/static/david/stream/ChaosManifesto2013.pdf      Roy,   Vandana   (2014).   Scrum   Versus   Kanban.   Scrum   Alliance.   Consulted   on:  https://www.scrumalliance.org/community/articles/2014/july/scrum-­‐vs-­‐kanban#sthash.FQmtbbcL.dpuf      Peterson,  David  (2014).  Kanban  Blog.  Consulted  on:  http://kanbanblog.com      Manson,  Paul   (2015).  The  end  of  capitalism  has  begun.  The  Guardian.  Consulted  on:   http://www.theguardian.com/books/2015/jul/17/postcapitalism-­‐end-­‐of-­‐capitalism-­‐begun      

  i  

Annex A: ICI flow comparison