Agile Software Development – Control or Chaos?
Jussi Markula, [email protected], 42964F
T-76.650 Software Engineering Seminar, spring 2002
Executive Summary
The software business is moving fast. Software development projects have hard time trying to manage with change. The traditional plan-driven waterfall model of software development is being contested with so called agile methodologies. Agile methodologies are very light and responsive to change. In Agile methods individuals and teams are given much responsibility, software is developed iteratively and incrementally in short cycles and delivered early and often.
Controlling a software project is done through planning, measuring, evaluating and correcting. The planning in agile software development is done iteratively along the iterations of usually fixed length. Agile methodologies give guidance mostly to monitoring the completed functionality and some quality factors. Frequent testing and integration are means to get feedback early in the process.
The agile software development methodologies differ greatly in comprehensiveness, required discipline and in the level of abstraction. The more generic methods have to be complemented with other models or practices, especially in the area of project management.
Project management of agile software development is a different role than project management of traditional waterfall software development. Agile software development projects are primarily controlled by reprioritizing the work of upcoming iterations. Within the iterations, very little controlling can be done.
Table of contents
INTRODUCTION 5
Background of the study 5
Research problem 6
Objectives 6
Scope 6
Methodology 8
Structure of the paper 8
AGILE SOFTWARE DEVELOPMENT 9
Methodologies 10
Managing agile projects 12
Project priorities 13
PROJECT CONTROL 14
Planning 14
Measuring and evaluating 17
Correcting 20
CONTRAST TO THE WATERFALL MODEL 22
STRENGTHS AND WEAKNESSES IN MANAGING AGILE PROJECTS 24
SUMMARY AND CONCLUSIONS 25
Conclusions 26
Areas for future research 26
Assessment of the study 26
GLOSSARY AND TERMS 28
Introduction
Background of the study
Software development is not yet a mature engineering area. The methodologies and processes used for building software products are still lacking common industry-level practices. It is a commonly known problem in the software industry today that too many software projects do not meet their expectations. Many projects miss their schedules or do not have the required functionality and quality. In the worst cases projects end up delivering no software at all.
Many organizations develop software in sequential phases of design, implementation and testing, according to the traditional waterfall model. I have seen that companies have recognized the problems in the waterfall model and have been strongly against its use. Unfortunately the companies criticizing the waterfall model could not have come up with any better solutions and have ended up having no official methodology or other formal processes in place at all.
Some researchers have been trying to solve the problems existing in the waterfall model. They have found the problems to be mainly caused by waterfall being too slow in responding to many kinds of changes in modern turbulent software business environments (Highsmith 2000a). So called agile software development methodologies have been developed to respond to the needs of these situations.
Agile methodologies are very light and their main characteristic is responsiveness to change (Highsmith and Cockburn 2001). In Agile methods individuals and teams are given much responsibility, software is developed iteratively and incrementally in short cycles, delivering software early and often.
The developers of agile methodologies have presented them as having numerous advantages over other methods. Can agile methodologies stand against all the praising? Are they mature enough for widespread use? I have found an essential question to be if the agile methods are just self-guiding missiles, which get the project going fast but without proper direction. Can agile software development projects be monitored and controlled by project management and do they need to be? This study will focus on project controlling of agile software development methodologies as seen from a project manager’s point of view.
Research problem
The research problem of this study is to analyze how agile software development projects can be controlled according to different agile methodologies and in contrast to the traditional waterfall development.
Objectives
To answer the research problem mentioned above, the objectives are to:
(1) Compare project controlling characteristics of different agile methodologies.
(2) Compare project controlling of agile methodologies against the traditional waterfall model.
(3) Analyze the main benefits and problems of different agile methodologies in the area of project controlling.
Scope
There is steadily increasing, but still quite limited, amount of material available about the agile methodologies. The descriptions of the methodologies include usually only main aspects of the
under consideration is on the aspects of project controlling that are considered in the literature, or can be derived from it.
A significant area close to project controlling is software metrics. It is a large field of study in itself, and therefore I have included only a brief discussion about the actual measures used in agile methodologies. Other areas of software metrics, such as the measuring process, are beyond the scope of this study.
There are some other specific areas close to the subject that are left outside the scope of this study. Responsibilities and decision making are not discussed, since a thorough study of these areas of agile methods is outside the scope of this study. Resource controlling is left out it being more of a general human resource subject not specific to software engineering. Some essential coordination mechanisms will be included in the study, but a thorough discussion of this area is beyond the scope of this paper. Project reporting to the outside parties of the project team is an essential responsibility of a project manager, but it is not really a mechanism for controlling a project team and is therefore not discussed in this paper.
Open source software development as described in Raymond (2000) is not considered, even though it resembles an agile methodology (Fowler 2001). Organization structures of open source projects differ in principle from traditional team-based software projects, where substantially small and stable teams work under a project manager or a team leader.
Agile Modeling is included in some listings of agile methodologies, in e.g. (Boehm 2002). Though, Scott Ambler (2002), the author behind many Agile Modeling papers, writes about the scope of the Agile Modeling: “An important concept to understand about AM is that it is not a complete software process. AM’s focus is on effective modeling and documentation. That’s it. … It doesn’t cover project management, system deployment, system operations, system support, or a myriad of
other issues. …you need to use it with another, full-fledged process such as XP, DSDM, SCRUM, or UP…” Agile Modeling is therefore not used in the comparisons between the methods.
Methodology
The study was done as a literature study. The researched literature was the software engineering and project management books and articles available in the library of the Helsinki University of Technology and by the Institute of Electrical and Electronic Engineers (IEEE) and Association for Computing Machinery (ACM). Also, few books from additional sources were studied.
Structure of the paper
After this introductory chapter, agile software development, different agile methodologies and their overall management principles are introduced. In the next chapter areas of project control are discussed by comparing the corresponding properties of different agile methods. After comparing agile software development with the traditional waterfall development model, the strengths and weaknesses of agile methods are discussed. In the last chapter a summary of this paper is presented along with key findings.
Agile software development
The group of 17 methodologists met in February 2001 to discuss and share ideas about their methodology approaches. The group started using the word agile for their methodologies sharing many same principles. They formed the Agile Alliance, which is a non-profit organization for promoting the ideas behind agile software development (Agile Alliance, date unknown; Cockburn, 2001). Also, the group agreed upon a common set of principles stated as four value statements in the Agile Manifesto (Beck et al. 2001):
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
According to the Agile Manifesto and the studied literature, the main characteristics of agile software development are:
(1) Methodology and processes are as light as possible
(2) Software is developed iteratively and incrementally in short cycles. (3) First delivery is done as early as possible.
(4) Integration and testing is done continuously and already in the early phases. (5) There is an adaptive approach to change
(7) Leadership style is more leading than managing.
(8) Individuals and teams are given much responsibility and accountability.
The road to agile software development started a long ago. Mills (1971) was among the first to describe that software should be developed incrementally. Others contributing to the idea have been Brooks (1987), Tom Gilb (1988) with Evolutionary Development approach, Boehm (1988) with his spiral model and Martin (1991) with the Rapid Application Development (RAD) approach.
Several agile methodologies are described in the next section.
Methodologies
I have used two criteria for choosing the methodologies to be discussed in this study:
(1) Conformance to the agile methodology characteristics presented in the previous section. (2) The popularity of the methodology - I have included only widely known methodologies.
Especially the methodologies developed by the signatories of the Agile Manifesto as described by e.g. Cockburn (2001) are considered in this study.
The most widely known agile methodologies are Dynamic System Development Model (DSDM) developed by the DSDM Consortium, Microsoft’s Synch-and-Stabilize, Scrum, Extreme Programming (XP) and Peter Coad’s Feature-Driven Development (FDD). Their project management properties are compared thoroughly in this paper.
Adaptive Software Development (ASD) by Jim Highsmith, Lean Programming (Poppendieck 2001) and the several different methodologies in Alistair Cockburn’s Crystal Methodology family are also considered, but those three differ from the others in one aspect: as other methodologies can be viewed more as detailed process guides, these discuss development at a more abstract, almost
philosophical level. Lean Programming, Adaptive Software Development and the Crystal methodologies have many good advices and principles and describe many issues that need to be considered, but do not go into details of telling how to implement them in practice. Lean Programming goes the furthest in this sense, mostly because it is a derivative of the Japanese Lean Production approach developed for assembly lines in car manufacturing plants (Poppendieck 2001) Compared to these abstract methods, there are two methodologies that are in the total opposite, namely Extreme Programming and Pragmatic Programming. They give a lot of detailed instructions and require a lot of discipline. In The Pragmatic Programmer Hunt and Thomas (2002) explain that process needs discipline to be consistent and repeatable, but understands that people find it hard to maintain discipline. The answer of Pragmatic Programming for this is to automate everything that is possible.
Pragmatic Programming has many agile method characteristics. It should be noted though, that from the viewpoint of this study it has a fundamental difference to the other methods. In an essential book about Pragmatic Programming called The Pragmatic Programmer, Hunt and Thomas (2000) take a developer perspective for improving software development. They talk about how developers should approach coding, testing, requirements and users but have only a few issues about interacting with management.
Another important characteristic regarding this study is that of Crystal Methodologies and DSDM: They both take a minimalist methodology approach to be as light as possible. In some areas they give many details, but many areas are left to be specified by local practices. Therefore, when using Crystal Methodologies or DSDM it is usually necessary to substitute elements from other methodologies. As Cockburn (2001, p. 168) explains: “[When using Crystal Clear]…for example, the team could decide to [use] Scrum or DSDM's timeboxing and dynamic prioritization policies, Scrum's daily stand-up meetings, pair programming from XP, and so on.”. Concerning this paper it
should be especially noted that DSDM leaves the choice of different project management techniques for the user of the methodology (Stapleton 1997).
Rational Unified Process (RUP) is not included in the comparison of the methodologies, since RUP is not considered as a methodology in itself, but as a wider framework that can be used in several different manners, in e.g. waterfall or agile style (Fowler 2001).
Overall, the agile methodologies are a very diverse group. Constantine (2001) describes Extreme Programming as being an archetype of agile methods and writes about it and other methods: “Like nearly every other methodology—light, heavy or middleweight—XP and its agile teammates are really mish-mashes of tricks and techniques, plus methods, models and management formulas, along with tools, practices and even a bit of philosophy.”
Managing agile projects
Agile projects are typically fast paced. Many times agile teams have to work at the edge of chaos, there is a lot of uncertainty and change in the requirements, technology and in the environment. Many traditional project management practices are no longer effective in agile projects, as the two following examples show. Grady (1992, p. 92) states: “…the most commonly available automated project management tools – PERT programs and estimation tools – provide little support for project managers when schedules become tight and when they must convince others that the project is on track. These tools have update intervals of weeks or months and it is difficult to keep their data current.” Coburn (2001, p. 1109) writes about the same issue: “The more precision in the plan, the more fragile it is, which is why constructing GANTT charts is so feared: it is time-consuming to produce and gets out of date with the slightest surprise event.”.
Processes, tools, documentation, contracts and plans are all effective means of tracking and controlling a project, but the value statements of the agile manifesto introduced earlier value all
these as secondary issues in agile methods. Project managers will have tougher times in agile projects, since they cannot rely on these traditional control mechanisms. Therefore, project managers need to learn a whole different approach for running agile projects.
Many books and articles that write about agile methodologies share mostly the same suggestions for the needed management approach, e.g. (Cockburn 2001; Constantine 2001; Cusumano and Selby 1995; Highsmith 2000a). Traditional top-down based, command and control management approach should be replaced with a self organizing agile team which is constantly ready to be adapting to change by itself. Teams and individuals should be given lot of responsibility and they should be made accountable for their own work. Project managers should lead the team with a common vision and make sure that the team collaborates as swiftly as possible, smoothing the process and removing obstacles. Also principles of Pragmatic Programming share the same ideas, even though they are written from a developer’s point of view (Hunt and Thomas 2000).
Project priorities
Software projects can have very different characteristics depending on the project goal variables and their priorities. The different project variables are usually represented as a combination of time, scope and costs (Kerzner 1998). Since the costs in software projects are mostly personnel costs, the variables can be represented as a triangle (see Figure 1).
Figure1. Project priority triangle.
Time Resources
While one two of the variables may be fixed, there should be at least one that can be correspondingly adapted to changing situations. In agile methodologies, the project is done in several increments and the time spent and resources available for each increment are usually fixed, as in e.g. DSDM (Stapleton 1997), Scrum (Rising and Janoff 2000) and Synch-and-Stabilize (Cusumano and Selby 1995). Therefore, scope is the variable, which is most typically adjusted in agile projects to make sure that increments can be finished on time and fulfill their other objectives.
Project control
Combining the structures of Patel (1999) and Kerzner (1998) I define the controlling process of project management as consisting of:
(1) Planning, determining how the project is to be approached (2) Measuring, determining performance status towards objectives (3) Evaluating, determining needs to act to affect performance (4) Correcting, taking control action
The comparison of how these areas are implemented in different agile methodologies is discussed next in the corresponding sections.
Planning
As stated in the previous section, project control means essentially checking the deviations from plans and taking needed corrective actions. To be able to control a project, there should be some goals to strive for. If there is no direction to go to, directing the project takes it nowhere. If this is the case, how do project managers control agile projects where no planning is done? Or is there?
Barry Boehm (2002, p. 64) gives an explanation to this question: “General view [of agile methods], though, places more value on the planning process than the resulting documentation, so these methods often appear less plan oriented than they really are.” Coburn (2001, p. 179) puts this as a recommendation: “Documents can be very useful, as we have seen, but they should be used along with the words "just enough" and "barely sufficient.". He sees excessive documentation as highly non-productive, because the purpose is to communicate, not write documents. One good reason for more thorough documentation is to keep information available even if people leave the project. In most cases this does not hold true for project planning, since changing project manager in the middle of a project will be such a catastrophic event, that in order to survive it through documentation, probably a few books should be written.
In the beginning of software projects there are many uncertainties and everything cannot be planned at once. According to the iterative development principle of agile methods, also planning is done iteratively along the way. Still, in many methodologies, there are one or more special planning phases at the start of the project. For example, in Scrum it is called planning step in the pregame phase (Schwaber 1995), in DSDM the project is planned in feasibility study, business study and functional model iteration phases (Stapleton 1997) and in FDD there are three specific planning steps done before the actual design and build iterations (Schwaber 1995).
Comparison of the planning activities of agile methods, as categorized by a combination of the approaches of Duncan (1996) and Abran and Moore (2001) is presented in table 1 in the next page:
Table 1. Project planning activities in agile methodologies.
Method DSDM FDD Scrum S&S XP
Scope and requirements planning x x - x -
Feasibility analysis x - - - -
Requirements management process (*) (*) (*) (*) x Software process planning x - - - -
Component definition x x x x x
Requirement prioritization x x x x x
Activity sequencing x - - - -
Activity duration estimating x x (*) x x
Schedule development x - - x -
Resource allocation x x x x x
Risk management x - x - -
Quality management (*) - - x x
Cost estimating - - (x) - -
x Included in the methodology - Not included in the methodology
(*) Some examples or notes that this should be done, but not a formal way how
When comparing the planning activities of the five methodologies listed in the table, it can be seen that DSDM is by far the most comprehensive. It is mostly because the methodology talks about many issues at a non-practical level and does not describe any strict guidance or processes for implementing the issues. (Stapleton 1997)
There are four planning activities that are clearly stated in all of the compared five methodologies, these are discussed next. First common activity, splitting up the work to right-sized fragments,
should be done carefully in order to enable the short iterations. The next common activity, prioritizing of requirements, is perhaps the most essential property of agile methodologies. It is the adaptation mechanism for effectively fulfilling the requirements of the project. By constantly prioritizing the requirements, the project team can react to change and make sure the timeboxed iterations can be finished on time. Two other planning activities common to all compared methods are estimating the activity durations and allocating resources for the next iteration. These are traditional project planning practices which are in agile projects used for effectively timeboxing the iterations.
In Feature-Driven Development, Scrum, Synch-and-Stabilize and Extreme Programming there are no clear guidelines for doing feasibility analysis. They make a presumption that the project has already been considered worth doing before the development starts. An important point is also that there are no instructions on sequencing the activities. If interactivity dependencies are not revealed through sequencing them, a project might end up having big schedule problems later on. From the mentioned three methodologies it should also be noted that no software process planning or adjustment is done.
Measuring and evaluating
Project status should be known in order to direct the controlling activities. Unfortunately measuring the progress of a software project is not trivial. Software is intangible, abstract and has complex models. The state of software can not be determined by looking at it. It is hard to relate software characteristics to real world entities, which is needed by the definition of measurement by Fenton and Pfleeger (1998, p. 5): “Measurement is the process by which numbers or symbols are assigned to attributes of entities in the real world in such a way as to describe them according to clearly defined rules”.
Fenton and Neil (2000) divide software metrics into two components: (1) defining the actual measures
(2) how we collect, manage and use the measures
The first component includes the software metrics meant for measuring or predicting the needed entities. The entities can be some internal or external attributes of product, process or resource. When choosing the measures, those that support decision-making should be chosen. (Fenton and Neil 2000)
Agile methodologies do not give much guidance on what to measure. To complement the shortcoming, other approaches such as Goal/Question/Metric, described in Basili and Rombach (1988), could be used for determining what to measure.
When the project status has been measured, the situation should be analyzed in order to find out the possible needed actions (Kerzner 1998). The measuring and evaluating process can also be called project monitoring (Patel (1999). I have collected to the table below main monitored items in the agile methodologies. In the last column there are also some suggestions given on how to collect the measures. The division of the measured data is done according to Abran and Moore (2001), who suggest that component completion, task completion, risks and adherence to quality requirements could be monitored about a project.
Table 2. Project monitoring activities in agile methodologies. Method Component
completion
Risks Quality How
Scrum Backlog Sprint review meeting, obstacles in Scrum meetings
- Scrum meetings,
end-of-Sprint demos
S&S Checklists - daily builds,
bug data - XP Acceptance tests check completed stories - Customer and
unit tests, bug reports Tracker (usually project manager) checks status FDD Tracking By Feature - Design and code inspections Monitored by the chief programmers Crystal Clear
- - - 2 user viewings per
release DSDM Completion of
timeboxes
- - Practices are to be
decided locally
Monitoring task completion is not included in the list, since agile methods track completed functionality rather than task completion (Cockburn and Highsmith 2001). Stapleton (1997) calls this product based tracking instead of activity based tracking. When checking the status of impending work, project managers should be interested in how much will be done instead of how much it will take.
Monitoring items such as spent effort and costs and schedule adherence are not discussed in the studied agile method literature. The techniques for doing those are left up to project managers with a slight exception of Scrum, which gives some instructions on these areas in (Scrum Frequently Asked Questions).
An interesting practical advice on how to track progress is given in (Scrum Frequently Asked Questions): “An empirical way of determining a team’s progress is to listen during the daily Scrum meeting. The tone of voice, the way work is being described, and the impediments give an empirical feel for a team’s progress.”
In larger scale of a whole project, monitoring is done by comparing requirements with the completed functionality in each iteration. The iterations provide also the main tool for making corrective actions, as described in the following section.
Correcting
In many projects there are problems staying in schedule. The most typical corrective action suggested by agile methods is to reprioritize or remove functionality after each iteration, when the status of agile projects is clearly visible. In ASD, DSDM and Scrum the reprioritizing is done after the iteration, in Synch-and-Stabilize features are deleted from a release. Extreme Programming makes an exception in that reprioritization is allowed within the iterations. (Cockburn 2001)
As the main controlling mechanism is changing the scope of each iteration, the speed of correcting relates therefore strongly to the length of the iterations. The recommended lengths of iterations in different methodologies differ from one week to several months as can be seen from the following table:
Table 3. Iteration lengths in agile methodologies. Method Length Notes Source
XP 1-3 weeks (Beck 1999)
Scrum 1-4 weeks 30 days
Sprints (Rising and Janoff 2000)
Schwaber 2000 FDD 2 weeks DBF/BBF iterations (Coad et al. 1999) DSDM 2-6 weeks Timeboxes (Stapleton 1997) ASD 1-2 months (originally 4-8 weeks)
For small projects (<5000 function points)
(Highsmith 2000b)
Crystal 1-3 months Sometime needs to be reduced to 2 weeks, or extended to 4 months.
(Cockburn 2001)
S & S 2-4 months Milestone releases (Cusumano and Selby 1995)
From the project manager’s view, agile projects resemble more likely chaos instead of control within the iterations. This is mostly because the team members have to be empowered for making
many, also critical, decisions. In fast-paced agile software projects there is constant change and many corrective actions to be taken. Most of these are quite small and should be done quickly. There is usually no time for traditional change control procedures, such as using change control boards or management reviews.
Some methodologies have special approaches for doing corrective actions. Scrum methodology hast two project control mechanisms that are not discussed in other methodologies. First one is the usage of risk as the primary control; risks are constantly assessed and the assessment can affect greatly the other controls (Schwaber 1995). The other unique control is the regular assessment of issues and problems in the Scrum meetings (Schwaber 1995). In Extreme Programming the role of the on-site
customer is often emphasized when talking about problem solving. The critical decisions should be left to the customer (Wake 2000). Some methods, such as ASD, Crystal Clear and Scrum recommend having regular reviews or workshops for improving the product and the methodology (Highsmith and Cockburn 2001; Schwaber 2000). These feedback sessions can be very effective sources for corrective actions.
Contrast to the waterfall model
In this section I discuss how the control aspects of agile methodologies relate to traditional waterfall software development model. The word waterfall is used in a way it is normally understood: requirements, design, implementation and testing phases done sequentially. The original waterfall model presented by Royce (1970) had also a prototyping round (called simulation in his model) which should be done when a program is new and being developed for the first time. Royce’s model has been widely misunderstood as forbidding prototyping and therefore the prototyping round is neither included in the waterfall model used in this paper.
The two models are compared in table 4 in the next page. Some issues in the table are adapted from (Cusumano and Selby 1995, p. 407; Highsmith and Cockburn 2001).
Table 4. Comparison of waterfall and agile development styles. Issue Waterfall model Agile methodologies Development
phasing
Requirements, design, implementation and testing Implementing and delivering whole product together
Iterative and incremental development, each iteration includes all functions
Completing features in small increments, first delivery as early as possible
Planning Detailed planning for the whole project
Defining and allocating tasks All product functionality is planned
Planning iteratively along the way Defining and allocating functionality Prioritizing product functionality along the way
Measuring and evaluating
Integrating and testing once, late in the process
Getting feedback in the
beginning and end of the project
Integrating often with small increments and testing continuously with frequent builds Getting frequent feedback with iterative development and customer collaboration Correcting Responsibility of management
Returning to earlier phase Eliminating variations from processes, avoiding change Formal change control procedures
Responsibility of the whole team
Reprioritizing work for the next iteration Adapting processes to change, embracing change
Dynamic Prioritization
To summarize the project control differences, it can be said that in agile projects there is little planning and continuous adaptation to change. Small corrective actions are needed constantly and these are mostly handled by empowering team members. Iterative and incremental development provide means to do bigger change control. In waterfall development, there is a lot of planning done and lot of effort is used for keeping the development going along the plans. Deviations from plans lead to a lot of extra work and are therefore to be avoided as much as possible. In waterfall development, at least in principle, there is lot less corrective actions to be taken, but when they are
needed they are usually critical issues to be handled by managers and rigorous change control processes.
Strengths and weaknesses in managing agile projects
Iteration length is a critical issue in agile methodologies, but unfortunately not all problems can be split into suitable sized pieces (Constantine 2001). If iterations are too short, there is too much overhead work in doing the iterations, but on the other hand, if the iterations are too long, a lot of effort could be spent before finding the chosen direction to be wrong (Sotirowski 2001). With right-sized iterations agile projects can be highly effective and efficient in producing high quality software fast.
There are many plan-driven organizations, where much bureaucracy is needed in order to get a project authorized and going. In these kinds of environments the efficiency of agile methods gets lost and therefore small projects these types of organizations might be better of with plan-driven methods. (Boehm 2002)
Agile methods do not really scale up with the size of projects. Upper limits of 12 to 15 people have been suggested in order to be able to manage the tightly coordinated team effort. (Highsmith and Cockburn 2001; Constantine 2001)
Project management of agile projects can be especially complex and hard and the project managers need to be very skilled. Without competent management the overlapping responsibilities of agile projects can lead to confusion and wasted effort, too much reinvention or trial and error. (Cusumano and Selby 1995; Constantine 2001)
If requirements are somewhat predictable, underemphasizing the importance of the underlying product architecture can lead to ineffective development. If requirements are highly volatile, a lot of
refactoring needs to done. If there are not enough skilled developers, they might not be able to keep the product architecture up to needed changes. (Boehm 2002; Cusumano and Selby 1995)
Summary and Conclusions
Summary
Agile software development is nothing new. It has come a long way from the first writings of iterative development in the seventies to the introduction of the Agile Manifesto. The principles and especially several different lightweight methodologies have recently gained much more popularity after the Agile Alliance was formed.
A fundamental difference from traditional software projects is that agile software projects are not plan-driven and require different kind of management. Agile projects are usually done in changing environments and the way to react to change is usually to control the scope of the project. The traditional waterfall model and agile methodologies differ mostly in that waterfall development is plan-driven and agile development can be thought of a as change-driven.
Controlling a software project is done through planning, measuring, evaluating and correcting. The planning in agile software development is done iteratively along the iterations of usually fixed length. Only the current or the following timebox is planned more thoroughly and the rest of the plans are mostly vague ideas without much energy put into planning them. Agile methodologies give guidance mostly to monitoring the completed functionality and some quality factors. Frequent testing and integration are means to get feedback early in the process. Other aspects of project monitoring are left up to project managers. The empowerment of individuals makes possible the numerous corrective control actions needed due to the change. In the bigger scale the most usual control mechanism is reprioritizing features in different releases.
Agile methodologies have obviously substantial strengths when they are carried out in a suitable project environment. Agile methods have also weaknesses though, such as requiring highly skilled developers and project managers, projects have to be quite small and tackled problems must be able to be split into iterations of suitable length.
Conclusions
The agile software development methodologies differ greatly in comprehensiveness, required discipline and in the level of abstraction. The more generic methods have to be complemented with other models or practices, especially in the area of project management.
Project management of agile software development is a different role than project management of traditional waterfall software development. Agile projects are primarily controlled by adjusting the scope of upcoming iterations. Within the iterations, very little controlling can be done.
Areas for future research
This paper gives an overview on how to control agile software development. There are three special topics that are very close to the subject but have not been discussed in this paper: project reporting to outside parties, division of responsibilities and the human aspect of project control: tracking and management of project resources.
In addition, there are many aspects of this paper, for which an empirical study would probably turn out to be highly useful.
Assessment of the study
There is still quite a limited amount of published literature about agile methodologies. Several essential books were available for the study as well as the articles of the widely known and respected organizations of IEEE and ACM. Therefore the reviewed list of literature was quite
comprehensive. It should be noted though, that only commonly available published material was used, as some of the subject material is only available commercially.
Defining the decision-making processes and responsibilities of different roles would have probably been valuable addition for the discussion of the subject, but as said in the scope definition, they are too large topics to be discussed in this paper.
The resulting statements are understandable and useful. The comparisons and analysis were done according to the objectives.
Glossary and terms
Adaptive Software Development: An approach for doing high-speed and high-change software projects, developed by James A. Highsmith III.
Agile: A term named by the Agile Alliance for the light software development methodologies that are very responsive to change.
Agile Alliance: Originally a group of 17 methodologists, who met in February 2001 to share their ideas about light methodologies. Now it is the name of a non-profit organization, whose purpose is to promote the same ideas.
Agile Manifesto: A statement of four principles of software development presented by the Agile Alliance.
ASD: See: Adaptive Software Development.
Backlog: See also: Scrum: A prioritized list of features, other requirements and issues used in the Scrum methodology.
BBF (Build by Feature): Programming and inspection phase in the Feature-Driven Development.
Coach: An Extreme Programming role, whose task is to make sure that the practices of the methodology are understood and followed.
CRC: The words stand for class, responsibilities and collaboration. CRC cards are an informal modeling approach for object oriented designs.
Crystal Methodologies: A set of different methodologies developed by Alistair Cockburn. It includes different methodologies for projects of different size and criticality.
DBF (Design By Feature): Design phase of the Feature-Driven development. DSDM: See: Dynamic System Development Model.
Dynamic System Development Model: An agile software development methodology developed by the DSDM consortium.
Extreme Programming: A disciplined agile software development methodology which
emphasizes customer satisfaction and team work. It values simplicity, communication, feedback, and courage.
FDD: See: Feature-Driven Development.
Feature-Driven Development: A model-driven process for agile software development. Increment: A cycle in which more functionality is added to software.
Incremental software development: Developing software in small cycles and incrementing functionality in each cycle.
Iteration: A cycle in which existing software is improved.
Iterative software development: Developing software in small cycles and improving existing software each cycle.
Lean Programming: An agile programming methodology based on teamwork, customer feedback and continual reintegration.
Manager: A role in Extreme Programming.
Method: A systematic way technique, or process for doing something, usually used as a synonym for a methodology in software engineering.
Methodology: A series of related methods, techniques or procedures in a particular field. Milestone: A synonym for an iteration used by Microsoft in its Synch-and-Stabilize process.
MoSCoW: An acronym for a rule in DSDM for prioritizing software functionality into categories of Must haves, Should haves, Could haves and Won’t haves.
Pragmatic Programming: A set of agile programming practices that will make developers more accurate, productive and happier.
Rational Unified Process: An instantiation of the Unified Process by Rational Software Corporation. It is a web-based set of software engineering best practices.
Rigorous (opposite of agile): Traditional software development, where development is done in sequential phases of design, programming and testing.
RUP: See: Rational Unified Process.
S & S: See: Synch-and-stabilize. An abbreviation of the Synch-and-Stabilize development process Scrum: An agile software development methodology.
Sprint: A name for an iteration in Scrum methodology.
Synch-and-Stabilize: Software development process used by Microsoft. The main aspects are daily builds and several development sub cycles, called milestones.
Timebox: A name for an iteration in DSDM. Tracker: A role in Extreme Programming.
UP: See: Unified Process. A set of software engineering processes. Unified Process: A software development methodology.
References
Abran, A.; Moore, J. W. (Ed.). 2001. SWEBOK: Guide to the Software Engineering Body of Knowledge. [online]. Trial version 0.95. Software Engineering Coordinating Committee, IEEE Computer Society. May 2001. [cited 5 March 2002]. Available from:
http://www.swebok.org/documents/stoneman095/Trial_Version_0_95.pdf.
Scrum Frequently Asked Questions. [online] Advanced Development Methods, Inc. [cited 10 February 2002]. Available from: http://www.controlchaos.com/faq.htm
Agile Alliance. The Agile Alliance. [online]. [cited 20 March 2002]. Available from: http://www.agilealliance.com/home.
Ambler, S. W. 2002. Agile Modeling (AM) Home Page. [online]. [cited 24 March 2002] The Scope of Agile Modeling (AM)?. Available from: http://www.agilemodeling.com/.
Basili, V. R.; Rombach, H. D. 1988. The TAME Project: Towards Improvement-Oriented Software Environments. IEEE Transactions on Software Engineering. Vol. 14, No. 6. June 1988. pp. 758-773 ISSN 0098-5589.
Beck, K. et al. 2001. Manifesto for Agile Software Development. [online]. [cited 20 March 2002]. Available from: http://www.agilemanifesto.org/.
Beck, K. 1999. Embracing Change with Extreme Programming. IEEE Computer. Vol. 32, No. 10. October 1999. pp. 70-77. ISSN 0018-9162.
Boehm, B. 1988. A spiral model of software development and enhancement. IEEE Computer. Vol. 21, No. 5. May 1988. pp. 61-72. ISSN 0018-9162.
Boehm, B. 2002. Get Ready for Agile Methods, with Care. IEEE Computer. Vol. 35, No. 1. January 2002. pp. 64-69. ISSN 0018-9162.
Brooks, F. P. 1987. No Silver Bullet: Essence and Accidents of Software Engineering. IEEE Computer. Vol. 20, No. 4. April 1987. pp. 10-19. ISSN 0018-9162. First published in Information Processing ’86. Kugler, H. J. (Ed.). Elsevier Science Publisher B.V. Holland. ISBN 0-444-70077-3. Coad, P., Lefebvre, E., and De Luca, J. 1999. Java Modeling in Color with UML: Enterprise
0-13-011510-X. [cited 7 February 2002]. Chapter 6. Feature-Driven Development. Available from: http://www.togethersoft.com/files/services/jmcu/chapter6.pdf.
Cockburn, A. 2001. Agile Software Development. Draft 3b. [online]. Addison-Wesley. 256 p. ISBN 0-201-69969-9. [cited 15 January 2002]. Available from:
http://members.aol.com/humansandt/crystal/game/agile3bpdf.zip.
Cockburn, A.; Highsmith, J. 2001. Agile Software Development: The People Factor. IEEE Computer. Vol. 34, No. 9. November 2001. pp. 131-133. ISSN 0018-9162.
Constantine, L. 2001. Methodological Agility. [online]. Software Development. June 2001. [cited 3 April 2002]. Available from: http://www.sdmagazine.com/documents/s=730/sdm0106f/0106f.htm Cusumano, M. A.; Selby R. W. 1995. Microsoft Secrets: How the World's Most Powerful Software Company Creates Technology, Shapes Markets, and Manages People. New York, NY. The Free Press. 512 p. ISBN 0-02 874048-3.
Duncan, William R. (Ed.). 1996. A guide to the Project Management Body of Knowledge. Upper Darby, PA. Project Management Institute. 176 p. ISBN 1-880410-12-5.
Fenton, N. E.; Neil M. 2000. Software Metrics: Roadmap. 'The Future of Software Engineering. Anthony Finkelstein (Ed.). 22nd International Conference on Software Engineering, ACM Press. pp. 357-370. ISBN 1-58113-253-0.
Fenton, N. E.; Pfleeger, S. L. 1997. Software Metrics: A Rigorous & Practical Approach. 2nd edition. Boston, MA. ITP. 638 p. ISBN 0-534-95425-1.
Fowler, M. 2001. The New Methodology. [online]. [cited 10 February 2002]. Available from: http://www.martinfowler.com/articles/newMethodology.html.
Gilb, T. 1988. Principles of Software Engineering Management, Addison-Wesley
Grady, R. B. 1992. Practical Software Metrics for Project Management and Process Improvement. Eaglewood Cliffs, NJ. Prentice Hall. 270 p. ISBN 0-13-720384-5.
Highsmith, J. 2000a. Adaptive Software Development: A Collaborative Approach To Managing Complex Systems. New York, NY. Dorset House Publishing. 358 p. ISBN 0-932633-40-4.
Highsmith, J. 2000b. Retiring Lifecycle Dinosaurs: Using Adaptive Software Development to meet the challenges of a high-speed, high-change environment. Software Testing & Quality Engineering. [online]. Vol. 3. July/August 2000. [cited 22 February 2002]. Available from:
http://www.jimhighsmith.com/articles/Dinosaurs.pdf.
Highsmith, J.; Cockburn, A. 2001. Agile Software Development: The Business of Innovation. IEEE Computer. Vol. 34, No. 9. September 2001. pp. 120-122. ISSN 0018-9162.
Hunt, A.; Thomas, D. (Ed.). 2002. Ubiquitous Automation. IEEE Software. Vol. 17, No. 4. January/February 2002. pp. 11-13. ISSN 0740-7459.
Hunt, A..; Thomas, D. 2000. The Pragmatic Programmer: From Journeyman to Master. Reading, MA. Addison-Wesley. 321 p. ISBN 0-201-61622-X.
Kerzner, H. 1998. Project management : a systems approach to planning, scheduling and controlling. 6th edition. New York, NY. Jown Wiley & Sons. 1180 p. ISBN 0-471-28835-7. Martin, J. 1991. Rapid Application Development. MacMillan Publishing, New York, NY. ISBN 0-02-376775-8.
Mills, H. D. 1971. Top-Down Programming in Large Systems. Debugging techniques in large systems: Courant Computer Science Symposium 1, June 29 - July 1, 1970. Rustin, R. (Ed.). Englewood Cliffs, NJ. Prentice-Hall. 1971. 148 p. ISBN: 0-13-197319-3
Patel, M. B.; Morris, P. G. W. 1999. CRMP Guide to the Project Management Body of Knowledge. Manchester, UK. Centre for Research in the Management of Projects. 74 p. ISBN 1-880410-12-5. Poppendieck, M. 2001. Lean Programming. [online]. Software Development. May 2001 and June 2001. [cited 24 March 2002]. Available from:
http://www.sdmagazine.com/documents/s=731/sdm0105e/0105e.htm.
Raymond, E. S. 2000. The Cathedral and the Bazaar . [online]. Last updated 24 August 2000. [cited 24 March 2002]. Available from: http://tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/.
Rising, L.; Janoff, N. S. 2000. The Scrum Software Development Process for Small Teams. IEEE Software. Vol. 17, No. 4. July/August 2000. pp. 26-32. ISSN 0740-7459.
Royce, W. W. 1970. Managing the Development of Large Software Systems. IEEE WESTCON. August 1970. TRW. p. 1-9. Reprinted in the Proceedings of the 9th International Conference on Software Engineering. March 30-April 2, 1987. Monterey, CA. IEEE Computer Society Press, Los Alamitos, CA. ISBN 0-89791-216-0.
Schwaber, K. 1995. The Scrum Development Process. [online]. In OOPSLA'95 Workshop on Business Object Design and Implementation. [cited 25 February 2002]. Available from: http://www.controlchaos.com/scrumwp.htm.
Schwaber, K. 2000. Against a Sea of Troubles: Scrum Software Development. Cutter IT Journal. November 2000. Vol. 13, No. 11. pp 34-39. ISSN 1048-5600.
Stapleton, J. 1997. DSDM – Dynamic Systems Development Method: The Method in Practice. Harlow, England. Addison-Wesley. 163 p. ISBN 0-201-17889-3.
Sotirovski, D. 2001 Heuristics for Iterative Software Development. IEEE Software. Vol 18, No. 3. May/june 2001. pp. 66 – 73. ISSN 0740-7459.
Wake, W.C. 2000. Managing XP: Manager, Tracker and Coach. [online]. XPlorations. July 2000. [cited 8 April 2002]. Available from: http://www.xp123.com/xplor/xp0007/index.shtml.
