1 An Ideal Process Model for Agile Methods Marcello Visconti 1 and Curtis R. Cook 2 1 Departamento de Informática, Universidad Técnica Federico Santa María, Valparaíso, CHILE 2 Computer Science Department, Oregon State University, Corvallis, Oregon, USA Abstract. We present a software process model that can be effectively applied to the agile software development context. Our approach builds an ideal agile software process model starting from the principles established by the agile community in what is known as the Agile Manifesto. The practices defined by the ideal model can be used to assess the various agile methods to determine any missing or under-emphasized practices or practices needing improvement. We compared the practices defined for two of the most popular agile methods (XP and Scrum) with the ideal model and found that these two methods do not explicitly address in an organized way all the principles in the Manifesto. While these approaches do include practices to regularly review the effectiveness of the particular method and tune the method s behavior accordingly for a particular product being developed, they lack explicit practices to perform a retrospective focusing on the process, with the goal of adapting and improving the method itself and its future application. We propose a simple practice that could be added to these methods that would address this apparent oversight. This practice would also provide the ability to leverage what was learned from previous projects to the future projects,. We believe the proposed ideal model is complete, flexible, and can be used to assess and propose simple process improvement actions for agile methods. We also point out some open questions about the best way to share the knowledge gained from retrospectives and to do end of project reviews. Keywords. Agile methods, process models, assessment, XP, Scrum 1 Introduction There has been a rapidly growing interest in agile methods for developing software. This interest has been sparked by the many reported successes of agile methods in situations where classical methods have been unsuccessful [2,4,5,6,7,8,11,10,13,14]. Extreme Programming (XP) [3,7] and Scrum [10,14] are two of the most popular agile methods. Agile methods have been classified as lightweight methodologies in recognition of their minimizing bureaucracy and documentation, short iterative cycles, ease of
2 response to changing requirements, and close interaction with the customer. Agile methods are lightweight in the sense that much of the documentation and many of the activities typically done in traditional software development, but that are not directly related to the product being developed, are not performed. For example, documenting that a particular milestone has been completed is not done; rather than designing to allow for all possibilities that may occur, an agile method implements the simplest design that meets the immediate customer needs. Agile methods are considered people-focused in sharp contrast to the process-focused heavyweight classical software development methods. Agile development teams are free to organize in any way that they feel will enable them to best accomplish the task. Further, in agile methods the developers work closely with the customer, frequently delivering the increments of the product the customer feels are most important. Even though agile methodologies are lightweight, they do have a defined process. Some agile proponents may consider this an oxymoron because they believe that agile methods present an alternative to a process-centered approach. They feel that their lightweight and lean development methodologies are distinctly different from the heavyweight, bureaucratic and disciplined plan-driven methodologies . Researchers have investigated the relation between process improvement models and agile methods. However, most of this work has compared the components of their process models with agile methods, such as XP and Scrum, to determine the degree to which these agile methods satisfy the components in their models. In an example of this approach Paulk  compared XP practices with SW-CMM sm1. He concluded that agile processes generally focus on technical issues while SW-CMM sm1 generally focuses on management issues and therefore considered them complementary. Turner  considered general agile methods in the context of CMMI sm1 and process improvement. He concluded that agile process fit into the realm of process improvement under a more essential and less literal interpretation of CMMI sm. Another study by Kane and Ornburn  investigated the degree to which XP and Scrum satisfy the process areas of the CMMI sm. Their comparison showed that XP and Scrum were strongest in the Project Management category and weakest in the Process Management category. This is not surprising considering the effort devoted to short-range planning in XP and Scrum and the lack of focus on process of these agile methods. Another approach to studying the relation between process and agile methods is to develop a process model for agile methods. In this paper we present a process model for an ideal agile method. This ideal model had to embody the essential properties of agile methods since it would be used as the standard in assessing the agility of agile methods. Fortunately, the agile community has come together to form the Agile Alliance  and produce an Agile Manifesto  (see Table 1) that states the principles of agile methods. Our ideal model is based on the principles of the Agile Manifesto. This paper presents our ideal process model for agile methodologies and uses it to evaluate two of the most popular agile methods, XP and Scrum. The ideal process 1 SW-CMM sm, CMMI sm are service marks of Carnegie Mellon University
3 model is adapted from a software process framework originally designed for constructing a process model for a particular software process or task . Rather than focusing solely on the process dimension of the product or service, that framework integrates process, quality assurance, and usability/customer satisfaction. This equal focus on the three dimensions seems to better reflect the customer orientation and other aspects of agile methods than a framework with only a process dimension. The next section presents the structure of the ideal agile process model. In Section 3 we use the ideal process model to evaluate XP and Scrum as defined in standard references. Our evaluation uncovered several agile principles not explicitly addressed in both of these methods, showing particularly that they lack explicit practices to perform retrospectives focusing on the process. In Section 4 we show how the addition of a simple practice to XP and Scrum would address this weakness. Finally, we present our conclusions and future work. Table 1. Agile Principles Our highest priority is to satisfy the customer through early and continuous delivery of valuable software Welcome changing requirements, even late in development. Agile process harness change for the customer s competitive advantage Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale Business people and developers must work together daily throughout the project Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done The most efficient and effective method of conveying information to and within a development team is face-to-face conversation Working software is the primary measure of progress Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely Continuous attention to technical excellence and good design enhances agility Simplicity the art of maximizing the amount of work not done is essential The best architectures, requirements, and designs emerge from self-organizing teams At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly 2 Ideal Agile Process Model Our proposed ideal agile software process model is an adaptation of a software process model framework  for a single process task and whose main purpose is to serve as a guide for the identification of key practices that drive software process assessment and improvement for that task. In this section, we describe the original framework and explain how it was adapted and applied in the agile software development context.
4 2.1 Background: Software Process Model Framework The software process modeling framework was designed to overcome process-only assessments shortcomings, help produce more useful information to proceed with planning for process improvement, and construct models for single-focus process areas. Rather than focusing entirely on process, the framework incorporates assuring the quality and usability of the end products produced or customer satisfaction with the service provided by the process. The framework has three dimensions (Core Process, Quality Assurance, Usability/Customer Satisfaction) and four phases (Identify, Monitor, Measure, and Feedback) associated with each dimension. Table 2 illustrates the framework. We see that the structure of the framework reflects not only the process itself, but also the quality and usability/customer satisfaction of the products or service produced by the process. Note that there are separate Identify and Monitor phases in each dimension, but combined Measure and Feedback phases. The reason for the combined Measure and Feedback phases is that activities that support measurement and feedback are dimension-independent. Table 2. Software Process Model Framework Phase Identify Monitor Measure Feedback Dimension Core Quality Usability/Customer Process Assurance Satisfaction Define important Define important Define important practices of quality assurance practices for product process for practices for usability or customer generating product or service satisfaction product or providing service Monitor Monitor quality Monitor adherence to assurance usability/customer process activities satisfaction activities Define, collect and analyze measures Generate, evaluate, prioritize and incorporate recommendations The process models developed using this framework are different from other process maturity models in several important ways: in the model developed using the framework there is equal focus on process, quality assurance and usability/customer satisfaction; the framework is specifically geared for developing a model for a particular process or task rather than encompassing the entire development process; and, the framework is flexible and the models developed using the framework can easily be tailored to the particular process and the particular organization. More details about the original process framework, how it differs from other models and application examples, are given in .
5 2.2 Proposed Ideal Agile Process Model The Agile Manifesto  helped us overcome the problem of what properties of agile development methods to include in developing an ideal agile process model. The Agile Manifesto principles are the product of a consensus among all the main agile proponents. Hence, rather than attempting to capture the essential aspects of all or the most commonly used agile methods in our model, we could focus on capturing the essential aspects of the Agile Manifesto. Thus, using the process model and the Agile Manifesto we were able to form an initial version of the ideal model for an agilecompliant software process, i.e. a process that satisfies both the requirements outlined in our earlier software process modeling framework and the principles expressed in the Manifesto. The original process model framework separates Quality Assurance and Usability/Customer Satisfaction. However, the agile principles stress user and customer involvement, and in agile methods software quality assurance and customer satisfaction are tightly related to whether the final working software does or does not meet customer expectations; hence, the quality assurance and usability/customer satisfaction dimensions are combined into a single dimension. We call this single dimension Customer Satisfaction. Table 3 presents the Ideal Agile Process Model (IAPM) showing the mapping of the agile principles to the phases and dimensions of the model. The Model emphasizes the distinction between the process (Core Process dimension) and the product (Customer Satisfaction dimension). This distinction is important because some agile practices apply to the product, some to the process and some to both. Hence, a comparison of the IAPM with a particular agile method will show clearly any weakness on either dimension making it more difficult to overlook a potential practice not explicitly addressed. Table 3. Ideal Agile Process Model Phase Identify Dimension Core Customer Process Satisfaction Deliver working software Satisfy customer frequently Welcome changing requirements Constant interaction between Continuous attention to technical customers and developers excellence and good design Maximize the amount of work Provide environment and support not done needed Face-to-face communication in development team Constant rate of development Self-organized teams
6 Monitor Measure Feedback Early and continuous delivery of valuable software Business people and developers work together daily Trust developers to get the job done Proper environment and support provided Working software is primary measure of progress At regular intervals, team reflects on how to become more effective, tunes and adjusts its behavior Early and continuous delivery of valuable software Business people and developers work together daily Working software is primary measure of progress Satisfy customer At regular intervals, team reflects on how to become more effective, tunes and adjusts its behavior 3 Application of Ideal Agile Process Model In this section we illustrate the application of the proposed IAPM to two of the most popular agile methods: XP and Scrum, with the goal of determining to what extent each of the practices or components as defined for XP and Scrum satisfies the principles prescribed in the Manifesto, i.e. how agile is the method. It is important to note that for this evaluation we are using the practices and components as defined in the standard references for XP [3,7] and Scrum [10,14]. The application will demonstrate that the proposed ideal agile model helps in identifying strengths and weaknesses for both methods in terms of their fitness to the agile principles expressed in the Manifesto; it also indicates potential areas of improvement, in terms of simple practices that could be added to the agile method while preserving the agile spirit. 3.1 Application to XP and Scrum A summary of main practices and components of XP and Scrum is given in Table 4. These practices and components were taken directly from the standard references [3,7,10,14]. For convenience of the reader, brief descriptions are included for each practice and component. The last 2 items for XP and the last 4 items for Scrum are components or key properties of the method. Table 5 compares the proposed ideal agile process model with XP and Scrum. Rather than using an assessment questionnaire to determine the degree of satisfaction, an assessment technique typically used in process improvement efforts, we use a lightweight approach. In this approach the practices and components of each method are matched with the practice or practices of the ideal model they satisfy. Both XP and Scrum have explicit practices that address most of the four phases for each dimension. However, the one ideal practice that neither method explicitly addresses is the feedback phase in the core process dimension. While XP and Scrum have explicit
7 practices that evaluate how well product development is proceeding, they do not have explicit practices for evaluating how well the process itself is working. It is important to be clear about the message in Table 5. It says that according to the practices and components given in the standard references for both XP [3,7] and Scrum [10,14] there is no regular explicit feedback about the process. However, this lack of regular explicit feedback appears to be in the definition of each method and not in the actual practice or way in which these methods are taught. Several proponents of these methods [18,19] encourage the use of retrospectives at the end of each iteration in XP or sprint in Scrum. In these retrospectives the team reflects on what happened during the last iteration and if necessary, tunes its process accordingly. We believe that both methods should include some simple practice to address this, and propose such a practice in next section. The assessment does point out one big difference between XP and Scrum, namely that XP is mostly engineering-oriented and Scrum mostly management-oriented. This is illustrated in Table 5 in which XP does not address the need to provide and monitor proper environment and support (marked (1) and (2) in the table), while Scrum does it through the Scrum Master. The opposite occurs for continuous attention to technical excellence and good design: where XP does address it through a number of engineering practices (marked (3) in the table), Scrum does not consider any particular practice. Another important difference is that XP stresses user involvement more than Scrum does: while users are on-site as part of the team at all times in XP, they do not belong to the Scrum team and the interaction is performed indirectly through the product owner and not on a daily basis (marked (4) in the table). This suggests that both agile methods can be used jointly given the complementary nature of their practices. This is consistent with the changes to XP proposed by Miller , where a new set of 19 practices (some old, some new, some changed) instead of the original 12 is presented and organized as joint practices, programmer practices, management practices and costumer practices.
8 Table 4. XP and Scrum Summary of Practices and Components XP On-site customer have an actual user on the team full-time to answer questions Planning game predicting what will be accomplished (release planning) and determining what to do next (iteration planning) Sustainable pace/40-hour week working overtime when it is effective, normal work maximizes productivity Testing developers continually write unit tests that must run for development to continue and customer write tests to demonstrate that functions are finished Simple designs the team keeps the design exactly suited for the current functionality of the system Pair programming two programmers, sitting side by side, at the same machine Collective code ownership any pair of programmers can improve any code at any time Coding standard all code in the system looks as if it was written by a single, very competent individual Metaphor common vision of how the program works Refactoring continuous design improvement, focusing on removal of duplication, increasing cohesion, lowering coupling Small releases first, team releases running, tested software chosen by customer, at every iteration; then, team releases to end users frequently Continuous integration system fully integrated at all times, multiple builds frequently Whole team all contributors are members of one team, including customer, manager, testers Big visible chart basic management tool Scrum Product owner prioritizes the product backlog Scrum master responsible for making sure a scrum team lives by the values and practices of scrum protects the team from overcommiting Sprints series of iterations that determine project progress Product backlog master list of all functionality desired in the product Scrum teams commits to completing top priority items during a sprint Sprint backlogs top priority items during a sprint Sprint planning meetings determination of which tasks will move from product backlog to sprint backlog Daily scrums brief daily meetings Sprint review meetings scrum team shows what they accomplished during the sprint demo of new features Empirical management clear visibility into project based on first hand observation and backlog graphs Self-organizing teams No requirements changes during sprint No specific engineering practices prescribed Sprint backlog graph used to reflect progress
9 Table 5. Ideal Agile Process Model Mapping of Practices for XP and Scrum Phase/Dimensions Ideal Agile Practices XP Practices Scrum Practices Identify/Core Process Deliver working Small releases and Sprints software frequently continuous integration Constant interaction Whole team and on-site Scrum teams, product between customers customer owner and developers Maximize the amount Planning game Sprint planning meeting Monitor/Core Process Measure/Core Process Feedback/Core Process Identify/Customer Satisfaction Monitor/Customer Satisfaction of work not done Face-to-face communication in development team Constant rate of development Whole team and pair programming Sustainable pace/40- hour week and small releases Daily scrum Sprint Self-organized teams Whole team Scrum team Early and continuous Small releases and delivery of valuable continuous integration software Business people and developers work together daily Trust developers to get the job done Proper environment and support provided Working software is primary measure of progress At regular intervals, team reflects on how to become more effective, tunes and adjusts its behavior Satisfy customer Welcome changing requirements Continuous attention to technical excellence and good design Provide environment and support needed Early and continuous delivery of valuable software Business people and developers work together daily Whole team and on-site customer Pair programming, collective code ownership, metaphor (2) Small releases, continuous integration and big visible chart Testing Small releases and continuous integration Testing, simple design, pair programming, refactoring and coding standards (1) Small releases and continuous integration Whole team and on-site customer Sprint review meetings, empirical management (4) Scrum teams and sprint review meetings Scrum master Sprint review meetings, empirical management and sprint backlog graph Product backlog, sprint review Product backlog (3) Scrum master Sprint review meetings, empirical management (4)
10 Measure/Customer Satisfaction Feedback/Costumer Satisfaction Working software is primary measure of progress Satisfy customer At regular intervals, team reflects on how to become more effective, tunes and adjusts its behavior Small releases, continuous integration and big visible chart Testing, small releases, continuous integration Small releases, continuous integration and big visible chart Sprint review meetings, empirical management and sprint backlog graph Sprint review meetings Sprint review meetings, empirical management and sprint backlog graph 3.2 Proposed Improvements to XP and Scrum Table 5 shows that when XP and Scrum were compared to the IAPM, both methods lack an explicit practice to provide feedback about the process of applying the method. We feel the feedback is important because it provides a way to: determine how well an agile method is working improve or tailor the agile method determine which parts of the particular agile methods are being carried out collect body of knowledge about the experiences with and changes to a particular agile method and pass this knowledge to others in the organization. A next question is how to add a feedback practice to XP and Scrum in a way that preserves the agile spirit. One simple way that this could be done is to add a process review practice similar to the idea of post-mortem analysis from traditional development, but applied at the end of each iteration in XP or sprint review in Scrum instead of only at the end of the project. There still could be a final review when the project is finished. This end of iteration review will provide an opportunity to identify any problems in the method application and implement a change for the next iteration. Then at the end of the next iteration the change can be evaluated. This approach to a feedback practice seems to be in harmony with the lightweight philosophy of agile methods. The periodic reviews could be used to analyze any particular agile practice and its implementation. For instance, customer involvement, agile rules enforcement, impediments or process/method-related obstacles that interfere with doing the work, and so forth. Our proposal is consistent with what has been proposed by other authors. Miller  suggests a new XP joint practice named Retrospectives, where he proposes that collective reviews should happen in an organized way at least after every release, probably after every iteration. He also points out that everybody should take part in the retrospective, both the technical and the non-technical people. Fowler  proposed viewing process changing over time as a part of process self-adaptivity; further, he suggested that it can be deepened if teams do a more formal review at major project milestones following the project retrospective sessions outlined by Kerth . Kerth proposed that the review focus on the questions: what did we do well? what have we
11 learned? what can we do better? what puzzles us? Fowler  also points out that in XP reviews are neither emphasized, nor part of the process, and proposes making them one of the XP practices. Rising  has suggested the use of periodic checkups at the end of an increment, such as a sprint in Scrum, and then using the information gathered at these checkups to uncover patterns to improve the process. There are other questions about taking these reviews and retrospectives to the next level and improving the process. For example, how to share the information gathered during the feedback sessions in an agile way? Some of the proposed alternatives  include: repository, web site, meetings, training courses, story-telling. Another important question is what is the best way to close a project and leverage the lessons learned at the end of a project? Fowler  proposed holding 2-3 day off-site formal process reviews. We think that further research can be conducted aimed at answering these questions in order to keep improving the agile methods both on their conceptual definition as well as their practical application. 4 Conclusions and Future Work We have presented an ideal agile software process model that can be used to assess how agile a particular agile method is. The model is based on the agile principles as defined in the Agile Manifesto, thereby avoiding favoring any particular agile method. We have used the model to assess two of the most popular agile software development methods: XP and Scrum, based on the explicit practices defined by their proponents. The assessment of XP and Scrum has shown that as defined in the standard references both agile methods do not fully and explicitly comply with the principles defined in the Agile Manifesto, the most noticeable being neither method addresses in an organized way the need to reflect and evaluate how effectively an agile method process is working, in order to adjust its behavior to improve its effectiveness. The assessment also showed the differences between XP and Scrum, in terms of their orientation. While XP is mostly engineering-oriented, Scrum is mostly managementoriented. We believe by separating the process and product, the proposed ideal agile process model captures the essential principles of agile methodologies and hence can be used to evaluate the strengths and weaknesses of agile methods and to propose new practices that could be added to improve them. We have also identified two important open questions for further improvement of agile methods: how to share the information gathered in feedback sessions?, and what to do at the end of a project? Finally, in the immediate future we plan on using the ideal model to assess other agile software development methods.
12 References 1. Agile Alliance. Manifesto for agile software development, Agile Alliance, K. Beck. Extreme Programming Explained: Embrace Change. Longman Higher Education, B. Boehm. Get ready for agile methods, with care. IEEE Computer, 35(1) (2002) A. Cockburn. Agile Software Development. Addison-Wesley, J. Highsmith. What is agile software development? CrossTalk, 15(10) (2002) What is Extreme Programming, D. Kane and S. Ornburn. Agile development: weed or wildflower? CrossTalk, 15(10) (2002) M. Paulk. Extreme Programming from a CMM perspective. IEEE Software, 18(6) (2001) K. Schwaber and M. Beedle. Agile Software Development with Scrum. Prentice Hall, R. Turner. Agile development: good process or bad attitude? Proceedings of 4 th International Conference on Product Focused Software Process Improvement PROFES 2002, Springer-Verlag Lecture Notes in Computer Science 2559 (2002) M. Visconti and C. Cook. A meta-model framework for software process modeling. Proceedings of 4 th International Conference on Product Focused Software Process Improvement PROFES 2002, Springer-Verlag Lecture Notes in Computer Science 2559 (2002) P. Wendorff. Organisational culture in agile software development. Proceedings of 4 th International Conference on Product Focused Software Process Improvement PROFES 2002, Springer-Verlag Lecture Notes in Computer Science 2559 (2002) Scrum, R. Miller. Demystifying Extreme Programming: XP distilled revisited, Part 1, M. Fowler. The new methodology N. Kerth. Project retrospectives: a handbook for team reviews. Dorset House, L. Rising. Using patterns to improve process improvement: the argument for a resident minstrel. JAOO 2002 Java Technology and Object-Oriented Software Engineering, Aarhus, Denmark, C. Collins, R. Miller. Adaptation: XP Style, Extreme Programming XP 2001, Cagliari, Sardinia, Italy, 2001
13 Marcello Visconti is an assistant professor of computer science at Universidad Santa María in Chile. He has a Degree in Informatics Engineering from Universidad Santa María in Chile and a Ph.D. in computer science from Oregon State University. His main research interests are in the areas of software engineering, software quality and software process improvement, where he has participated in various national and international research projects along with collaborative work with industry, where he has completed his preparation as an S:PRIME assessor. He has served in the program committee of various national and international conferences. He is a member of the Chilean Computer Science Society, the IEEE and the ACM. Curtis R. Cook is professor of computer science at Oregon State University. He received his Ph.D in computer science from the University of Iowa. Professor Cook has over 20 years of research and experience in the software complexity metrics, program understanding and software quality areas. His most recent work has involved empirical studies in the end-user software engineering area. He has over 80 journal publications and conferences presentations and co-authored two books. He has taught workshops and short courses on software complexity merics and software measurement. He is a member of the editorial board of the Software Quality Journal and has served on the program of several conferences.