An Iterative Model for Agile Product Line Engineering Yaser Ghanam University of Calgary yghanam@ucalgary.ca Frank Maurer University of Calgary frank.maurer@ucalgary.ca Abstract Agile software development (ASD) and software product line engineering (SPLE) seem to be two rewarding yet disparate schools of thoughts in software engineering. ASD encourages strong business involvement in development activities, focuses only on the requirements at hand, and deems huge investment in requirement and design upfront unjustifiable. On the other hand, SPLE considers intensive domain analysis and flexible & detailed software design as prerequisites to any development effort. SPLE plans for potential future projects, and dedicates considerable resources for preplanning efforts. Integrating ASD and SPLE, although is challenging, has a huge potential of magnifying enhancements in quality, cuts in cost and reductions in time-to-market. In this paper, we present our research on this integration. We propose a model that enables agile organizations to establish product lines without disturbing the agility of their practices. The model is a bottom-up application-driven approach that relies on automated tests to derive core assets from existing code. 1. Introduction Agile software engineering is a collection of methodologies that, according to the Agile Manifesto [1], give customer involvement and satisfaction the highest priority. Agile practitioners preach an iterative development approach that encourages values and practices such as stakeholder communication, early feedback from customer, test-driven development, short iterations, just-in-time design and continuous integration. The field of software engineering has matured enough to realize that getting the customer requirements right is key to the success of any software project. This is why traditional software engineering approaches invest so much time at the beginning of the project life cycle to elicit these requirements, clarify any vagueness around them, document them and produce designs that attempt to satisfy them. On the other hand, given the high level of uncertainty of customer requirement at the beginning of the project, agile methods discourage large investments in upfront analysis and design. Big-design-up-front (BDUF) is seen by many agile practitioners as the antithesis of agility. Agile methods tackle requirements in a different manner. While a project vision and rough scope are usually developed by agile teams, they do not spend more than a few weeks on this effort before iterative development starts. Detailed requirements are only determined during development iterations and only for features that are part of this increment. Requirements are elicited from the customer in the form of user stories and made more concrete by defining acceptance tests [2]. A short development iteration (two to four weeks) implements these user stories and produces a working version of the system. At the end of each iteration, the customer gets the final say on how well those requirements are satisfied and what needs to be done in the next iteration. The architecture of the system evolves gradually bottom-up as the project needs become clearer. Design decisions are agreed upon by the members of the development team who talk to each other in their daily scrum meetings. Agile methods demonstrate an outstanding flexibility to accommodate change requests. This responsiveness to change, although might be expensive, can still be more economically justified (by the not-so- much investment upfront in predicting future changes) than other models which deem any change request during the implementation phase very expensive (because of the so-much investment upfront). While scientific data on agile methods is not yet conclusive, they seem to work well according to a growing number of case studies, experience reports and controlled experiments investigating individual agile practices (e.g. business organizations are reporting success in adopting agile practices like Test Driven Development [3]). Another successful practice in industry is software product line engineering. By planning for families of products as opposed to single products, SPLE offers opportunities for cost minimization, time reduction, and quality improvement. This is achieved through emphasizing flexibility of the reference architecture of the product line and focusing on the reusability of