An Ideal Process Model for Agile Methods
Marcello Visconti1 and Curtis R. Cook2
1 Departamento de Informática, Universidad Técnica Federico Santa María, Valparaíso, CHILE
2Computer 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.
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 [4]. 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 [9] compared XP practices with SW-CMMsm1
. He concluded that agile processes generally focus on technical issues while SW-CMMsm1 generally focuses on management issues and therefore considered them complementary. Turner [11] considered general agile methods in the context of CMMIsm1 and process improvement. He concluded that agile process “fit into the realm of process improvement” under a “more essential and less literal” interpretation of CMMIsm. Another study by Kane and Ornburn [8] investigated the degree to which XP and Scrum satisfy the process areas of the CMMIsm. 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 [2] and produce an Agile Manifesto [1] (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
model is adapted from a software process framework originally designed for constructing a process model for a particular software process or task [12]. 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
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
Dimension Phase Core Process Quality Assurance Usability/Customer Satisfaction Identify Define important practices of process for generating product or providing service Define important quality assurance practices for product or service Define important practices for product usability or customer satisfaction Monitor Monitor adherence to process Monitor quality assurance activities Monitor usability/customer satisfaction activities Measure Define, collect and analyze measures
2.2 Proposed Ideal Agile Process Model
The Agile Manifesto [1] 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 agile-compliant 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
Dimension Phase Core Process Customer Satisfaction Identify
• Deliver working software frequently
• Constant interaction between customers and developers • Maximize the amount of work
not done
• Face-to-face communication in development team • Constant rate of development • Self-organized teams
• Satisfy customer
• Welcome changing requirements • Continuous attention to technical
excellence and good design • Provide environment and support
Monitor
• 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
• Early and continuous delivery of valuable software
• Business people and developers work together daily
Measure • Working software is primary measure of progress
• Working software is primary measure of progress
Feedback
• At regular intervals, team reflects on how to become more effective, tunes and adjusts its behavior
• Satisfy customer
• At regular intervals, team reflects on how to become more effective, tunes and adjusts its behavior
3
Application of Ideal Agile Process ModelIn 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.
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.
Table 4. XP and Scrum – Summary of Practices and Components
XP Scrum
• 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
• 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
Table 5. Ideal Agile Process Model – Mapping of Practices for XP and Scrum
Phase/Dimensions Ideal Agile Practices XP Practices Scrum Practices
Deliver working software frequently
Small releases and continuous integration
Sprints Constant interaction
between customers and developers
Whole team and on-site customer
Scrum teams, product owner Maximize the amount
of work not done Planning game
Sprint planning meeting Face-to-face
communication in development team
Whole team and pair programming
Daily scrum
Constant rate of development
Sustainable pace/40-hour week and small
releases
Sprint Identify/Core Process
Self-organized teams Whole team Scrum team
Early and continuous delivery of valuable
software
Small releases and continuous integration
Sprint review meetings, empirical management Business people and
developers work together daily
Whole team and on-site customer
(4)
Trust developers to get the job done
Pair programming, collective code ownership, metaphor
Scrum teams and sprint review meetings Monitor/Core Process
Proper environment
and support provided (2)
Scrum master
Measure/Core Process Working software is
primary measure of progress
Small releases, continuous integration
and big visible chart
Sprint review meetings, empirical management
and sprint backlog graph Feedback/Core
Process
At regular intervals, team reflects on how
to become more effective, tunes and adjusts its behavior
Satisfy customer Testing Product backlog, sprint
review Welcome changing
requirements
Small releases and continuous integration
Product backlog Continuous attention
to technical excellence and good design
Testing, simple design, pair programming, refactoring and coding
standards
(3) Identify/Customer
Satisfaction
Provide environment
and support needed (1)
Scrum master Early and continuous
delivery of valuable software
Small releases and continuous integration
Sprint review meetings, empirical management Monitor/Customer
Satisfaction
Business people and developers work
together daily
Whole team and on-site customer
Measure/Customer Satisfaction Working software is primary measure of progress Small releases, continuous integration
and big visible chart
Sprint review meetings, empirical management
and sprint backlog graph
Satisfy customer Testing, small releases,
continuous integration
Sprint review meetings Feedback/Costumer
Satisfaction
At regular intervals, team reflects on how
to become more effective, tunes and adjusts its behavior
Small releases, continuous integration
and big visible chart
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.
learned? what can we do better? what puzzles us? Fowler [16] 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 [18] 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 [18] 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 [16] 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 WorkWe 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 management-oriented.
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?
References
1. Agile Alliance. Manifesto for agile software development, http://agilemanifesto.org/, 2001 2. Agile Alliance, http://www.agilealliance.com/, 2001
3. K. Beck. Extreme Programming Explained: Embrace Change. Longman Higher Education, 2000 4. B. Boehm. Get ready for agile methods, with care. IEEE Computer, 35(1) (2002) 64-69 5. A. Cockburn. Agile Software Development. Addison-Wesley, 2002
6. J. Highsmith. What is agile software development? CrossTalk, 15(10) (2002) 4-9
7. What is Extreme Programming, http://www.xprogramming.com/xpmag/whatisxp.htm/, 2002 8. D. Kane and S. Ornburn. Agile development: weed or wildflower? CrossTalk, 15(10) (2002) 30 9. M. Paulk. Extreme Programming from a CMM perspective. IEEE Software, 18(6) (2001) 19-26 10. K. Schwaber and M. Beedle. Agile Software Development with Scrum. Prentice Hall, 2002
11. R. Turner. Agile development: good process or bad attitude? Proceedings of 4th International
Conference on Product Focused Software Process Improvement PROFES 2002, Springer-Verlag
Lecture Notes in Computer Science 2559 (2002) 134-144
12. M. Visconti and C. Cook. A meta-model framework for software process modeling. Proceedings
o f 4th International Conference on Product Focused Software Process Improvement PROFES
2002, Springer-Verlag Lecture Notes in Computer Science 2559 (2002) 532-545
13. P. Wendorff. Organisational culture in agile software development. Proceedings of 4th
International Conference on Product Focused Software Process Improvement PROFES 2002, Springer-Verlag Lecture Notes in Computer Science 2559 (2002) 145-157
14. Scrum, http://www.controlchaos.com/, 2003
15. R. Miller. Demystifying Extreme Programming: “XP distilled” revisited, Part 1, http:// http://www-106.ibm.com/developerworks/java/library/j-xp0813/, 2002
16. M. Fowler. The new methodology. http:// http://www.martinfowler.com/articles/newMethodology.html, 2003
17. N. Kerth. Project retrospectives: a handbook for team reviews. Dorset House, 2001
18. 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, 2002 19. C. Collins, R. Miller. Adaptation: XP Style, Extreme Programming XP 2001, Cagliari, Sardinia,
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.
