By Topic

Date 24-28 Aug. 2009

Filter Results

Displaying Results 1 - 25 of 77
  • [Front cover]

    Page(s): C1
    Save to Project icon | Request Permissions | PDF file iconPDF (133 KB)  
    Freely Available from IEEE
  • [Title page i]

    Page(s): i
    Save to Project icon | Request Permissions | PDF file iconPDF (84 KB)  
    Freely Available from IEEE
  • [Title page iii]

    Page(s): iii
    Save to Project icon | Request Permissions | PDF file iconPDF (145 KB)  
    Freely Available from IEEE
  • [Copyright notice]

    Page(s): iv
    Save to Project icon | Request Permissions | PDF file iconPDF (130 KB)  
    Freely Available from IEEE
  • Table of contents

    Page(s): v - ix
    Save to Project icon | Request Permissions | PDF file iconPDF (163 KB)  
    Freely Available from IEEE
  • Message from the Research Stage Chairs

    Page(s): x
    Save to Project icon | Request Permissions | PDF file iconPDF (107 KB)  
    Freely Available from IEEE
  • Welcome to “Telling Our Stories” at Agile 2009

    Page(s): xi
    Save to Project icon | Request Permissions | PDF file iconPDF (89 KB)  
    Freely Available from IEEE
  • Organizing Committee

    Page(s): xii - xvi
    Save to Project icon | Request Permissions | PDF file iconPDF (115 KB)  
    Freely Available from IEEE
  • Examining the Foundations of Agile Usability with eXtreme Scenario-Based Design

    Page(s): 3 - 10
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (414 KB) |  | HTML iconHTML  

    The increasing use of agile methods to develop UI-intensive systems has led to a need to find ways of integrating usability into agile teams reconciling the convergence and divergent points between the two areas. Agile usability researchers at Virginia Tech have partnered with Meridium, Inc. to develop and implement an integrated approach known as extreme scenario based design (XSBD). Based on an analysis of core values and principles of both areas, and work from other agile usability researchers we identified four requirements that need to be met for an integrated approach to work effectively. We report on the results of using XSBD to develop a product at Meridium, summarizing how it addresses those requirements and draw conclusions about the effectiveness of the approach making connections back to core principles of agile usability. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • The Importance of Identity and Vision to User Experience Designers on Agile Projects

    Page(s): 11 - 18
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (287 KB) |  | HTML iconHTML  

    User Experience (UX) practitioners and agile practitioners need to understand how user-centred design (UCD) and its techniques can be applied in an agile context. This paper presents the results of a study concerning the role of UX practitioners on agile projects, as perceived by UX practitioners themselves. We interviewed ten UX practitioners in a variety of settings, and following a qualitative approach we identified two main themes that are perceived by UX practitioners to be highly influential in the success of integrating UCD and agile approaches. These two themes are: UX practitionerspsila understanding of their job role, and the need to establish, protect and communicate an overall team vision. Techniques for integrating the end user perspective in agile projects are also reported. These results were refined through a short observational study of one of the practitioners. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Easing Team Politics in Agile Usability: A Concept Mapping Approach

    Page(s): 19 - 25
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (272 KB) |  | HTML iconHTML  

    Team politics complicate software projects. They cause internal conflicts that can not only cost a software team time and money, but may also detract from the needs of the productpsilas end users. In this paper, we explore the use of concept maps as a means of mitigating such team conflicts. Approaching agile usability through the lens of distributed cognition, concept mapping could improve team communications. We conducted interviews with eleven practitioners from three local software development companies to gain preliminary evidence of the practicality of the approach. Participants were questioned about their challenges in agile development and about their overall impressions of a concept mapping approach. We asked about the practicality and acceptability of implementing such a methodology, along with general concerns and recommendations. Results indicate that there is a need for improvement in agile usability, and a concept mapping approach is promising for addressing existing concerns. With refinement of the method and the development of the proper tools, this approach has great potential to improve team interaction in agile usability environments. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Supporting Program Comprehension in Agile with Links to User Stories

    Page(s): 26 - 32
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (632 KB) |  | HTML iconHTML  

    Agile software development involves continuously making iterative and incremental changes to source code. When making changes, developers quickly focus on parts of code that they consider to be important, and sometimes miss other relevant parts. Therefore, tool support is needed to help developers locate conceptually related sections of code. In this paper, we present Zelda, a tool designed to work with Agile practices that captures and maintains links between high-level information and source code. We evaluated Zelda with a pilot study where subjects were required to make a change to a small web application (10 KLOCs). They were given a task description either on paper or in Zelda. We found that the Zelda Group made more accurate changes, were less likely to become disoriented, and were more willing to access additional information. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • XP Customer Practices: A Grounded Theory

    Page(s): 33 - 40
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (293 KB) |  | HTML iconHTML  

    The customer is a critical role in XP, but almost all XP practices are presented for developers by developers. While XP calls for real customer involvement, it does not explain what XP customers should do, nor how they should do it. Using grounded theory, we discovered eight customer practices used by successful XP teams: customer boot camp, customerpsilas apprentice, customer pairing, and programmerpsilas holiday support the well-being and effectiveness of customers; programmer on-site and road shows support team and organization interactions; and big picture up front and re-calibration support customers steering the whole project. By adopting these processes, XP customers and teams can work faster and more sustainably. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Extreme Product Line Engineering: Managing Variability and Traceability via Executable Specifications

    Page(s): 41 - 48
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (768 KB) |  | HTML iconHTML  

    Extreme Programming (XP) has been reported to work well by valuing principles of simplicity, lightweight practices, effective feedback and continuous process and product improvement. This paper describes an approach towards managing software product lines in a setting where XP practices are common. The paper is an action research describing a case where we handled variability in the domain of intelligent home systems to satisfy a range of requirements by our industrial partner. The paper delves into how variability and traceability of requirements can be managed via executable specifications. A case study was used to evaluate the approach, and it provided initial insights on its feasibility and usefulness. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Improving General Knowledge in Agile Software Organizations: Experiences with Job Rotation in Customer Support

    Page(s): 49 - 56
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (245 KB) |  | HTML iconHTML  

    For many organizations the transition to agile methods is problematic due to history of bureaucratization and subsequent extensive specialization of knowledge among people. Specialist knowledge inhibits self-organization and role interchangeability which are key elements of agile development. Knowing that bureaucracies are hard to counteract once established, how can development of general knowledge in software organizations be improved? Job rotation is a well-known practice often used to improve general knowledge. The reported action research evaluated job rotation among developers in customer support. The findings suggest that general knowledge is considered interesting and valuable among the participants. However, the findings also show that general knowledge acquisition can be found irrelevant and therefore counter-efficient for day-to-day work among participants if the perceived applicability to own projects is too low. Therefore, using job rotation to improve general knowledge requires careful considerations. Implications for research and practice are discussed. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • The XP Customer Team: A Grounded Theory

    Page(s): 57 - 64
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (282 KB) |  | HTML iconHTML  

    The initial definition of XP resulted in many people interpreting the on-site customer to be a single person. We have conducted extensive qualitative research studying XP teams, and one of our research questions was ldquowho is the customerrdquo? We found that, rather than a single person, a customer team always exists. In this paper we outline the different roles that were typically on the team, which range from the recognized ldquoAcceptance Testerrdquo role to the less recognized roles of ldquoPolitical Advisorrdquo and ldquoSuper-Secretaryrdquo. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Shock Therapy: A Bootstrap for Hyper-Productive Scrum

    Page(s): 69 - 73
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1211 KB) |  | HTML iconHTML  

    A properly implemented Scrum framework enforces a few simple constraints that cause a team to self-organize into a state that achieves 5 to 10 times waterfall performance. Yet the majority of Scrum teams never achieve this design goal. Teams do not know how to sequence work to deliver working software at the end of a sprint. They do not know how to work with a Product Owner to get the backlog in a ready state before bringing it into a sprint and do not know how to self-organize into a hyper-productive state during a sprint. A pattern is emerging at MySpace in California and Jayway in Sweden, for bootstrapping high performing Scrum teams. Rigorous implementation of Scrum by an experienced coach creates a total immersion experience akin to Shock Therapy. Teams are trained on exactly how to implement Scrum with no deviations for several sprints. These teams consistently achieve better than 240% improvement in velocity within a few weeks. They are then able to self-organize on their own to continue to improve performance. For many developers and managers, the experience is a wake up call to agile awareness. Unfortunately, management tends to disrupt hyper-productive teams by disabling key constraints in the Scrum framework. Team velocity then falls back into mediocrity. Velocity data is provided on five hyper-productive teams at MySpace and one team at Jayway. In all but one case, management ldquokilled the golden goose". View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Scrum 911! Using Scrum to Overhaul a Support Organization

    Page(s): 74 - 78
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (208 KB) |  | HTML iconHTML  

    The Support 2.0 team at our IT organization has recently completed Phase 1 of the Support 2.0 project. Phase 1 was a four month endeavor with a primary focus of collecting data to understand why support was so costly and identify the root cause for each support request. The team strongly believed that this initial phase would be critical to making significant impacts to the quality and supportability of applications. This experience report describes the challenge for the Support 2.0 team and shares the successful adoption of agile practices in redefining the support organization. In the spirit of the agile transition to software development one year prior, our IT organization decided to rethink the approach to application support. By embracing agile principles and utilizing agile concepts, such as a cross functional team, a team collaboration approach with frequent reviews to inspect and adapt as needed, etc, the business was able to reap immediate benefits. It was a challenging journey for the team, where the mix of onshore-offshore support engineers and an integrated client-vendor relationship within an agile team and focused framework helped to transform the support organization from an operational cost center to a value added thought partner. This resulted in a significantly improved culture and effectiveness of the support organization. This unique organization of an agile, cross-functional and team-based approach to handle support requests improved the customer experience, reduced support costs, and ultimately provided greater opportunity for the business to fund new development efforts. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Covert Agile: Development at the Speed of… Government?

    Page(s): 79 - 83
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (217 KB) |  | HTML iconHTML  

    It is the late-80psilas and the U.S. Department of Defense is rolling out a new state-of-the-art system for scheduling satellite tracking stations that uses a text-driven display and communication over serial lines. Now 15 years, three failed replacements and over 20 million tax payer dollars later a final attempt at replacing the crippled system gets underway...using Agile. This experience report will cover the challenges faced developing a critical application in iterations while satisfying the customers requirement that deliverables be made using the traditional waterfall lifecycle. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • A Peek into an Agile Infected Culture

    Page(s): 84 - 89
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (958 KB) |  | HTML iconHTML  

    What happens when your organization practices Agile software development for many years? Well, you get pretty good at Agile and you are able to apply Agile with reducing effort on challenging projects. But there is another interesting outcome which is that your people internalize Agile values, so much so that Agile becomes second-nature to everyone! In this paper we will show you how our culture is infected with Agile thinking, we will show you how we apply Agile to many ldquonon-softwarerdquo development activities like training- sessions, recruitment, staffing, office reforms, strategic decision making and more. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Enterprise Agile Transformation: The Two-Year Wall

    Page(s): 90 - 95
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (230 KB) |  | HTML iconHTML  

    As Agile is adopted by large enterprises, the number of transformation success stories has grown. But, transformation is an ongoing process, and maintaining organizational change is difficult. So, what happens after the success stories have been told? What can IT leaders expect once the Agile transformation honeymoon is over? This paper addresses these questions head-on, sharing Borlandpsilas transformation experiences and the challenges that emerged after the initial phases gave way to a new stage in our journey. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • How the FBI Learned to Catch Bad Guys One Iteration at a Time

    Page(s): 96 - 100
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (231 KB) |  | HTML iconHTML  

    Because the Federal Bureau of Investigation (FBI) never stops evolving, High Performance Technologies, Inc. (HPTi) found itself struggling to keep up with the changes while maintaining its CMMI III certification. Developers were complaining, clients were getting anxious, software releases were slipping. But what was the problem? Was it CMMI? Was it the environment? Was it HPTi? Through a disciplined approach to agile development, HPTi was able to successfully deliver above expectations. This experience report outlines HPTipsilas successful journey through a CMMI III certification on an FBI software development project and the even more successful transition into agile development. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • How Being Agile Changed Our Human Resources Policies

    Page(s): 101 - 106
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (219 KB) |  | HTML iconHTML  

    Menlo Innovations adopted agile software development practices in order to build highly effective software development teams that could produce software for Menlopsilas clients. As client needs changed during projects, it was often appropriate to change the size of the team working on the project. In order to accommodate the effective integration of new staff, and to remain productive when staffing was reduced, knowledge transfer skills became critical. Menlo found that many of the agile engineering practices, when performed well, form the basis for effective knowledge transfer. What Menlo did not expect was that the flexibility provided by being able to move resources from project to project would ultimately allow the ability to offer creative human resource policies. These policies have resulted in Menlo winning many awards, including the Alfred P Sloan Award for Workforce Flexibility. View full abstract»

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

    Page(s): 107 - 112
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (225 KB) |  | HTML iconHTML  

    Scrum provides a framework for managing agile development projects. It encourages transparency at all times, which helps reinforce the cycle of trust that must exist between development teams, management and the customer. Over the course of two years, our team had used Scrum to successfully deliver three revisions of our product with a degree of predictability that had been unattainable prior to adopting the agile method. When the projected schedule of our next project didnpsilat align with the business needs of the organization, we found ourselves on the fast-track to conflict. And we had given them all the ammunition they needed to turn our gesture of trust into a weapon of unimaginable destruction. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Agile at Yahoo! From the Trenches

    Page(s): 113 - 118
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (227 KB) |  | HTML iconHTML  

    Yahoo! is a great proving ground for Agile. Since the introduction of Agile methods and practices into the company over five years ago, many contests of the Agile process have played out across the expansive Yahoo! software development landscape. Throughout its history, the spirit of Agile has survived, often in surprising and unexpected ways. Whether being mandated from the executive-level or arising from self-motivated small teams, one theme is constant - Agile has embedded itself into the DNA of Yahoo!. And to the present day, Agile continues to emerge and re-emerge in many forms from the dedicated individuals who use the tools of Agile to create some of the most innovative user experiences on the Internet. This paper offers an informal retrospective of the relative successes and failures of enterprise Agile adoption at Yahoo! from the period 2004 to 2009. View full abstract»

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