Dealing with an increasingly volatile organizational environment is a serious challenge for managers of any software development project . Traditional formal software development methodologies can be characterized as reflecting linear, sequential processes, and the related management approaches can be effective in developing software with stable, known, consistent requirements. Yet most real-world development efforts are much more likely to be conducted in more volatile environments, as organizations adapt to changing technology, markets, and social conditions. Requirements for systems must be able to change right along with them, often at "Internet speed" . Even seemingly minor changes can produce unanticipated effects, as systems become more complex and their components more interdependent. Project management approaches based on the traditional linear development methodologies are mismatched with such dynamic systems.
Observing this tendency for software requirements to change, Meir Lehman, writing in , suggested that their underlying processes can be characterized as "multi-level, multi-loop, multi-agent feedback systems." Software developers have long responded to this complexity with iterative, often ad-hoc approaches. More recently, a host of "agile" development methodologies, including eXtreme Programming (XP) , Crystal, Scrum, Adaptive Software Development, Dynamic Systems Development Method, and Feature-Driven Development, have sought to focus on rapid iterative delivery, flexibility, and working code .
In our experience, project managers invariably fall back on the traditional linear approaches, seeking to reign in the increasing volatility of their projects. This can be true even when they use agile methodologies. These efforts can lead to "stable systems drag"  in which organizations try to respond simultaneously to both changing environmental conditions and to their own increasingly obsolete legacy systems.
The agile manager understands the effects of the mutual interactions among a project's various parts and steers them in the direction of continuous learning and adaptation.
Projects that employ agile methodologies are complex adaptive systems (CAS) , as discussed in the sidebar. We have evolved a CAS-based Agile Project Management (APM) framework, aiming to leverage XP to steer projects to success in terms of being on schedule and within budget while satisfying their customers. The APM framework prescribes the six practices for managing agile development projects discussed here:
Organic teams of from seven to nine members. Self-organization and emergent order are due in part to complex interactions or flows among agents. Organizing a project into organic teams implies a minor interaction penalty in terms of communication and coordination overhead . Allowing members to join and leave the team allows dynamic team composition and supports adaptability to changing external conditions. The team  maintains optimal internal channels of communication while minimizing the effect of an interaction penalty. Even when a project requires a larger team of, say, more than 15 members, it can still be organized into several smaller, organic subteams working in parallel. The agile manager is responsible for establishing clear roles and responsibilities to ensure proper team alignment and accountability.
Guiding vision. CAS agents help anticipate and adapt to changing conditions. A project vision translated into a simple statement of project purpose and communicated to all team members has a powerful effect on individual member behavior. In the U.S. Army, an example of this principle is "commander's intent." The Army knows its leaders are not omnipresent; the commander's intent is employed as a guide for soldiers' individual initiatives, actions, and decisions. Even if a mission falls on the shoulders of the lowest-ranking person, that person is still able to carry out the mission. Likewise, agile managers guide their teams by defining, disseminating, and sustaining a vision that influences the internal models of individual agents. The Agile Manifesto (www.agilemanifesto.org) created in 2001 by the proponents of these methodologies articulated a core set of values useful in steering this vision.
Simple rules. In CAS, agents follow simple rules, but their interactions result in complex behavior that emerges over time. The standard XP practices represent a set of simple rules for agile development projects. They're accepted by all members of the team at the outset, though the team can adjust or add new practices as needed. Throughout a project, the manager identifies practices that aren't being followed, seeks to understand why they're not, and removes obstacles to their implementation. XP practices provide simple generative rules without restricting the autonomy and creativity of team members.
Free and open access to information. In CAS, information about plans, progress, objectives, and organization is the catalyst for adaptation by each member of a project team. The richness of the interaction among team members depends largely on their openness to the exchange of information. For an agile team to adapt, information must be open and free-flowing. In the APM world, information flows freely and team members benefit from the power of knowledge no matter what its source.
Light touch management style. With traditional approaches, everything is viewed through the prism of controlof change, risk, and, most important, people. Elaborate methodologies, tools, and practices have evolved to manage an out-of-control world. But tools fail when neat linear tasks don't easily accommodate dynamic processes and when neat schedules require frequent updating to reflect changing circumstances.
Imposing more and more control, managers may forget their own original purposecreating order. In such cases, they may come to believe that more control leads to more order. Unfortunately, this view doesn't account for the uncertainties inherent in the real world. Skilled professionals don't adapt well to micromanagement, and tools and techniques quickly reach their limits when not used appropriately. Managers realize that increased control doesn't yield increased order, accepting their own inability to know everything in advance while relinquishing some control to achieve greater order.
Adaptive leadership. An agile project team balances on the edge of chaosa concept from complexity theory. Systems with too much structure are too rigid, while systems without enough structure spiral into chaos. Leading a team by nurturing small organic teams, establishing a guiding vision, establishing simple rules, championing open information exchange, and managing with a light touch is challenging enough. There's also the risk of a team veering into chaos. Nonlinear behavior can be either positive or negative in a project context, and controls placed on the system by well-intended managers can produce unintended outcomes.
Adaptive leadership employs "systems thinking" to understand a project's internal forces. For example, events are understood in terms of their patterns, or the common elements that recur in diverse circumstances. Systems archetypes reflecting common types of problems help identify the unintended and counterintuitive consequences of actions when cause and effect aren't closely related in time and space. The agile manager understands the effects of the mutual interactions among a project's various parts and steers them in the direction of continuous learning and adaptation. An adaptive APM-based framework includes several practices:
Following them helps make managers adaptive leaders, setting direction, establishing simple rules for the system, and encouraging constant feedback, adaptation, and collaboration.
In 2002, as part of an eight-member advisory implementation team in a Fortune 50 financial services company, two of the authors (Augustine and Payne) led the recovery and stabilization of a large mission-critical product-development project involving a team of more than 120 IT and services professionals in multiple locations. Though the project began with a skilled team and clear mandate, project-delivery challenges emerged from the complexity of such a large team in what was for the organization a critical business endeavor. At the time we were consulted, the project was already several months behind schedule, along with frustrated customers and dispirited developers.
To resuscitate the project, we implemented XP nested within APM. We organized six development teams by general business functionality and used a SWAT team (concept from the Crystal Orange methodology ) to integrate code across teams at iteration end. To accommodate legacy code without extensive unit tests, we maintained a separate quality assurance (QA) team. We used APM practices to manage and coordinate all the teams. Following combined release planning, we conducted individual release planning for each of them. We initiated two-week iterations of software delivery, devoting the first to retrofitting unit tests for major sections of legacy code. At iteration end, the QA team and the SWAT team together integrated code and fixed minor defects. Users then conducted acceptance testing, while the QA team performed more rigorous manual testing.
A lack of shared understanding of the project's goals was a major issue in terms of delivering customer value. We thus established a guiding vision to serve as an internal model for all project team members, entrusting the task to a newly created project office (PO) that included all 15 of the company's business and technical project managers. It conducted release planning and translated an existing release document into an XP release plan representing the major requirements for each release iteration and embodying the specifics of the guiding vision. The PO presented it at iteration planning meetings, as well as at the daily standup meeting, reviewing it weekly to accommodate changes.
We replaced the existing project-delivery process, establishing the XP practices and values as simple rules for all 120 team members. We then initiated overall XP training, followed by intensive breakout training sessions tailored to each subgroup. To overcome the team's collective inertia, we began two-week iterations within a few days of completing the training. We then placed XP process mentors on each team to inculcate XP values and bolster our application of XP. We also held several bootstrap training sessions to reinforce XP practices.
Before beginning our work on the project, information was restricted to a select few senior managers. Our aim was to make information available to all. That's why we did the following:
Before we arrived, managers responded to schedule slippage and frustrated customers by micromanaging developers. Schedule pressure dictated long hours. This and hasty integration periods contributed to low-quality code. We thus negotiated (with the company's senior management) a delicate balance, so developers would no longer be required to work sustained overtime. Many managers took on a new style; instead of creating, allocating, and micromanaging tasks, they gave their individual team members greater autonomy to determine which tasks had to be done while demanding demonstrable results at the end of each iteration. To keep the project on schedule and budget, they also had to do the following:
Along with the PO, other useful innovations included:
Some team managers also had to deal with a number of difficulties:
Our previous experience managing projects taught us the difference between the assumptions of APM and the assumptions of traditional project management. By viewing an agile project as a CAS and adopting a leadership-collaboration model, we were able to develop a management framework with practices encapsulating agile methodologies (such as XP). Using the framework and scaling XP, we could thus lead the recovery and stabilization of a large mission-critical, product-development project, steering it to completion in five months in terms of schedule, budget, customer satisfaction, and business value.
1. Abrahamsson, P., Warsta, J., Siponen, M., and Ronkainen, J. New directions in agile methods: Comparative analysis. In Proceedings of the 25th International Conference on Software Engineering (May 310, 2003), 244254.
©2005 ACM 0001-0782/05/1200 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2005 ACM, Inc.
No entries found