By Topic

Date 5-9 Aug. 2013

Filter Results

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

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

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

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

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

    Page(s): v - vii
    Save to Project icon | Request Permissions | PDF file iconPDF (131 KB)  
    Freely Available from IEEE
  • Message from Conference Chair

    Page(s): viii
    Save to Project icon | Request Permissions | PDF file iconPDF (313 KB)  
    Freely Available from IEEE
  • Message from Research Reports Track Chair

    Page(s): ix
    Save to Project icon | Request Permissions | PDF file iconPDF (198 KB)  
    Freely Available from IEEE
  • Message from Experience Reports Track Chairs

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

    Page(s): xi - xii
    Save to Project icon | Request Permissions | PDF file iconPDF (283 KB)  
    Freely Available from IEEE
  • Agile Software Development with Distributed Teams: Agility, Distribution and Trust

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

    Trust among team members is imperative for blending agility with distributed software development. Little is known about how team members who are dispersed across different geographical locations, time zones and cultures can build trust while working together in Agile software development projects. Through a Grounded Theory study that involved 55 participants from 38 different software companies in the USA, India and Australia, we investigate the key concerns of distributed teams in Agile software development. We found that trust among members of a distributed team is important for bridging spatial, temporal and socio-cultural distances in order for them to work together as one team. In this paper, we present techniques for building trust in Agile software development with distributed teams. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Proposing Regulatory-Driven Automated Test Suites

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

    In regulated domains such as finance and health care, failure to comply with regulation can lead to financial, civil and criminal penalties. While systems vary from organization to organization, the same regulations apply for all systems. As a result, efficiencies could be gained if the commonalities between systems could be captured in public, shared, test suites for regulations. We propose the use of Behavior-Driven-Development (BDD) technology to create these test suites. With BDD, desired system behavior with respect to regulatory requirements can be captured as constrained natural language 'scenarios'. The scenarios can then be automated through system-specific test drivers. The goal of this research is to enable organizations to compare their systems to regulation in a repeatable and traceable way through the use of BDD. To evaluate our approach, we developed seven scenarios based on the HITECH Act Meaningful Use (MU) regulations for healthcare. We then created system-specific code for three open-source electronic health record systems. We found that it was possible to create scenarios and system-specific code supporting scenario execution on three systems, that iTrust can be shown to be noncompliant, and that emergency access procedures are not defined clearly enough by the regulation to determine compliance or non-compliance. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Assessing an Organization's Capability to Effectively Implement Its Selected Agile Method(s): An Objectives, Principles, Strategies Approach

    Page(s): 22 - 31
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (780 KB) |  | HTML iconHTML  

    Agile methods provide an organization or a team with the flexibility to adopt a selected subset of principles and practices based on their culture, their values, and the types of systems that they develop. More specifically, every organization or team implements a customized agile method, tailored to better accommodate its needs. However, the extent to which a customized method supports the organizational objectives, i.e. the 'goodness' of that method, should be demonstrable. Existing agile assessment approaches focus on comparative analyses, or are limited in scope and application. In this research, we present a systematic, comprehensive approach to assessing the 'goodness' of agile methods. We examine an agile method based on (1) its adequacy, (2) the capability of the organization to support the adopted principles and practices specified by the method, and (3) the method's effectiveness. We employ the Objectives, Principles and Strategies (OPS) Framework to guide our assessment process. The Framework (a) specifies objectives of the agile philosophy, (b) identifies principles that support the objectives, (c) designates strategies that implement the principles, (d) defines linkages that relate objectives to principles, and principles to strategies, and (e) prescribes indicators for assessing the extent to which an organization supports the implementation and effectiveness of those strategies. The propagation of indicator values along the linkages provides a multi-level assessment view of the agile method. In this paper, we discuss our assessment approach and substantiation results. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Agile Testing: A Systematic Mapping across Three Conferences: Understanding Agile Testing in the XP/Agile Universe, Agile, and XP Conferences

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

    Unit and acceptance testing are central to agile software development, but is that all there is to agile testing? We build on previous work to provide a systematic mapping of agile testing publications at major agile conferences. The analysis presented in this paper allows us to answer research questions like: what is agile testing used for, what types of studies on agile testing have been published, what problems do people have when performing agile testing, and what benefits do these publications offer? We additionally explore topics such as: who are the major authors in this field, in which countries do these authors work, what tools are mentioned, and is the field driven by academics, practitioners, or collaborations? This paper presents our analysis of these topics in order to better structure future work in the field of agile testing and to provide a better understanding of what this field actually entails. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Ten Lessons Learned from Integrating Interaction Design and Agile Development

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

    Agile development have a distinct culture that at first glance seems to conflict with Interaction Design. Therefore, integrating these two areas becomes a challenging task. There is little guidance about integrating them. Very limited empirical evidence exists on Agile development and Interaction Design being combined in practice. In order to better understand how these approaches are combined in practice, a multiple-case study of Agile teams working with Interaction Designers was performed. In the paper, we present a set of ten lessons learned from these studies. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Analyzing Effectiveness of Workshops for Learning Agile Development Principles

    Page(s): 50 - 59
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (326 KB) |  | HTML iconHTML  

    Workshops are sometimes known as effective ways to learn the human and social factors of software engineering. However, their effectiveness in learning agile development principles in particular has not yet been determined, despite the fact that numerous agile development workshops have been held over the years. In this paper, we analyze the effectiveness of agile development workshops through an experiment, and show that one of representative workshops is indeed effective at learning agile principles. Self-study is another commonly used method to learn something new. Therefore, we compare the effectiveness of workshops with that of self-study to better illustrate the effectiveness of agile development workshops. In our experiment, we examine 7 workshop subjects and 8 self-study subjects, and compare their scores on the agile mind check, which is a method used to measure their degree of mastery of agile principles. As a result, we demonstrate the effectiveness of agile development workshops, especially those that simulate actual experiences. We also show that one of workshops is more effective than self-study regarding the agile mind check score. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • System Dynamics Modeling of Agile Continuous Delivery Process

    Page(s): 60 - 63
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (266 KB) |  | HTML iconHTML  

    The popularization of agile development as well as the recent prevalence of virtualization and cloud computing has revolutionized the software delivery process- making it faster and affordable for businesses to release their software continuously. Hence, the need for a reliable and predictable delivery process for software applications. The aim of this paper is to develop a System Dynamics (SD) model to achieve a repetitive, risk-free and effortless Continuous Delivery process to reduce the perils of delayed delivery, delivery cost overrun and poor quality delivered software. View full abstract»

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

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

    A classic way to choose a supplier is through a bidding process where tenders from competing companies are evaluated in relation to the customer's requirements. If the customer wants to hire an agile software developing team instead of buying a software product, a new approach for comparing tenders is required. In this paper we present the design of such a new approach, the Scrum Code Camp, which can be used to assess agile team capability in a transparent and consistent way. A design science research approach is used to analyze properties of two instances of the Scrum Code Camp where seven agile teams were evaluated. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Transforming a Public Sector Company: From Stone Age to Agile

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

    On June 7, 2012, our CIO walked our Kanban board with the management team. When he saw a low priority feature being worked on, he took it off the board and told them to stop. This was the first time he'd had an organization with the transparency and flexibility that gave him this kind of control. We provided the opportunity to empower our executives as much as our workers. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Adapting Agile Methodology to Overcome Social Differences in Project Members

    Page(s): 82 - 87
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (202 KB) |  | HTML iconHTML  

    Projects often consist with members with different values that may cause conflicts within the team causing decrease in members' motivation, involvement, and cohesiveness. In our experiences with off shoring Japanese software development projects to China, we were having difficulties with low quality deliverables and high turnover rate of Chinese members because of social differences. Our attempts to create a common culture were not very successful because people in general are less likely to change their basic views and behavior in a short period of time. We, however, were able to obtain success by acknowledging that differences are going to exist and adopting and adapting agile practices in consideration of the existence of these differences. We will show Kaizen as is used by a Japanese company in software development. We will focus on our experiences with social differences we've found and how we continuously adapted practices in our project to take better advantage of the situation as relationship between members changed. It is based on our over 10 years of experience in trying to improve a software package development at a software company in China, which has now become our subsidiary. During our attempts, we have learned the importance of agile mentality in resolving value difference issues. We believe what we've learned in adapting agile practices is not just limited to our particular project but can be useful in agile projects in general and thus can be used to assist resolve value differences in organizations as well. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Beyond Requirements Dictator: How Agile Helped a Business Analyst Discover Her Real Value

    Page(s): 88 - 93
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (517 KB) |  | HTML iconHTML  

    This is my personal journey of discovering how to provide value as a business analyst on an agile team. I will share some things that smoothed my path and some obstacles that slowed me down. And for the many BAs struggling with how they fit into this new world, I will also redefine the role of a business analyst as more than a requirements dictator. In closing, I will illustrate how BAs, as well as the rest of the team, can reap the benefits of broadening their roles and stepping outside of their role boundaries. View full abstract»

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

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

    Software testing is a key part of software development, so it's important that the testers be as effective as possible. Especially in fast-feedback agile teams, software testers must respond to their teammates' need for information with readily available, easy-to-understand testing materials. The novel twist of turning user experience personas inward to focus on the product team members provides deep insights into both what decisions team members need to make and how to present testing information to them to support those decisions. Having established personas as the context for the testing work, testers are poised to spring into action, planning, estimating, and executing both exploratory testing and user-facing automation. Testers then surface the results of this work to the product team in a way that helps them to address concerns in a timely fashion. Big visible charts display testing for co-located teams in a particularly effective form. Testers experiment with a variety of big visible representations throughout the life of the team, retaining these charts only as long as they provide value for decision-making and moving on to other forms as the team learns more about satisfying their information-gathering needs through testing. User personas produce a fresh perspective on product team members to help testers to focus on the value big visible testing artifacts provide to the individuals on a software development team. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Black Swan Farming Using Cost of Delay: Discover, Nurture and Speed Up Delivery of Value

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

    Improving prioritization has become a tired concept in most IT departments, and yet it has the potential to change the conversation from one of cutting cost, to delivering valuable solutions as quick as the business needs it. This paper examines how Maersk Line applied an economic framework across a $100 million portfolio to quickly discover, nurture and speed up the delivery of value. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Need 4 Speed: Leverage New Metrics to Boost Your Velocity without Compromising on Quality

    Page(s): 117 - 120
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (414 KB)  

    As Agile becomes the de-facto SDLC practice, it has become evident that additional practices are required to allow enterprises to realize the premise of it. In this experience report, we will share the practices learnt and exercised over the past 3 years that helped us cope with the common challenges of large scale enterprise projects. The concept of "Application Lifecycle Intelligence" discussed in this paper covers the key principles of these best practices. It shares the additional analytics and metrics that allowed HP to enable cross time zones collaboration and alignment through transparency and provides insights into quality and risk. The key principal accomplished by extracting data from various practitioners tools and surface it in an actionable format for the various stakeholders. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Continuous Delivery? Easy! Just Change Everything (Well, Maybe It Is Not That Easy)

    Page(s): 121 - 128
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (304 KB) |  | HTML iconHTML  

    Rally Software transitioned from shipping code every eight-weeks, with time-boxed Scrum sprints, to a model of continuous delivery with Kanban. The team encountered complex challenges with their build systems, automated test suites, customer enablement, and internal communication. But there was light at the end of the tunnel - greater control and flexibility over feature releases, incremental delivery of value, lower risks, fewer defects, easier on-boarding of new developers, less off-hours work, and a considerable up tick in confidence. This experience report describes the journey to continuous delivery with the aim that others can learn from our mistakes and get their teams deploying more frequently. We will describe and contrast this transition from the business (product management) and engineering perspectives. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Refactoring as a Lifeline: Lessons Learned from Refactoring

    Page(s): 129 - 136
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (389 KB) |  | HTML iconHTML  

    Refactoring legacy code can be a major impediment for teams transforming to agile due to the high cost of manual regression testing of frequent (typically 2-week) releases. Also, attempts to implement automated tests may involve technical and cost issues. In this report we present a new and more systematic approach to refactoring we have found to be successful for refactoring legacy code that has few (if any) automated tests. This report describes two experiences: one with 3 teams applying a basic and traditional refactoring approach, and another with 2 teams applying the new approach. This new approach helped achieve better results in covering code with tests, involved senior management to retain their support, and achieved better and more sustainable pace of development powered by continuous refactoring techniques. View full abstract»

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