The adoption of agile concepts, principles, and approaches in many sectors is rapidly transforming project management practice. Crucially, agile methods focus on managing -- and speeding up -- development activities and can therefore offer new ideas and significant improvements for project-management-in-the-small.
The aim of this article is to reflect on the impact that agile methods are likely to have on project management practice. Agile methods challenge some of the basic assumptions embedded in sound project management, and while they overcome some limitations, they introduce new constraints and ways of thinking. Their adoption requires intelligent adjustments to the way projects are perceived, prioritized, and managed.
AGILITY IS EVERYWHERE
Agile software development emerged in response to widespread dissatisfaction with sequential approaches to developing software. Much like prototyping before it, agile development embraced the ideas of greater interest in users, capturing true requirements, and rapid delivery of working versions of the agreed content. While agile methods adopted the creative ideas of prototyping, they also placed a greater emphasis on controlling development through the use of timeboxing, thus offering a more structured framework for delivery.
Agile normally means nimble, quick-moving, or active. Agile methods aim to use such qualities in order to prosper in an environment of constant and unpredictable change. They integrate established software development practices and principles into organized approaches for responsive development that emphasize collaboration and communication. Short delivery cycles enable developers to respond more easily to changing demands from clients and a shifting marketplace and environment. Agile development is typified by adaptive software built by small teams that focus on rapid feedback and continuous improvement.
Agile methods boast an ever-growing influence. Such methods, and the principles they embody, have played a key part in shaping research and practice in software development and engineering, bringing many new topics to the forefront. Moreover, the improved IT project success rate -- with more IT projects delivered on time, on budget, and within requirements -- is being attributed in part to the increased adoption of agile methods.
Meanwhile, the "agile movement" has spawned new terms, such as sprints, scrums, velocity, epics, sagas, user stories, huddles, and daily stand-up meetings, which have become part of the accepted software development jargon. The Agile Conference is probably the best-attended conference in software development and continues to grow in popularity. Many new conferences and communities have formed to discuss agile ideas, and tracks in established conferences also highlight agile concepts. And this explosion of interest in all things agile has extended beyond IT. Bookshelves in bookstores hold many new titles focusing on agile investors, agile competitors, agile organizations, agile systems and enterprises, agile genes, and even the agile library.
Not surprisingly, the improved success rates in agile IT project delivery have also sparked an interest amongst a project management community looking to improve its own practices. Many of the ideas and emphases fostered in agile methods, such as value, benefit, relationships, feedback, and response to change, chime in with interests the project management community has explored. Given the shared focus on projects and project delivery, it is easy to see why importing new agile ideas into project management seems so attractive. However, it is worth noting that there is a difference between agile as a development method and agile as a project management method. This is not clear in many of the discussions of agile software development.
THE EXPERIMENT
Anecdotal evidence suggests that the use of agile methods will translate into increased productivity, quality, and stakeholder satisfaction. Products developed using agile methods are often reported to be more creative and to result in higher user satisfaction levels. To date, however, there have not been many direct comparisons made between the different approaches in terms of the quality, functionality, and scope of the resulting products. Nor is there much information regarding the impact of various methods on projects, their intermediary products, and the development teams. Among the few examples is a case study focusing on the effects of adopting XP at IBM and Sabre Airlines. That study indicated productivity improvements of 46%-70% in lines of code (LOC) per person-month.1
Intrigued by the overall lack of evidence, Professors Oddur Benediktsson and Helgi Thorbergsson and I decided to set up a comparative experiment involving 15 one-year IT projects, which were completed in parallel (albeit in an academic environment). The experiment was conducted at the University of Iceland in 2004. The comparable products to be developed were interactive packages centered on a database system for home or family usage with a Web-based user interface. Four of the project teams used the V-model, a variation on the traditional waterfall approach; four used incremental development; four applied an evolutionary approach; and three utilized XP, an agile method.
Our goal was to examine and compare resource utilization and efficiency in projects developed using sequential, incremental, evolutionary, and XP approaches. The experiment appears to be the largest comparative study conducted to date. While there were no measurable differences in quality, there were astonishing differences in terms of productivity and a matching increase in the satisfaction levels of clients. The greatest difference in productivity was between V-model teams and XP teams, with the XP teams being, on average, 337% more productive than the V-model teams.
THE RESULTS
The XP teams produced on average 3.5 times more LOC than those using the V-type model, 2.7 times more LOC than those using the incremental model, and 2.2 times more LOC than the evolutionary teams. This significant trend is also reflected in terms of the number of LOC produced in Java and in XML. Table 1 offers a size comparison between the results of the different groups. We can easily see that the XP teams developed the greatest number of lines. The increased code production by the XP teams also translated into a greater productivity rate over the course of the project (see Figure 1).
Table 1 -- Code Production in LOC
Figure 1 -- Monthly productivity in LOC/PM.
Figure 2 offers a size and effort comparison between the different groups. It is easy to see that the XP teams developed the greatest number of lines. The figure also offers a productivity clustering by method. Back in 1984, Barry Boehm, Terence Gray, and Thomas Seewaldt2 showed that with traditional development and with prototyping, development effort is generally proportional to the size of the developed product. They further asserted that this relationship will apply to most development methods. While this principle still appears to roughly apply to most groups in our experiment irrespective of the method they applied, two of the XP teams in our study achieved significantly greater productivity as measured by size in LOC. Another way of viewing this is to say that if we drew a line from the bottom left of Figure 2 to the bottom third on the right, all the methods with the exception of XP will cluster around it (as Boehm et al. initially predicted). In comparison with more traditional development approaches, then, XP appears to defy the relationship posited by Boehm and his colleagues.
Figure 2 -- Size as a function of effort.
Figure 3 -- The project management triangle in traditional and agile projects.
So the case for the adoption of agile methods is powerful. In addition to increased productivity, the use of agile methods in our experiment resulted in increased acceptance of the delivered product as well as other business benefits with the potential to improve the bottom line. Given the same amount of time, XP teams were able to build on the feedback from small and frequent releases and produce a medium-sized product (compared to the smaller products delivered by the other teams). Significantly, of all the systems delivered in the experiment, users viewed the XP-developed products as the most comprehensive solutions and the most satisfactory products. It seems that involving the users and delivering on a more regular basis yielded products that were not only larger, but also more significant in terms of functionality.
THE IMPACT OF AGILE PROJECT MANAGEMENT (OR, CAN WE GET RID OF TRADITIONAL PROJECT MANAGEMENT?)
Agile development uses well-established principles and effective methods to deliver value more rapidly through increments. It emphasizes the role of learning, feedback, and people in evolutionary cycles. The approach encourages team cohesion and emergence and fosters commitment and knowledge sharing. Agile projects take dedicated project teams and focus on short-term delivery in which nonessential activities are stripped away from the process, thus resulting in improved productivity.
Agile development offers a powerful tool for microplanning, controlling increments, and showing progress. In essence, agile methods organize technical development by dividing it into microprojects. This enables teams to measure their progress closely, thus providing unparalleled visibility. Frequent delivery cycles also offer improved control over the entire effort. In situations where the deadline and the available resource level are fixed, the use of multiple increments gives project managers significant leverage.3 In such cases, greater productivity gains and enhanced flexibility will result from organizing the development effort into short, frequent increments, as we saw in our experiment. All 15 teams had the same overall time boundary and resource level, yet the XP teams delivered larger products, thereby displaying a significant increase in productivity.
Complex project environments with high rates of change are ideal for the employment of rapid increments embedded within agile methods.4 But the true focus in agile methods is on the technical tasks and their organization and not on the project per se. In traditional project management, projects have a clear beginning and a definite end. Agile methods, on the other hand, are designed to help teams demonstrate business value more quickly and more often. Therefore, agile development has a more continuous sense and may extend beyond more conventional projects. Agile increments continue to bunch together segments of functionality, and project work thus becomes an ongoing operation, a service that can continue to deliver. The continuous nature of change in a turbulent environment opens up opportunities, whilst also introducing new challenges.
A TYPICAL AGILE FAILURE STORY?
One of my research interests involves the collection of failure stories. Over the last 20 years, I have collected stories of hundreds of IT project failures. While the bulk of these relate to traditional approaches, I am now seeing a growing number of agile failure stories. Many of them have certain common features that were not typical of more "traditional" failures. In fact a new kind of project failure may have been made possible by the ways agile methods are defined and applied -- a project in which each increment is a success but the overall project is a flop. The ultimate failure often results from a missing key system, proving that value accumulation is not always an adequate replacement for overall project coordination.
In the case I will discuss, the Candy Corporation (CC)5 wanted to develop a state-of-the-art Web interface to showcase its candy. In a highly competitive environment, with the potential for international competition, senior management decided that the Web display was essential to capturing -- possibly even cornering -- the market. As the project involved a new concept in this sector, management agreed to adopt an agile approach and involve a wide range of stakeholders in order to ensure the integrated system satisfied all concerned parties. Agile development was selected so that changes could be incorporated more easily and business value demonstrated more efficiently. The new system was to be implemented by Halloween a year hence.
As the teams focused on each current development cycle, more users were brought into the process and many novel features were incorporated in the Web display. Thus, the new system kept growing and improving, with each new increment adding value and offering a more impressive system. Six weeks before Halloween, a visiting senior manager was being shown the almost complete Web-ordering interface. When he asked about the volume of orders, it quickly emerged that no one had built the capability to fulfill orders into the system. While each project increment had delivered business value, the final system was missing the key component needed for business operation.
Without the ability to harvest orders, CC tried to survive Halloween but ultimately folded within six months. In this case, agile methods were adopted without a full understanding of the implications. This lack of understanding is made worse when the concept of a project is abandoned in favor of an ongoing operation that fails to define the key parameters. Some of the agile failures I have looked at occurred because project teams were concentrating on a single increment at a time while ignoring the overall picture. When projects are not viewed as complete undertakings, certain aspects can slide under the radar. The delivery of value in each increment means that content is optimized per delivery cycle. Unless sound methods are adopted, essential features and functions can be forgotten -- and sometimes it is too late to recover.
Agile practitioners have noted that, occasionally, customer involvement in work planning can lead to scope creep. Even prioritization by the business product owner is no guarantee that the entire project perspective has been accounted for. CC had a string of successful projects, each of which delivered benefits. But when they were all combined, they added up to ultimate business failure.
THE SHIFTING TRIANGLE
The missing aspect for CC was the complete project view. Agile project management requires a careful reassessment as projects are viewed in an entirely new way. The move to agile project management means that we need to consider the impact of this new approach on constraints and on how projects are prioritized.
Traditional project management is predicated on the idea of a project -- a distinct entity that must be completed. The vision of the project drives the tradeoffs between the constraints of time, cost, scope, and quality in order to ensure that a project delivers as intended. In many areas, a project manager may encounter the need to manage two lifecycle systems, one revolving around the technical tasks and a second concerned with the project activities. Agile development blurs the boundaries between the two, as it spans both domains. Agile methods feature timeboxing as a way of managing work elements. The focus on work content has led some project managers to view agile development, and the emerging ideas of agile project management, as the management of work packages or tasks.
The truth is that agile methods adopt a different perspective. Rather than focus on the management perspective and the project concept, agile methods are concerned with the work that can be completed over a given period of time with the already agreed resources. If we depict traditional management as a triangle in which the project idea drives decisions about resource levels and the timing available to deliver the project, agile development would turn the triangle on its head (see Figure 3). In agile projects, the time available is fixed by the size of the increment, or the timebox, and so is the size of the team. What needs to be determined is the content that will be delivered as part of that increment. This shift has the potential to transform project management as we know it.
Unlike the traditional view of project management, agile development is not necessarily concerned with having a defined project and delivering parts of that vision. Agile teams often operate within what I have termed a "fixed resource envelope" with fixed time and predetermined resource levels. This has a huge impact on how content is selected and agreed upon, as the traditional triangle of project management has shifted in emphasis. Agile projects use a variety of methods to allocate stories, backlogs, or requirements into these envelopes, thereby populating them with content, or work. Developers determine and rearrange the content of their envelope to ensure they deliver useful and productive functionality. Indeed the content is optimized internally by the team rather than on a project-wide basis. Given the brief timescale of increments, each agile project has a short-term concern for optimizing what may be delivered in that time. Organizations such as CC, which are used to focusing on a more traditional project vision, can be led astray by such "short-sightedness" and lured into pursuing a series of small incremental steps that lead to failure.
To reiterate, an essential difference between the two approaches is that traditional project management has developed around the delivery of projects, while agile development is concerned with delivering value. Project management has recently learned from program management that every project should deliver benefits to the organization. While the delivery of benefits is a key focus, project management is not used to dealing with the constant delivery of value that may or may not add up to an old-style project.
MAKING AGILE PROJECT MANAGEMENT WORK
Agile project management requires adjustments. Traditional project managers who try to manage streams of fixed resource envelopes face fundamental challenges. For example, traditional project management has developed two general approaches to scheduling. One assumes unlimited resources within a fixed project time frame, and the other assumes limited resources within a flexible project time frame. Agile project management requires a new mindset, as it assumes fixed resources and a fixed time frame, rendering both traditional scheduling approaches irrelevant. It also has the added bonus of avoiding the need for smoothing resource levels in the project, as resource size is a fixed commodity.
Agile development offers a new approach for dealing with change in turbulent environments. Many project managers are keen to understand and harness the potential of this approach. As agile projects replace traditionally managed projects, many project managers find themselves in unfamiliar territory outside the project team. In agile development, content is selected by autonomous teams. Teams create and monitor iteration plans, dividing the tasks and fitting them into timeboxes and iterations; customers prioritize features based on their perceived business value.
However, some of the failures reveal that there is still a need for a higher form of project management, not least for prioritizing across agile increments and looking at how work content is selected, allocated, and revised. The guiding vision embedded in traditional project management needs to be preserved and used to support decisions and perform tradeoffs. Project managers are trained to develop, control, and monitor plans to ensure the achievement of project objectives and the integrity of the project concept. They need to retain the overall view rather than get bogged down in detail.
Coexistence requires a middle ground, especially when both sides have so much to offer. Traditional project managers retain a helicopter view of the complete project. Agile managers offer insights into reducing uncertainty and dealing with inherent complexity through collaboration and rapid iterations. We can seize the middle ground by utilizing agile project management approaches, focusing on speeding up microproject increments, while also employing program management techniques to look after the overall project. Program management will enable the coordination of streams of projects to ensure the successful delivery of outcomes. The focus on outcomes and the delivery of benefits can mitigate against some of the new failures.
While agile methods cross the boundary between technical and project management, program management is ideally suited to sit alongside them, as it can comfortably deal with collections or clusters of smaller projects managed in a coordinated way. Programs operate in inherently ambiguous, uncertain, and less well-understood environments typified by change and turbulence. They also link with strategy achievement and entail an understanding of internal culture and politics, making them an ideal partner for agile projects.
In such a powerful arrangement, project-management-in-the-small can be done within autonomous agile teams. The vision and architecture can be maintained by technical and management experts who ensure the integrity of the overall concept of the project and oversee its decomposition, architectural design, and ultimate integration. Moving up a level will mean that project managers will become the new program managers, with a more strategic role and a new orientation that involves leading people rather than managing, and guiding rather than directing. Ultimately, they will also make sure that strategy materializes and is constantly served by rapidly executed change initiatives that deliver organizational benefits.
In an increasingly global environment, as we move toward smaller projects in a flatter society, we need to employ higher-level approaches to guarantee the value we deliver represents coherent and complete content. Our ability to continue to prosper in an environment of constant change will depend on the mastery of these techniques.
ENDNOTES
1 Layman, Lucas. "Empirical Investigation of the Impact of Extreme Programming Practices on Software Projects." Proceedings of OOPSLA'04. ACM Press, 2004.
2 Boehm, Barry W., Terence E. Gray, and Thomas Seewaldt. "Prototyping Versus Specifying: A Multiproject Experiment." IEEE Transactions on Software Engineering, Vol. 10, No. 3, May 1984, pp. 290-303.
3 Bendiktsson, O., and D. Dalcher. "Estimating Size in Incremental Software Development Projects." Software: IEE Proceedings, Vol. 152, No. 6, December 2005, pp. 253-259.
4 Bendiktsson and Dalcher. See 3.
5 To hide the identity of the organizations involved, the case presented is a composite of two such failures.
ABOUT THE AUTHOR
Darren Dalcher is Chair Professor of Software Project Management at Middlesex University (UK) and Visiting Professor in Computer Science at the University of Iceland. Dr. Dalcher is the founder and Director of the National Centre for Project Management, an interdisciplinary center of excellence operating in collaboration with industry, government, and the learned societies in the UK. He has been named one of the top 10 "movers and shapers" in project management by the Association for Project Management (APM) and voted Project Magazine's Academic of the Year for his contribution in "integrating and weaving academic work with practice."
Dr. Dalcher is active in numerous international committees, steering groups, and editorial boards. He is heavily involved in organizing international conferences and has delivered many keynote addresses and tutorials. He has written over 150 papers and book chapters on project management and software engineering. He is Editor-in-Chief of Software Process: Improvement and Practice and Editor of a major new book series from Gower Publishing, Advances in Project Management.
Dr. Dalcher is a Fellow of APM and the British Computer Society, as well as a member of the Project Management Institute (PMI), the Academy of Management, IEEE, and the ACM. He is a member of the APM Professional Development Board and the PMI Advisory Board that is responsible for the prestigious David I. Cleland project management award. Dr. Dalcher can be reached at D.Dalcher@mdx.ac.uk.
In this issue of Cutter IT Journal , we discuss the complex issues surrounding project management in the new global environment. Discover how one IT executive is overcoming her PMO's "midlife crisis" by shifting its focus from project execution and metrics to portfolio oversight and business relationship management. Learn how your projects can reduce their "Feature-Time-to-Benefit" through a combination of lean, agile, and Toyota Production System (TPS)-inspired techniques. And hear from one author who relates "a typical agile failure story" and argues that we need to go beyond agile project management to ensure that the value project teams deliver represents coherent and complete content. Be sure to tune in - the project you save may be your own!.