Mobile
AMO Intern
3
rdYear Internship Report
Enterprise
Juan Alejandro MOYA GRAJALES
3
rdYear student
Promotion 2012
School
A
cknowledgements
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.
A
bstract
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.
T
able 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
G
lossary
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.
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.
I
ntroduction
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.
E
nterprise
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
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.
“
A
gile 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
”
Arie van BennekumAlistair 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
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 Pr
odu ction Pr
odu ction Pr
odu ction
Development Development
Development Client
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.
RISK time valu e d e li ve r y value value RISK time valu e d e li ve r y
Figure 4 Waterfall vs. Agile risk over time
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.
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.
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
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
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
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.
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
G
eneral
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
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
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.
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
• 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