By Topic

Date 22-26 June 2004

Filter Results

Displaying Results 1 - 25 of 25
  • Proceedings of the Agile Development Conference. ADC 2004

    Publication Year: 2004
    Save to Project icon | Request Permissions | PDF file iconPDF (928 KB)  
    Freely Available from IEEE
  • [Title page]

    Publication Year: 2004 , Page(s): i - iv
    Save to Project icon | Request Permissions | PDF file iconPDF (78 KB)  
    Freely Available from IEEE
  • Table of contents

    Publication Year: 2004 , Page(s): v - vi
    Save to Project icon | Request Permissions | PDF file iconPDF (37 KB)  
    Freely Available from IEEE
  • Message from the Conference Chair

    Publication Year: 2004 , Page(s): vii
    Save to Project icon | Request Permissions | PDF file iconPDF (29 KB) |  | HTML iconHTML  
    Freely Available from IEEE
  • Research Program Committee

    Publication Year: 2004 , Page(s): viii
    Save to Project icon | Request Permissions | PDF file iconPDF (29 KB)  
    Freely Available from IEEE
  • Experience Reports Committee

    Publication Year: 2004 , Page(s): viii
    Save to Project icon | Request Permissions | PDF file iconPDF (29 KB)  
    Freely Available from IEEE
  • Agile methods for large organizations - building communities of practice

    Publication Year: 2004 , Page(s): 2 - 10
    Cited by:  Papers (7)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (160 KB) |  | HTML iconHTML  

    Agile development practices respect tacit knowledge, makes communication more effective, and thus fosters the knowledge creation process. However the current agile methods, like XP, are focused on practices that individual teams or projects need, and the use of the methods in organizations consisting of multiple cooperating teams is difficult. The community of practice theory suggests that large agile organizations should have various overlapping, informal cross-team communities. This paper studies three agile methods developed at Nokia that use facilitated workshops to solve multiteam issues. The paper explains using communities of practices theory - why these methods work in multiteam settings. The results of this paper suggest that workshop practices that amass people from different parts of organizations to perform a specific well-defined task can be used effectively to solve issues that span over multiple teams and to build up communities of practice. This result suggests that the community of practice concept could provide a basis for adapting agile methods for the needs of large organizations. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • An initial exploration of the relationship between pair programming and Brooks' law

    Publication Year: 2004 , Page(s): 11 - 20
    Cited by:  Papers (6)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (248 KB) |  | HTML iconHTML  

    Through his law, "adding manpower to a late software project makes it later,'' Brooks asserts that the assimilation, training, and intercommunication costs of adding new team members outweigh the associated team productivity gain in the short term. Anecdotes suggest that adding manpower to a late project yields productivity gains to the team more quickly if the team employs the pair programming technique when compared to teams where new team members work alone. We utilize a system dynamics model which demonstrates support of these observations. Parameter values for the model were obtained via a small-scale, nonprobabilistic, convenience survey. Our initial findings suggest that managers should incorporate the pair programming practice when growing their team. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Direct verbal communication as a catalyst of agile knowledge sharing

    Publication Year: 2004 , Page(s): 21 - 31
    Cited by:  Papers (4)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (512 KB) |  | HTML iconHTML  

    This paper discusses the role of conversation and social interactions as the key element of effective knowledge sharing in an agile process. It also presents the observations made during a repeated experiment on knowledge sharing conducted in various groups of professionals and students. The study suggests that the focus on the pure codified approach is the critical reason of Tayloristic team failure to effectively share knowledge among all stakeholders of a software project. Drawing on the knowledge-as-relationship perspective of knowledge sharing we theorize that verbal face-to-face interaction facilitates achieving higher velocity by software development teams. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Exploring extreme programming in context: an industrial case study

    Publication Year: 2004 , Page(s): 32 - 41
    Cited by:  Papers (14)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (224 KB) |  | HTML iconHTML  

    A longitudinal case study evaluating the effects of adopting the extreme programming (XP) methodology was performed at Sabre Airline Solutions™. The Sabre team was a characteristically agile team in that they had no need to scale or re-scope XP for their project parameters and organizational environment. The case study compares two releases of the same product. One release was completed just prior to the team's adoption of the XP methodology, and the other was completed after approximately two years of XP use. Comparisons of the new release project results to the old release project results show a 50% increase in productivity, a 65% improvement in pre-release quality, and a 35% improvement in post-release quality. These findings suggest that, over time, adopting the XP process can result in increased productivity and quality. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • The XP customer role in practice: three studies

    Publication Year: 2004 , Page(s): 42 - 54
    Cited by:  Papers (7)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (168 KB) |  | HTML iconHTML  

    The customer is the only nondeveloper role in extreme programming (XP). The customer's explicit responsibilities are to drive the project, providing project requirements (user stories) and quality control (acceptance testing): unfortunately the customer must also shoulder a number of implicit responsibilities including liaison with external project stakeholders, especially project funders, clients, and end users, while maintaining the trust of both the development team and the wider business. In this paper, we report on a series of case studies of the customer role in XP projects. We have found that customers have a pressured and stressful role, leading to issues of sustainability. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • A study case: evolution of co-location and planning strategy

    Publication Year: 2004 , Page(s): 56 - 62
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (328 KB) |  | HTML iconHTML  

    Agile practices can and should be evolved throughout a project. This paper focuses on the evolution of two agile practices, namely co-location and planning strategy, in a software development project at TransCanada. From inception to conclusion, the evolution contributes to the successful delivery of an in-house developed system and leads to change in organizational culture. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Adaptive agility

    Publication Year: 2004 , Page(s): 63 - 70
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (184 KB) |  | HTML iconHTML  

    To maximize the velocity of business value delivery Alistair Cockburn talks of having a process that is "barely sufficient". At Landmark Graphics we developed some guidelines as to what "barely sufficient" means for our various software projects. We examined over 60 projects and observed two primary attributes that influenced the type of process used: complexity and uncertainty. We provide a scoring model for plotting projects onto a four quadrant graph, which we use to categorize projects into dogs - simple projects with low uncertainty, colts - simple projects with high uncertainty, cows - complex projects with low uncertainty, or bulls - complex projects with high uncertainty. We adapt our agile process from a core set of barely sufficient practices that all projects use and add processes and practices according to a project's profile. One key benefit of this approach has been identifying project drivers and providing early guidance to project teams so that they can start with a process that is close to appropriate. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Agile methods applied to embedded firmware development

    Publication Year: 2004 , Page(s): 71 - 77
    Cited by:  Papers (8)  |  Patents (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (128 KB) |  | HTML iconHTML  

    This paper describes the experience of applying agile approaches to the development of firmware for the Intel® Itanium® processor family. Embedded development (i.e. firmware) projects are quite different from object-oriented and pure software endeavors, yet they face many of the same challenges that agile software development practices address. Several unique challenges are described, including team members' specialized domain knowledge, technical backgrounds and attitudes toward change, and the impact hardware plays in firmware design. We found agile approaches to be well-suited for our project, despite the fact that most agile methodologists come from very different backgrounds. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Aligning strategic planning with agile development: extending agile thinking to business improvement

    Publication Year: 2004 , Page(s): 78 - 82
    Cited by:  Papers (1)  |  Patents (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (95 KB) |  | HTML iconHTML  

    Many development teams have successfully used agile development to build quality software, but often these projects have failed to effectively contribute to overall company success. Our feeling is that this failure is due to the fact that most companies' strategic planning processes have not been aligned to take advantage of the flexibility and adaptability of agile development. We strongly believe in the power of agile development; however we feel that this alone is insufficient to make every software project successful. Projects must be coupled with a complimentary approach to strategy to in order to achieve the overall business goals. If agile development is to continue growing in the business community, complimentary strategic planning capabilities must be developed that share the same agile philosophies. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • AntiPractices: AntiPatterns for XP practices

    Publication Year: 2004 , Page(s): 83 - 86
    Cited by:  Papers (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (128 KB) |  | HTML iconHTML  

    When you introduce extreme programming (XP) to your project, the team gets fresh energy and high efficiency. However, sustaining the good condition becomes difficult when you are attacked by its side effects. We call these XP side effects "AntiPractices", just as AntiPatterns come from Patterns. "Turning all the knobs up to 10" is the XP way, but AntiPractices show bad symptoms of the overdrive. In this experience report, we identify AntiPractices discovered from our projects. We add prescriptions so that XPers can share the countermeasures. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Behind the rules: XP experiences

    Publication Year: 2004 , Page(s): 87 - 94
    Cited by:  Papers (2)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (120 KB) |  | HTML iconHTML  

    Agile processes such as XP (extreme programming) have been recognised for their potential benefits of improving software. During adoption of the XP process, teams can misapply the XP principles by following them verbatim, ignoring the context in which they are applied. In this paper we document our experiences where naive applications of XP principles were altered in recognition of context. We detail our observations of how teams "looked behind" the rules and began fitting XP to the problem rather than attempting to fit the problem to XP. We conclude by reflectively focusing on how this transformation occurred and suggest that it is buying into the XP ethos that drives this change of perspective on the XP process and principles. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • DecisionSpace infrastructure: agile development in a large, distributed team

    Publication Year: 2004 , Page(s): 95 - 99
    Cited by:  Papers (6)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (89 KB) |  | HTML iconHTML  

    DecisionSpace infrastructure was an effort to develop new software in a company where the corporate culture was geared to support old products. The team was large and distributed, and used an agile approach to succeed despite that. In the process, the team helped to lead the company to rediscover how to develop new software products. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Emergent database design: liberating database development with agile practices

    Publication Year: 2004 , Page(s): 100 - 105
    Cited by:  Papers (2)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (128 KB) |  | HTML iconHTML  

    Many agile projects do not apply agile practices to their database development. Common wisdom dictates that the entire data model be carefully designed up front and protected from change thereafter. We believed the common wisdom as well. But the clash of traditional database practices and agile development practices caused us significant pain, and hamstrung our ability to deliver the most business value in each iteration. Once we recognized this pain, we abandoned the conventional wisdom. Incrementally, we applied agile discipline to our database development, eventually reducing up-front design work to just-in-time work that matched our 1 to 2 week development iterations. This paper summarizes our experience. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Refactoring the development process: experiences with the incremental adoption of agile practices

    Publication Year: 2004 , Page(s): 106 - 113
    Cited by:  Papers (3)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (112 KB) |  | HTML iconHTML  

    The goal of many current process improvement efforts is to become more agile by adopting an agile process. However, the results of several recent projects suggest that when attempting to become more agile, adopting an agile process is exactly the wrong thing to do! In this experience report, the author discuss his failures with wholesale process adoption and his successes using an incremental adoption strategy based on metric- and retrospection-driven feedback. Similar to refactoring practices for design and code, this strategy identifies "process smells," and targets the worst of them with specific agile practices drawn from several popular agile processes. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Subclassing XP: breaking its rules the right way

    Publication Year: 2004 , Page(s): 114 - 119
    Cited by:  Papers (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (112 KB) |  | HTML iconHTML  

    Extreme programming encourages adoption of all of its practices. In practice many projects drop practices. What remains can be an incomplete methodology, which is dangerous. This problem can be overcome by replacing each removed dropped practice with a compensating practice tailored to the circumstances of the project - effectively subclassing XP. This experience report recounts the experiences of subclassing of XP at Wotif.com, where pair programming was replaced with "pairing" and refactoring was replaced with "team refactoring". View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Taming the embedded tiger - agile test techniques for embedded software

    Publication Year: 2004 , Page(s): 120 - 126
    Cited by:  Papers (3)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (136 KB) |  | HTML iconHTML  

    Strong unit testing is the foundation of agile software development but embedded systems present special problems. Test of embedded software is bound up with test of hardware, crossing professional and organizational boundaries. Even with evolving hardware in the picture, agile methods work well provided you use multiple test strategies. This has powerful implications for improving the quality of high-reliability systems, which commonly have embedded software at their heart. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • The slacker's guide to project tracking or spending time on more important things

    Publication Year: 2004 , Page(s): 127 - 136
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (488 KB) |  | HTML iconHTML  

    As a project manager, your time is far too important to be wasted on mundane tasks like detailed tracking of the day-to-day activities of each of your developers. Wouldn't it be nice if you spent your time negotiating project scope and identifying and removing team impediments? Our experience has shown that consistency in card sizes and estimates allows you to perform full project planning with little effort. Additionally, it results in diagrams that accurately reflect your project's status. With this, release planning sessions take hours not days, freeing up valuable time for both you and your developers. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Using competition to build a stronger team

    Publication Year: 2004 , Page(s): 137 - 141
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (136 KB) |  | HTML iconHTML  

    In 2001 we started a new project at our company. Undermanned, short on time, and under the gun to succeed, we knew that we needed a process that would help us stay on track. Unfortunately, once the project got under way, we received a lot of negative feedback from the developers. The process took away from what developers want to do: code. This paper describes how we used competition as a tool to create a more cohesive team that worked better with management and the process. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Author index

    Publication Year: 2004 , Page(s): 142
    Save to Project icon | Request Permissions | PDF file iconPDF (20 KB)  
    Freely Available from IEEE