internship report - juan alejandro moya grajales
TRANSCRIPT
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