The Challenges of Agile Methods.doc.doc


Published on

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

The Challenges of Agile Methods.doc.doc

  1. 1. Ì Résumé Cet article présente un compte rendu détaillé des moyens déployés par une entreprise de consultation pour développer un système de gestion de la connaissance pour un client à distance. Cette étude montre comment le succès a été obtenu en dépit d’un contexte difficile et en contradiction avec la plupart des préceptes de base des méthodes agiles. Les résultats démontrent que la clef de la réussite réside dans l’accord initial entre les deux parties sur les fonctionnalités de haut niveau du futur système et sur les mécanismes de coordination à mettre en place pour le déroulement du projet. Même si la relation était fondée sur la confiance mutuelle, les points d'approbation formels identifiés pour chaque Sprint ont servi à protéger les deux parties. Compte tenu des exigences d'un accord contractuel et des délais induits par la distance, le cycle du Sprint a été prolongé à deux mois et des technologies de communication performants ont été employées pour soutenir la collaboration. L'approche retenue s'est avérée être un facteur crucial de succès. Mots clés: Technologies de l’information ; Projets de développement ; Approche agile ; Adaptation ; Gestion des relations Ì Abstract Through its detailed account of how a consulting firm tailored Scrum to successfully develop a knowledge management system for a client, this study shows how success was achieved despite the project’s chal- lenging context, which was in conflict with most of the basic precepts of the agile methods. The results show that the key was to get both parties to agree on the high-level functionalities of the future system and on how the parties would work together throughout the project. While the relationship was based on mu- tual trust, the contract-identified points of approval during each Sprint served to protect both party. Given the legal requirements of a contractual agreement, the need for a reasonable approval time cycle for a global client, and the delays induced by distance, the Sprint cycle was extended to two months, and facilitating communications technologies were used throughout. The tailored approach proved to be a defining con- tributing success factor. Key Words: Information Systems; Project development; Agile Method; Tailoring; Relationship Management
  2. 2. An Agile Method, a Contractual Relationship and Distance: An Unlikely Recipe for System Development Success Carmen Bernier, Vital Roy et Line Dubé An Agile Method, a Contractual Relation- ship and Distance: An Unlikely Recipe for System Development Success L’approche agile, une entente contractuelle et l’éloignement : une liste d’ingrédients improbables pour la réussite d’un projet de développement Carmen Bernier Professeure adjointe HEC Montréal 3000, chemin de la Côte-Sainte-Catherine Montréal (Québec), Canada H3T 2A7 Vital Roy, Ph.D 1 Professeur adjoint HEC Montréal 3000, chemin de la Côte-Sainte-Catherine Montréal (Québec), Canada H3T 2A7 Line Dubé, Ph.D Professeure titulaire HEC Montréal 3000, chemin de la Côte-Sainte-Catherine Montréal (Québec), Canada H3T 2A7 1 Correspondent author
  3. 3. An Agile Method, a Contractual Relationship and Distance: An Unlikely Recipe for System Development Success Carmen Bernier, Vital Roy et Line Dubé Agile methods have been proposed as an alternative communication flow between the development team and software development strategy to overcome the the client. weaknesses of traditional software development The importance of documentation in software methods (take too long, cost too much and offer a low development and maintenance is widely debated in the level of adaptability to the client’s changing needs). literature (Theunissen et al., 2003; Lindvall et al., 2002; Agile methods are said to perform especially well when Fruhling & De Vreede, 2006; Lethbridge et al., 2003; requirements are unknown, unknowable, or changing Neill, 2003). Most agile method advocates insist that (Schwaber, 2007). The agile manifesto clearly exposes the output of the software development process is a the underlying values 2: 1) Individuals and interactions piece of working code, not documentation. The basic over processes and tools; 2) Working software over tenet is that no or little time should be spent on comprehensive documentation; 3) Client collaboration documentation that does not provide direct value to the over contract negotiation; 4) Responding to change over project’s main goal (Theunissen et al., 2003). Agilists following a plan. mainly raise two arguments to support their point: (1) These precepts raise concerns, notably concerning the nothing can replace face-to-face communication for the applicability of the methods to a wide variety of transmission of tacit knowledge (Cockburn, 2002; software development scenarios and to diversified Qumer & Henderson-Sellers, 2008); and (2) the most environments. Literature on agile methods emphasizes reliable source of information about what a system does the necessity for team members to work in an open area is the code itself, since documentation is typically never in anticipation of an increase in energy level, an updated (Turk et al., 2005). The absence of formal enhanced focus and cohesiveness, and a more sustained documentation poses the problem of how to preserve overall collaboration (Moore et al., 2007). Coordination critical knowledge through time (De Souza et al., 2005), is fluid and supported by the shared knowledge of what especially when people leave (Neill, 2003), or the the others are doing. Because of the increased potential application is developed by a consultant. Different for miscommunication and delays, face-to-face forms of documentation may be essential in a interactions have precedence over mediated distributed environment. A legal relationship may also communication (Turk et al., 2005). In Scrum, for make the exchange of some formal documentation example, a mandatory face-to-face 15-minute daily mandatory (Turk et al., 2005; Fruhling & De Vreede, meeting is organized each morning. Collocation, 2006). however, is increasingly difficult to achieve, as The absence of documentation also raises the issue of distributed software development becomes more agile method compatibility with ISO or CMM common (Ramesh et al., 2006; Carmel, 1999; Turk et certifications (Boehm, 2002; McMichael & Lombardi, al., 2005). 2007). But by definition, agile methods are highly Agile methods also advocate the same close, face-to- adaptable and should be able to comply with required face interactions between the development team and the standards (Theunissen et al., 2003), including those client. The client representative should be “committed, pertaining to the production of documentation. knowledgeable, collaborative, representative and Organizations seem to be able to integrate their agile empowered” (Boehm, 2002, p. 66). Client feedback is efforts into the requirements of their quality systems seen as crucial to success. The client representative (McMichael & Lombardi, 2007; Vriens, 2003; should be close by, and able to give input and to make Fitzgerald et al., 2006). In fact, most authors would decisions that may be needed in order for the team to agree that the “no documentation” principle can hardly continue its work (Cockburn, 2002; Turk et al., 2005). be applied. The challenge is rather to identify what is This on-going interaction provides the development “just enough” documentation, what knowledge should team with a deeper understanding of the users’ needs be codified and what may remain tacit (Nerur et al., and habits (Cockburn, 2002). 2005; Cockburn, 2002). Though this may be the ideal, in practice, it may not In agile environments, contracts are supposed to be always be possible. The client may have other important loosely, informally and continuously negotiated matters to attend to (Turk et al., 2005), or may be miles (Ramesh et al., 2006). This does not fit well with the away (Williams et al., 2007). Reasonable arrangements long-established transaction cost perspective where a need to be made to ensure that developers have constant contract is awarded on a predefined set of requirements access to client feedback. A few authors (Fruhling & De and for a fixed price. Such contracts usually carry a Vreede, 2006; Cockburn, 2002) suggest alternatives, clause stipulating that any changes to the contract will such as weekly meetings, weekly interview sessions entail significant cost increases (Turk et al., 2005). The with users, ethnographic studies of the user community, scope-related risks are typically shouldered by the surveys, friendly alpha-test groups, etc., to keep an open vendor who tries to attenuate them by factoring in a high contingency. Overall, this practice makes the project extremely expensive (Eckfeldt et al., 2005). 2
  4. 4. An Agile Method, a Contractual Relationship and Distance: An Unlikely Recipe for System Development Success Carmen Bernier, Vital Roy et Line Dubé An agile approach therefore puts pressure on how a Method tailoring implies that the right combination of contract is negotiated. While several authors discuss processes, activities, tasks, techniques, guidelines, roles, system development by consultants using agile methods bureaucratic reporting and project management be (Cockburn, 2002; Vaihansky et al., 2006), very few identified along with the process by which this examine the contractual issues of such relationships and combination will evolve over time (Qumer & how to make them work. As mentioned by Eckfeldt et Henderson-Sellers, 2008). While method tailoring is al. (2005), it is difficult to find clear guidelines to common in software development projects and can be fashion a contractual agreement that will foster a done successfully (Fitzgerald et al., 2006), selecting the productive vendor/client relationship. As an alternative, right combination of individual agile practices that will these authors propose a target-cost contract, which, preserve the benefits of agility is not easy (Qumer & given a flexible scope, includes a labor rate, and fixed Henderson-Sellers, 2008). contingency and profit margins. This encourages both parties to find the most effective and efficient solution, 3. Method and to drop or reduce unnecessary functionalities. This To develop a rich understanding of how an agile method type of contract has the advantage of eliminating the had been tailored in this specific context, we elected to win-lose situation of the traditional fixed-cost contract use a qualitative approach (case study). Since we were and to make the vendor and the client work together to interested in how the consultant had tailored its develop the best solution in the shortest time frame approach to the specific needs of the project, we chose (Eckfeldt et al., 2005). to analyze the development project from the Agile methods typically rely on short iterative cycles consultant’s point of view. where responsive development has precedence over Semi-structured face-to-face interviews were conducted detailed long-term planning. Each iteration includes: (a) with the account manager (3 interviews), the Scrum a planning phase to establish the requirements (backlog) master who also serves as a functional architect on the representing the functionalities that the team will be project (2 interviews), and the technical architect. Each developing during the iteration, to evaluate the required tape-recorded interview lasted from 60 to 90 minutes, system architecture modifications and to develop the and was subsequently transcribed. Multiple e-mails high level design. The client is free to choose any set of were also exchanged with the account manager to functionalities, as long as the development team agrees deepen our understanding of the case and to clarify that they can be developed during a normal iteration. specific elements. Confidential project documentation The client usually create stories from which use cases (the project proposal, the contract, the project planning, will be compiled; (b) a coding and test phase (sprint) for the output of the Scrum reviews, etc.) was also obtained the development of the new release functionality, with a and analyzed. Triangulation through many data sources view to providing an application that responds to the and multiple respondents lessened the presence of client’s needs. Contrary to traditional plan-driven certain biases, such as social desirability or selective methods, where clients control progress based on memory of events. Both the transcripts and the “paper,” these short cycles and the focus on working documents were then analyzed to plot the timeline of code allow the client to “see” what has been done in the the project and to discover the actual software cycle; (c) the closure phase, during which the team development practices in use. presents the new functionalities to the Product owner in To do this, we developed a matrix based upon the an event called the “sprint review“, accompanied by the Scrum practices as portrayed by Schwaber (2004) and final documentation, the pre-release staged testing, and Schwaber & Beedle (2002). Reasons for the adaptations the release itself (Schwaber, 2007). were then identified and investigated. Other issues 2. Agile Method Tailoring pertaining to the applicability of agile methods, as raised in the literature review, were systematically The perfect context for agile methods (a small, self- investigated: quality assurance, contract issues, organizing, collocated team of fewer than 20 developers practices and technology that relate specifically to closely working with one on-site client over 30-day clients that are at a distance. The researchers’ cycles) is seldom encountered. In Scrum, for example, understanding of how the method was used and adapted each individual practice (collocated development team, was finally validated with the project team members, rapid client feedback, a streamlined decision process, namely the account manager and the Scrum master and the focus on developing software) has to be present during two follow-up meetings. if a “working piece of software” is to be delivered at the end of each month. These structures notwithstanding, 4. Case Description others have shown that several benefits can be realized, With employees in all major financial centers even if some of the practices have to be modified, throughout the world, Financials 3, located on the west loosened or ignored (Fruhling & De Vreede, 2006; Berczuk, 2007). 3 Names and identifying characteristics have been changed or omitted so as to preserve the anonymity of
  5. 5. An Agile Method, a Contractual Relationship and Distance: An Unlikely Recipe for System Development Success Carmen Bernier, Vital Roy et Line Dubé coast of the United States, wanted a new strategic 4.2.The Development Approach – a Tai- system (Knowledge+) to support its agents and analysts lored Scrum in collecting, organizing, searching through, and The system would be developed over a 12-month analyzing highly unstructured financial information period. The first two months would be used to set up the from multiple sources. This project–which made use of technical environment. At Financials’ request, three an unfamiliar technology, Microsoft’s .Net–was to be months at the end of the project were reserved for the largest and most complex IT development effort additional integration tests and for providing support for ever undertaken by Financials. Financials’ management the user training sessions. The system would be hired ConsultCo, a Canadian ISO9001-certified IT developed during six overlapping two-month Sprints consulting firm, located 3,000 miles away on the (see Figure 1). Canadian East Coast, to develop the new system. The choice of the partner was somewhat easy, as Financials The first month of each Sprint served to define already had a successful ongoing working relationship requirements, thereby detailing the sought after (tier-1 outsourcing) with ConsultCo. Furthermore, functionalities. During the first week of the cycle, ConsultCo was widely recognized for its expertise in ConsultCo’s functional and technical architects met .Net and in large project management. face-to-face with the client’s team (business unit representatives, business analysts, and DBA) at the 4.1.The Contractual Agreement client’s site for three days in order to understand and Given that producing a stable set of requirements for the validate the “existing process” document prepared by Knowledge+ project appeared difficult to achieve, the client business analysts in the month preceding the ConsultCo was reluctant to tackle the project on a fixed- meeting. Between scheduled meetings, ConsultCo’s price and fixed-delivery-date basis, and to shoulder all architects would prepare high level use cases (UML the risks related to its elusive scope. ConsultCo scripts format) for the required functionalities and therefore recommended the use of an agile development evaluate the overall development effort. During the last approach, namely Scrum, which Financials readily of these face-to-face working sessions, the client team accepted. While ConsultCo would be responsible for the and ConsultCo’s architects finalized the list of development of the system, Financials IT resources functionalities to be developed during the Sprint. The would be accountable for the business requirements product owner would then sign-off on this list. Upon definition and for the user acceptance tests. A list of their return home and over the following two weeks, high level functionalities was established and used by ConsultCo’s architects and analysts completed and ConsultCo to estimate the global effort required. In documented the approved list of functionalities. They addition, the iterative approach that would be used was extended the use case first versions and developed the described in great detail (iterations, dates, roles and user interfaces while working closely with the client responsibilities, documents to be produced and business analysts, by phone and video conference, to approved, deliverables, meeting format, etc.) The cost resolve any unexpected issues/questions. During the to deliver the system was estimated as a 3,000 person- fourth week, via a collaborative environment tool day effort. (SharePoint), the complete functional documentation (use cases, user interfaces, class diagrams, data model, The Financials team involved 17 business unit and business rules) was provided to the client team for representatives, including a super user who was IT review and formal approval. At the end of the fourth knowledgeable and who acted as the official product week, typically after some minor adjustments, the owner and final arbiter for all business requirement functional documentation was approved by the product issues and priorities, three IT business analysts, and one owner and became the official Sprint backlog. database administrator (DBA). The contract stipulated that the user representatives were to be available The second 30-day period of the Sprint was used to 50-75% of the time for face-to-face working sessions code and test the approved functionalities. The software with the ConsultCo senior architects at the beginning of developers organized their work, validated their use each Sprint. The business analysts and other IT case understanding with the architects, started the resources had to dedicate at least 75% of their time to coding process and prepared the test scripts. All on- the project. The ConsultCo team included a senior going work (updated functional documentation, code, functional architect, a senior technical architect, two daily build, issues and bug management, etc.) were functional analysts, and seven software developers recorded on collaborative working tools, to which all working full-time on the project. On specific occasions, team members, consultants and clients had access. At several IT specialists complemented the original team. the beginning of each day, ConsultCo team members The senior functional architect served as the Scrum met face-to-face for a daily Scrum; no client master. representatives attended this meeting. The project manager prepared a standard weekly progress report that was sent to the project management offices of both the client and the consulting firm. the organizations involved.
  6. 6. An Agile Method, a Contractual Relationship and Distance: An Unlikely Recipe for System Development Success Carmen Bernier, Vital Roy et Line Dubé At the end of each Sprint, the development team presented the production-ready Sprint functionalities to Financials’ team through a Sprint review meeting organized through a Web application, along with an audio conference. The final use cases, system and integration test coverage, updated bug list, data model and business rules were also included in the Sprint delivery package. In the end, ConsultCo’s and Financials’ teams were able to deliver a fully operational, tested and documented application to Financials’ users. The project was such a success that the client immediately contracted ConsultCo for additional Sprints with the objective to add enhanced functionalities to the Knowledge+ system.
  7. 7. Figure 1 : The Development Approach - A Tailored Scrum 5. Discussion But the Knowledge+ project also raised concerns about At first glance, the project seemed to have all the basic how Scrum could be applied to a software development characteristics that made it a perfect candidate for an context that was not in line with its central tenets and agile method. According to Applegate et al. (2003), it assumptions. Working with a distant and global client could be best described as a low structure and high risk and under the umbrella of a fixed-price contractual project. Knowledge+ was a large, but manageable agreement required major adaptations to the method’s project. After two years of intensive efforts, and the ac- basic practices. tive intervention of outside specialists, Financials had 5.1. Working at a Distance not managed to produce a complete list of requirements for the project, let alone the design specifications of the First and foremost, the project group would be dis- future system. The company had also elected to use a persed on two distant locations: the client team on the new technology with which it was unfamiliar. Because west coast and the development team on the East Coast, of strategic constraints, the project was also planned more than 3,000 miles and three time zones away. This along a very tight 12-month schedule. Clearly, the would be at odds with the Scrum method suggestion project was not well-suited for a classic plan-driven ap- that the client be easily accessible for face-to-face meet- proach: innovation and audacity were called for. This ings with the development team for the review phase at proved to be an opportunity for ConsultCo, who had the end of each cycle. As noted by Turk et al. (2005), trained personnel in the Scrum method, to market its geographical distribution renders communications more technological and project management expertise. It was difficult because of varying work schedules and differ- also a way to share some of the scope risks associated ences in time zones, and because the participants cannot with the project’s elusive nature with their client. see each other and take advantage of the non-verbal di- mension of their interactions. However, intense commu- nication is one of the method’s basic building blocks,
  8. 8. permitting mutual adjustments, tacit knowledge trans- mission and rapid reaction time.
  9. 9. To overcome this handicap, ConsultCo had to bend the project manager provided Financials with a weekly sta- method’s rules somewhat and implement operational tus report, where progress was tracked against plan; the and technological adaptations: burn-down chart; the current issues and risk log; and the • The Sprint cycle was extended to two months so as following week’s planned activities. to permit the documentation of the functional spec- 5.2.Working with a Global Client ifications contained in the Sprint backlog (first month) and to give Financials the necessary time to Working for a large and global client also carried its examine the functional specifications and get ev- own set of challenges. The first one pertains to the iden- eryone’s comments before the final approval by the tification and legitimacy of the product owner. In the product owner. This served a dual purpose. On the Knowledge+ context, the role of product owner was ac- one hand, the client insisted on having a set of ful- tually played by a group of functional specialists from ly documented functionalities before the develop- Financials’ various business units. The members of this ment phase was launched (second month). The group would meet at the beginning of each Sprint. Their documentation was used as a discussion baseline main responsibilities involved drafting the initial re- for the client and the development teams. This was quirements, prioritizing and approving the list of use seen as a confidence building measure that granted cases resulting from the negotiation with ConsultCo’s a higher level of control to Financials on the architects, and accepting the delivered functionalities at project orientation. This written functional package the end of the Sprint cycle. This group was coordinated also gave Financials a high level of assurance as to by a super user who had final authority on the group de- what could be expected at the end of the Sprint. At cisions. Since this group was not easily reachable the same time, for legal considerations, ConsultCo throughout the development phase of a Sprint cycle, the was eager to have documented and signed-off spec- main contact points were Financials’ IT business ana- ifications that could be used as proof that the re- lysts who would answer the development team in a quired functionalities had effectively been deliv- timely fashion. The role of the product owner was there- ered, as per their ISO requirements. Ultimately, the fore distributed and somewhat redefined. written documentation proved to be an effective As described, the sheer number of stakeholders in- communication and coordination tool for both part- volved on the client’s side created a burden on the ners, reducing the need for face-to-face dialogue; project and decreased the whole process pace. Typical- • In order to deal with the three-hour differential ly, it took three days (sometimes up to five) to meet time zone lag, both teams agreed on a fixed period with the group of user representatives, and to finally get of the day where each would be available for tele- a list of approved functionalities for the Sprint. It also phone and e-mail communications; took a week at the end of the design phase to get ap- proval on the functional packages. While this process is • Because of their tier-1 outsourcing relationship, important for the client buy-in and the formal approval ConsultCo had a permanent representative based at for the legal and ISO requirements, it also contributed the client’s office on the west coast, serving as the heavily to the lengthening of the Sprint cycle and made “eyes and ears” of the development team, and pro- the approach less receptive to up-to-the-moment viding feedback and assessments; changes. While in a standard 30-day Sprint, a change • ConsultCo established a high-performance elec- request can be integrated into the following increment, tronic link between the two locations, so as to per- the same change request in the Knowledge+ project oc- mit an easy and efficient sharing of data, program curring, for example, in the middle of month 2 (when code and application demonstrations. Technology the list of functionalities had already been approved) was used to replace face-to-face Sprint reviews; would only be dealt with in the planning stage of Sprint • Each month, ConsultCo commissioned two senior 3. The change requirement would therefore be devel- architects to meet with the client’s team on the oped and implemented at the end of the fourth month, west coast and discuss the content of the next which was over 80 days. As commented by the Scrum Sprint backlog. This activity was the closest ap- master, this aspect of the method “required some seri- proximation of the Sprint meeting where the devel- ous on-going education” of the client throughout the opment team meets with the product owner and project. However, this Scrum rule (no changes after both go through the product backlog items to iden- Sprint planning meeting), while amplified by the two- tify which ones would be included in the Sprint, month cycle, probably helped ConsultCo deal with the while respecting the total time allowance. risk of constant scope redefinition which was important in the specific context of this project. In this arrangement, all issues and questions involving the client were answered promptly because of the en- 5.3.Working under a Fixed-Price Con- forced working rules and the technology used to com- tractual Agreement Umbrella municate with the client’s business analysts. The trans- Another major handicap is related to the fact that, with parency goal was also attained since the ConsultCo the Scrum approach, there appears to be limited support
  10. 10. for subcontracting (Turk et al., 2005). Under normal cir- ingly helped confirm Financials’ choice of ConsultCo as cumstances, subcontracted tasks have to be well-de- a good faith and dependable partner that could be count- fined, measureable and agreed upon by both parties. ed on to take up and support its objectives. The subcontractor assumes the responsibility for deliv- ConsultCo also appreciated Financials’ open-minded- ering a fixed level of functionalities in a predefined pe- ness and maturity in accepting to let ConsultCo’s archi- riod of time and for a set price, while the client has to tects evaluate the amount of development that could define clear and complete specifications that the devel- reasonably be taken up in each cycle. During some iter- opers can understand and act upon. Clearly, this was not ations, ConsultCo underestimated the required effort the case in the Knowledge+ project. and had to absorb the additional work as overtime; on The elected strategy to overcome this difficulty was other occasions, the development effort was less than multifaceted. First of all, the governance philosophy planned and the developers had slack time that could be had to move from an arm’s-length contractual approach dedicated to other tasks. Both partners took for granted to one based on partnership and mutual trust. It was im- that, over the total duration of the project, things would possible for Financials and ConsultCo to negotiate a ful- average out. All in all, the willingness of both parties to ly specified contract covering all aspects and imponder- embark in a partnership agreement is probably the sin- ables of the future system. The only practical solution gle most important factor that contributed to the suc- was to enter into a partnership arrangement. Partner- cessful completion of this project. ships can be described as a transactional/relational con- While the list of functionalities may serve as a baseline tinuum (Paulin et al., 1997; Dwyer et al., 1987; Mac- for contract negotiation and thus make a fixed-price neil, 1980). From the transaction costs perspective, con- contract possible, it may also reveal itself to be a curse tractual governance is concerned with understanding the during the project. In Scrum, the product owner has full specifics of setting up and implementing viable cooper- control over the product backlog. This backlog can ation relationships, and delineating the terms and condi- evolve as the product owner sees fit. The development tions (distribution of rights and duties between the part- team decides with the product owner, in accordance ners) needed to organize such relationships. Relational with the development team’s workload capacity, which governance is concerned with how independent firms elements of the product backlog will be included in the align their shared processes on a day-to-day basis next Sprint. In the fixed-price contract negotiated by Fi- through organizational mechanisms with the aim of im- nancials and ConsultCo, the list of functionalities to be plementing the bilateral exchange of information delivered by the end of the project was fixed. Based on (Goshal & Haspeslagh, 1990). The participants indeed an evaluated level of complexity, ConsultCo made a acknowledged the fact that they could not spell out, in time estimate for each deliverable functionality. Indeed, advance, the complete set of terms and conditions for each Sprint initiation ended up being a mini-contract the length of their forthcoming relationship. Rather, negotiation about the functionalities to be included, the they opted for an approach that allowed for periodic level of sophistication awarded to each and how much renegotiations of evolving requirements, added options, effort each one will require. While a “real” Scrum team and scope changes over the life of the project. They just needs to be preoccupied by the feasibility of the jointly defined how they would work in the contract. Sprint backlog, ConsultCo’s team members also had to Actions were initiated to support and nurture an atmo- keep their eyes on the overall list of functionalities to sphere of trust between the partners. First and foremost, deliver at the end of the project. Therefore, the level of both companies relied on their accumulated experience sophistication of each functionality had to be defined (working together on a first tier-1 outsourcing deal). In and agreed upon and kept under control. Such negotia- addition, in the year preceding the launch of the project, tions called for compromises and give-and-take from two senior analysts from ConsultCo (now involved as both sides. Mutual trust of course made the process pos- architects in the current project) had worked full-time sible. with the client’s team to help implement the .Net infras- All this tailoring of the basic Scrum practices begs the tructure. These analysts therefore had an intimate question of, as expressed by Lewis & Neher (2007), knowledge of Financials’ needs and work environment, “When is a duck NOT a duck?” After all the adaptations and personally knew most of its IT team members. to the original method have been accounted for, do we Another important element that raised Financials’ confi- still have an agile method? The answer may lie in the dence was the presence of a sustained and open commu- words of Cockburn (2002, p. 195): “Consider agile as nication flow between the two teams. The setting up by an attitude, not a formula.” Agile methods rightfully Financials of a stable and representative user group that question traditional and hard to change assumptions of had full authority to decide on all functional issues per- plan-driven methods. Their greatest contribution may be taining to the project clearly contributed to the prompt- in providing a set of values that can be used to stimulate ness and depth of communication between the two orga- our reflection about how we conduct software develop- nizations. The timely delivery of anticipated bug-free ment projects. functionalities at the end of each iteration also increas-
  11. 11. 6. Conclusion specifically consulting firms, with a roadmap of how A new era of software development imposes addition- to tap into the potential of agile methods and to tailor al constraints on software development methods them to their specific needs. (Carmel, 1999). Information systems are increasingly Overall, however, despite the growing popularity of complex, large, and developed by multiple parties of- the agile approach (Nerur et al., 2005), we still do not ten located around the globe. Alliances, partnerships know much about how agile methods can be adapted and organization networks further contribute to blur to address the specific needs of different project con- the frontiers and complicate the development process. texts. Consequently, rigorous empirical evidence aim- While agile methods have been successfully used in ing at a better understanding of their benefits, chal- many projects, as illustrated in the literature, we still lenges, domain of applicability and tailoring is neces- do not have an organized knowledge base to help sary (Erickson et al., 2005; Mann & Maurer, 2005; evaluate their suitability or to select the ideal prac- Turk et al., 2005). Until now, anecdotal evidence and tices for a specific context. This study contributes to experience reports by methodologist advocates are le- this objective by providing a detailed account of how gion; more rigorous work with the goal of building a a consulting firm tailored Scrum to successfully de- solid research tradition and a cumulative knowledge velop a system for a client located thousands of miles base in this important field of study can only be en- away. This analysis provides practitioners, and more couraged 7. Références Applegate, L.M., Austin, R.D., McFarlan, F.W. (2003). Fitzgerald, B., Hartnett, G., Conboy, K. (2006). “Cus- “Portfolio Approach to IT Projects”, in L.M. tomizing agile methods to software practices Applegate et al. (Eds.), Corporate Informa- at Intel Shannon”, European Journal of In- tion Strategy and Management: Text and formation Systems, 15, 200-213. Cases (chap. 10; pp.579-599). McGraw-Hill. Fruhling, A., De Vreede, G.-J. (2006). “Field experi- Berczuk, S. (2007). “Back to basics: The role of agile ences with eXtreme programming : Develop- principles in success with a distributed Scrum ing an emergency response system”, Journal team”, AGILE 2007, IEEE Computer Society. of Management Information Systems, 22(4), Boehm, B. (2002). “Get ready for agile methods, with 39-68. care”, Computer, January, 64-69. Goshal, S., Haspeslagh, P. (1990). “The Acquisition Carmel, E. (1999). Global Software Teams. Prentice- and Integration of Zanussi by Electrotux: A Hall. case study”, European Journal of Manage- ment, 8(4), 414-433. Cockburn, A. (2002). Agile Software Development. Addison-Wesley Lethbridge, T.C., Singer, J., Forward, A. (2003). “How software engineers use documentation: The De Souza, S.C.B., Anquetil, N., de Oliveira, K.M. state of the practice”, IEEE Software, 20(6), (2005). “A study of the documentation essen- 35-39. tial to software maintenance”, SIGDOC ’05, Coventry, UK. Lewis, J., Neher, K. (2007). “Over the waterfall in a barrel – MSIT adventures in Scrum”, Agile Dwyer, F.R., Schurr, P.H., Oh, S. (1987). “Developing 2007, IEEE Computer Society. Buyer-Seller Relationships”, Journal of Mar- keting, 51(2), 11-27. Lindvall, M., Basili, V., Boehm, B., Costa, P., Dangle, K., Shull, F., Tesoriero, R., Williams, L., Eckfeldt, B., Madden, R., Horowitz, J. (2005). “Selling Zelkowitz, M. (2002). “Empirical findings in agile: Target-cost contracts”, Proceedings of agile methods”, in D. Wells, & L. Williams the Agile development Conference (ADC ’05). (Eds.), XP/Agile Universe 2002 (pp.197-207). Eisenhardt, K.M. (1989). “Building Theories from Macneil, I.R. (1980). “Relational Contract Theory: Case Study Research”, Academy of Challenges and Queries”, Journal of Eco- Management Review, 14(4), 532-550. nomic Issues, 14(4), 909-923. Erickson, J., Lyytinen, K., Siau, K. (2005). “Agile Mann, C., Maurer, F. (2005). “A case study on the im- modeling, agile software development, and pact of Scrum on overtime and customer sat- extreme programming: The state of research”, isfaction”, Proceedings of the Agile Develop- Journal of Database Management, 16(4), ment Conference, IEEE Computer Society. 88-100.
  12. 12. McMichael, B., Lombardi, M. (2007). “ISO 9001 and Schwaber, K. (2007). Scrum Development Process. Agile Development”, IEEE Agile 2007 Con- Available at: ference. resources/227, last accessed on Feb. 24 th, Moore, R., Reff, K., Graham, J., Hackerson, B. (2007). 2009. “Scrum at a fortune 500 manufacturing com- Schwaber, K., Beedle, M. (2002). Agile Software De- pany”, IEEE Agile 2007 Conference. velopment with SCRUM. Prentice-Hall. Neill, C.J. (2003). “The extreme programming band- Theunissen, W.H.M., Kourie, D.G., Watson, B.W. wagon: revolution or just revolting?” IT Pro, (2003). “Standards and agile software devel- Sept/Oct, 64-67. opment”, Proceedings of SAICSIT, 1-11. Nerur, S., Mahapatra, R., Mangalara, G. (2005). “Chal- Turk, D., France, R., Rumpe, B. (2005). “Assumptions lenges of migrating to agile methodologies”, underlying agile software-development pro- Communications of the ACM, 48(5), 73-78. cess”, Journal of Database Management, Paulin, M., Perrien J., Ferguson, R. (1997). “Relational 16(4), 62-87. Contract Norms and the Effectiveness of Vaihansky, P., Sutherland, J., Victorow, A. (2006). Commercial Banking Relationships”, Inter- “Hyperproductivity in Large projects through national Journal of Service Industry Man- distributed Scrum”, The Agile Journal, Dec. agement, 8(5), 435-452. 8 2006, available at: http://www.agilejournal. Qumer, A., Henderson-Sellers, B. (2008). “An evalua- com/articles/columns/articles/190-hyperpro- tion of the degree of agility in six agile meth- ductivity-in-large-projects-though-distribut- ods and its applicability for method engineer- ed-scrum, last accessed on Feb., 24th, 2009. ing”, Information and Software Technology, Vriens, C. (2003). “Certifying for CMM level 2 and 50, 280-295. ISO9001 with XP@Scrum”, Proceedings of Ramesh, B., Cao, L., Mohan, K., Xu, P. (2006). “Can the agile development conference (ADC ’03). distributed software development be agile?” Williams, M., Bellubbi, R., Packlick, J., Coburn, S. Communications of the ACM, 49(10), 41-57. (2007). “How we made onsite customer work Schwaber, K. (2004). Agile Project Management with – An extreme success story”, IEEE Agile Scrum. Microsoft Press. 2007 Conference.