S OBRE LOS INTERMEDIARIOS POLÍTICOS Y LAS POLÍTICAS AGRÍCOLAS

Sabre Holdings’ experience with waterfall was no different than most of the industry. Requirements were often unclear, sometimes contradictory and always changing. Some systems were extremely complex, and gathering all the requirements at the beginning of the project was more difficult than designing and implementing the corresponding system. Increasing the rigidness of the process proved not to be the answer – it slowed software construction and created order-taking behaviors.

The Product Development organization looked from 2001 for an agile methodology that could be implemented with little controversy and a high level of adoption.

We liked the values promoted by the Agile Alliance in its Manifesto for Agile Software Development, summarizing what takes precedence in an agile methodology:

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

We wanted to change the organization in the spirit of Lean Software Development. However, we didn’t find a good fit within the agile methodologies existing at the time. Most were declared to support small teams, up to 10 people. Some of our teams were much bigger due to complexity of our business. Most methodologies had no success track record for distributed development – while our projects required expertise located in multiple sites, from 2 to 4 in each case, on at least 2 or 3 continents. Many methodologies targeted just the software construction activity – rather than the whole lifecycle. We needed something to replace Waterfall at its full scope and we tasked Valtech with defining a methodology that would help us.

The closest to these requirements was the Rational Unified Process, however it was not lightweight (or “lean”) enough. A number of practices from more agile methodologies like Scrum were combined with the RUP’s framework and the resulting mix was named Agile UP, or AUP for short.

It’s important to realize that AUP had to plug into the existing system of waterfall- specific PM processes. Most changes are therefore seen on the lower levels such as development teams, and less – on the levels of aggregated project management. The descriptions below discuss the ideal target shape of AUP, the real-life accounts are given in the following section.

2.1. Actors

The attempt to define special roles within AUP teams, such as iteration tracker, weren’t very successful. All other roles had their waterfall-process counterparts and regardless of the name (e.g. Business Analyst vs. Consumer Advocate) performed the same functions. The key thing was that the way to do it had now changed.

2.2. Timeline

Development in AUP is iterative and each phase consists of one or more iterations, usually 2 or 4 weeks in duration. The development is organized in phases, similar to the 4 UP phases, each with specific objectives:

Phase Objective Ends when

Inception To verify that the project is worth doing and to reach agreement among all stakeholders on the objectives of the project

A good idea of the functionality has been reached and preliminary budget has been estimated and assigned

Elaboration Reduce project risk and to stabilize the requirements and architecture.

Development effort and operating costs can be estimated

Construction To incrementally develop a complete product through all construction phase iterations.

Stakeholders decide that the functionality is sufficient for the customer

Transition To deliver the product to the user community.

Customer is running the last release in production

The length of phases and their proportions depend on the project characteristics and the team’s ability to achieve the objectives of the phase. For example, the length of Elaboration will be longer for more complex projects, where a new architecture is required and therefore a final estimate is more difficult to give.

2.3. Planning

Work items are based on use cases (user-perspective functionality), engineering cases (non-functional technical requirements, such as operability, security etc.) and risk mitigation (action points from risk analysis). The items are identified, estimated and added to the backlog of deliverables. They are changed, added and removed during the project as new information comes.

Every deliverable is named in terms of demonstration, implying acceptance criteria (e.g. “demonstrate that category 4 validation is performed on one-way one segment M. Bukowy et al. / Agile Software Development at Sabre Holdings 29

itineraries” rather than “category 4”). The description has to be unambiguous enough for the work to be estimated before the iteration, it also makes it testable. A deliverable can only be accepted if the effort estimate for it fits within an iteration, otherwise it has to be broken down into smaller pieces.

Backlog is worked in value order, based on risk mitigation and business value. All the high risk items are to be resolved during elaboration. The construction is about “doing the obvious” and is prioritized according to business value – in order to maximize customer value for the software released periodically during construction. Dependencies are resolved dynamically when choosing the next achievable deliverable.

Every iteration ends with a demonstration of compliance of work items with the acceptance criteria. Like in other iterative methodologies, items that haven’t been fully completed in one iteration are not to be counted and have to slip to the next one.

The analysis, design, coding and testing activities are performed for every deliverable separately. The analysis step is to be done as late as reasonable. More complex analysis has to start sooner and be completed just before the iteration in which the deliverable is to be worked by the development team. The testing can begin right then – at least in the sense of defining the test cases. The design of the deliverable, coding of the tests and actual programming of the application code make up the scope of the deliverable work.

2.4. Tracking

Day to day progress is tracked using stand-up meetings, where team members report their progress, obstacles, plans and lessons learned. This is a big enabler for an effec- tive exchange of information – it is estimated that every participant should get a maximum of 2 minutes. The issues raised can be followed up on after the meeting.

The overall project progress is tracked as part of the iteration planning for the next iteration(s). This allows feeding back the budget and time estimates for the whole project (including the undone part) to the customer, effectively allowing the customer to react early and change direction so that the project brings the expected value.

A number of variables are tracked and combined to provide a project level burndown information. The tracking points are only those at the end of every iteration; unlike Scrum, AUP does not track “sprint burndown” – during the iteration – for the fact that the effort required hasn’t been found justifiable by the additional information it would bring.

2.5. Feedback

Getting early and regular feedback is the foundation of the methodology. At the end of every iteration, information is captured and analyzed, allowing re-planning the remaining part of the project.

Every iteration ends with a demonstration which only occasionally would involve a customer. Very often, a customer representative, or “proxy” would be present instead. This would be the consumer advocate / definer, usually affiliated with the marketing department. One of the reasons for this choice over a direct customer consultation is the fact that many products are constructed to serve a few customers. Rather than having different customers with slightly different ideas for the same product, who perhaps at times shouldn’t even know about each other, in the same room, marketing would

communicate with them “asynchronously” and align the requirements to be acceptable by all prior to involving the developers.

Another type of demonstration is the one involving the real customer. This typically happens much less frequently, only a few times during development, the last of which is at the official customer acceptance phase.

Feedback is not limited to the product. The whole team meets and discusses practices and how the way they work should be changed for the next iterations. This results in so-called plus/delta notes (plus=what we want to do more of, delta=what we want to do differently).

2.6. Ceremony

Many waterfall documents went away. Some of the formerly required document-based milestones could still be used in agile projects, subject to a subtle redefinition of their role in the process.

10 types of artifacts are defined for AUP: Vision, Business Case, Use-Case Model, Supplementary Specification, Risk Assessment, Backlog, Estimate, Master Test Plan, Phase Plan, Software Architecture Document. The Software Architecture Document is very important, as it must be created for every project and analyzed by the Sabre Architecture Review Board prior to approving a project, regardless of the methodology used. The SARB oversees all projects and formally enforces technical alignment of all projects, in the areas ranging from the high level flow and architecture to technologies used. As we will see, many of the artifacts refer to or are based on SARB documen- tation.

As a matter of principle, in order to avoid creating unnecessary documentation, the direction in requesting documentation is shifted from the “push” model – one where it is mandated by the process and created with little motivation, to a “pull” model – one where anyone needing information looks for the source of information and drives putting it in a form suitable (or rather – sufficient) for their purposes. This requires maturity and self-management of the teams.

2.7. Engineering

There are really only a few guidelines that are defined here. All of them are known from other agile methodologies.

 Code should be kept in a source code repository; checked out only briefly, worked, checked in, and frequently re-built with other recent work.

 Every project must have a Continuous Integration site. The CI site should be able to perform automatic builds and tests upon every check-in of code into source control.

 Automated unit tests must be built while (or before) coding the covered fun- ctionality.

 A regression suite has to be maintained to ensure that changes to the code base aren’t damaging the functionality coded earlier.

 Orientation manual should be prepared for new team members to allow them to quickly configure the environment and understand the basics of the project.

 Code reviews are to be individually agreed between developers and performed prior to demonstration.

 Code refactoring is encouraged but cannot be mandated.

3. Adoption

The adoption was driven by a small “Catalyst” group consisting of 2 subgroups:

x Project management – 3 Sabre project managers and 2 Valtech consultants,

focused on coaching the project management community to better understand the principles of agile practices and prepare for the transition. They selected the projects and teams for each AUP project, explained the methodology and helped kick-start the backlog. 3 out of 4 authors of this article served on this team.

x Engineering – 1 Sabre developer and 1 Valtech consultant. This subgroup

provided coaching and propagated the engineering-specific practices among developers during the first 2-3 iterations of every project. Involvement in no more than two projects at a time.

Since the largest team and variety of actors were located in the company’s headquarters, the Catalysts operated mainly there. Other sites, featuring mostly developers, followed with the level of adoption of practices determined by their eagerness to match or exceed the example set by developers at the headquarters.

Some of the projects involved were already running and their environments had to be redesigned for AUP. The results of implementing AUP over an existing code base depended largely on the clarity and modularity of the code, as the amount of time that could be spent on re-architecting the environment was usually low.

The degree of practice adoption varied greatly between all participating actors. 3.1. Customers and Analysts

The first projects to adopt AUP were internal. Thus, all risks associated with introducing the new culture were covered by the company. Lessons learned by the early adopters helped mature AUP before applying it to external projects.

The key to enabling introduction of an agile methodology at Sabre for external projects were the customer relationships. Well known in the travel industry, with its relationships with airline or agency customers dating back decades, Sabre was in a position to convince a few customers to run some projects in an agile way, especially if these projects represented a fraction of the development done for the customers.

Most of the external contracts, while roughly declaring the time and budget for the projects, were mainly constructed on a Time and Material basis. This, combined with the ability of specifying the details later, provided the flexibility that AUP needed while ensuring the control that the customers wanted to keep.

The customers had to switch their mentality and learn how to play their part of the methodology effectively. The learning would last anywhere from one to three or more projects depending on a customer. At first, the risk would be taken internally by developing seemingly waterfall-style, fixed scope projects with a vague definition at

the start. In that mode of operation, the customers would be regularly asked during development to increase the level of detail of requirements by using examples, use cases etc.

The customers would also be invited to review the deliverables and provide feedback. Getting them to regularly participate was a challenge at first. However, they quickly realized how beneficial this was to the projects and learned the value of feedback. Thanks to that, quite a few significant miscommunications of requirements could be detected early in the process, saving everyone’s time.

The next step was to encourage the customers to abstract all requirements and specify them in terms of the deliverable definition. In the best cases, we were able to define a backlog sufficient for starting work within 3-5 days of intensive sessions.

Thanks to the simplicity of specification of the requirements by test cases, it was sometimes possible to take it to the extreme of test-driven development by having business analysts specify functionality via XML files with request-response pairs. 3.2. Management

Tied back to the “safe”, because well-known, haven of waterfall methodology, many managers and project managers struggled with the notion of self-managed teams. Elaborate and detailed iteration plans covering the whole project were often built before the first line of code was written, and then sequentially “executed”.

A distinction must be made here between two project roles that might be specific to Sabre. A delivery manager is a relatively technical role with which the responsibility for the delivery of a project resides. S/he ensures that the team can produce their deliverables. A project manager is responsible for project tracking and administration.

Delivery managers, focused on the shape of the product being implemented, very quickly appreciated the early feedback provided by the new methodology and used the information to drive the projects more optimally from the technical standpoint.

There were more challenges with project managers’ tracking. They often complained that AUP did not give them and the executives as many metrics allowing insight in the progress of the projects as waterfall did. Certainly, the set of metrics was small, different and no “automatic” translation could be performed. Some of the met- rics weren’t integrated in the same project tracking tools, a gap which could be bridged only by those with good understanding of principles of AUP.

It was particularly hard to alter the project management practices that were enforced by previous project management standards. For example, in AUP, partially completed deliverables are considered 0% done, which is in clear conflict with the PMI standards for project tracking. Agile methodologies have not been around long enough to gather an equal amount of respect and therefore such conflicts would, by default, invoke PMI behaviors until eradicated by systematic mentoring.

Focused on fulfilling the indicators of “agility”, many PMs would promote “catching up” on unit test coverage by requesting the developers to add unit tests long after the corresponding functionality or, worse, complete program modules were coded. While not completely pointless, as improving the code’s future maintainability, this wasn’t nearly as beneficial as it could have been.

A number of approaches were tried for estimating the effort of the deliverables. All revolved around some forms of a planning poker, where developers would repeat their estimates on every item until they all agreed. A few options were tried, resulting in M. Bukowy et al. / Agile Software Development at Sabre Holdings 33

a similar inaccuracy. The fastest results were obtained by reducing the effort to the minimum and deciding whether an item will fit in an iteration.

In some teams, estimates would be decided at the technical lead level, resulting in a similar inaccuracy but much greater level of frustration of the team.

3.3. Development Teams

The level of acceptance varied greatly for the many practices that the developers were supposed to adopt. Very few projects implemented all of them in the ideal shape known from literature.

Stand-up meetings – there were two difficulties with introducing stand-up meetings. First, developers had a hard time admitting failures/obstacles. They were gradually becoming more open as the teams worked together longer and saw that hiding a problem was worse than admitting it. Some teams have grasped the idea faster than others, realizing that early problem identification enables quick progress.

Secondly, it was very challenging to keep the meetings short. Used to longer, usually less frequent, design/analysis meetings, teams would tend to take 30-45-60 minutes, turning a quick report meeting into a collective issue resolution. Taking issues “offline” was a challenge particularly for distributed teams, where the overhead of organizing another meeting was greater, so the issues had to be narrowed down during the main meeting enough to determine at least who should be contacted for resolution of the problem outside of the meeting.

For large teams, working on a variety of areas within the project, it became possible to order the speakers by area and have them join for their part only, while a handful of people supervising the progress would take part in the whole meeting.

Code reviews – as those were not explicitly required, very small number of developers have actually requested their peers to review their code.

Continuous integration – the level of adoption was mainly related to the com- plexity of the software environment. Some projects with giant build times had the builds done as infrequently as once a day, others had their builds trigger automatically upon every check-in of new code under source control.

Unit testing – a wide diversity was observed here, too. In case of most projects that were requested to “go agile” months or years after they started, the developers felt that the code they worked with was not modular enough to allow unit testing.

The results were much better for projects done in AUP from scratch. Developers learned to design their code in a way enabling “plugging in” regression tests on