The Challenges of Agile

Click here to load reader

  • date post

    12-Jan-2015
  • Category

    Technology

  • view

    776
  • download

    3

Embed Size (px)

description

 

Transcript of The Challenges of Agile

  • 1. Rsum Cet article prsente un compte rendu dtaill des moyens dploys par une entreprise de consultation pour dvelopper un systme de gestion de la connaissance pour un client distance. Cette tude montre comment le succs a t obtenu en dpit dun contexte difficile et en contradiction avec la plupart des prceptes de base des mthodes agiles. Les rsultats dmontrent que la clef de la russite rside dans laccord initial entre les deux parties sur les fonctionnalits de haut niveau du futur systme et sur les mcanismes de coordination mettre en place pour le droulement du projet. Mme si la relation tait fonde sur la confiance mutuelle, les points d'approbation formels identifis pour chaque Sprint ont servi protger les deux parties. Compte tenu des exigences d'un accord contractuel et des dlais induits par la distance, le cycle du Sprint a t prolong deux mois et des technologies de communication performants ont t employes pour soutenir la collaboration. L'approche retenue s'est avre tre un facteur crucial de succs. Mots cls: Technologies de linformation ; Projets de dveloppement ; 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 projects 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. An Agile Method, a Contractual Relationship and Distance: An Unlikely Recipe for System Development SuccessCarmen Bernier, Vital Roy et Line Dub An Agile Method, a Contractual Relation- ship and Distance: An Unlikely Recipe for System Development SuccessLapproche agile, une entente contractuelle et lloignement : une liste dingrdients improbables pour la russite dun projet de dveloppementCarmen Bernier Professeure adjointe HEC Montral 3000, chemin de la Cte-Sainte-Catherine Montral (Qubec), Canada H3T 2A7 Carmen.Bernier@hec.caVital Roy, Ph.D 1Professeur adjoint HEC Montral 3000, chemin de la Cte-Sainte-Catherine Montral (Qubec), Canada H3T 2A7 Vital.Roy@hec.caLine Dub, Ph.D Professeure titulaire HEC Montral 3000, chemin de la Cte-Sainte-Catherine Montral (Qubec), Canada H3T 2A7 Line.Dube@hec.ca 1 Correspondent author 3. An Agile Method, a Contractual Relationship and Distance: An Unlikely Recipe for System Development SuccessCarmen Bernier, Vital Roy et Line Dub Agile methods have been proposed as an alternativecommunication flow between the development team and software development strategy to overcome the the client. weaknesses of traditional software developmentThe 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 clients changing needs).literature (Theunissen et al., 2003; Lindvall et al., 2002; Agile methods are said to perform especially well whenFruhling & 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 interactionspiece of working code, not documentation. The basic over processes and tools; 2) Working software overtenet is that no or little time should be spent on comprehensive documentation; 3) Client collaborationdocumentation that does not provide direct value to the over contract negotiation; 4) Responding to change over projects 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 emphasizesreliable source of information about what a system does the necessity for team members to work in an open areais the code itself, since documentation is typically never in anticipation of an increase in energy level, anupdated (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). Coordinationcritical knowledge through time (De Souza et al., 2005), is fluid and supported by the shared knowledge of whatespecially when people leave (Neill, 2003), or the the others are doing. Because of the increased potentialapplication is developed by a consultant. Different for miscommunication and delays, face-to-face forms of documentation may be essential in a interactionshaveprecedence overmediated distributed environment. A legal relationship may also communication (Turk et al., 2005). In Scrum, formake 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 etcertifications (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 thestandards (Theunissen et al., 2003), including those client. The client representative should be committed, pertaining to the production of documentation. knowledgeable, collaborative, representative andOrganizations 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 makeFitzgerald 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 developmentjust enough documentation, what knowledge should team with a deeper understanding of the users needsbe 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 sessionsentail 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 openvendor who tries to attenuate them by factoring in a high contingency. Overall, this practice makes the project extremely expensive (Eckfeldt et al., 2005). 2 http://agilemanifesto.org/ 4. An Agile Method, a Contractual Relationship and Distance: An Unlikely Recipe for System Development SuccessCarmen Bernier, Vital Roy et Line Dub An agile approach therefore puts pressure on how aMethod 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 fewidentified along with the process by which this examine the contractual issues of such relationships andcombination will evolve over time (Qumer & how to make them work. As mentioned by Eckfeldt etHenderson-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 adone 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 t