Alistair Cockburn
(pronounced "Coburn", the Scottish way )

Agile Software Development 2: The People Factor

Alistair Cockburn, Humans and Technology
Jim Highsmith, Cutter Consortium

Agile development focuses on the talents and skills of individuals, molding the process to specific people and teams.

In the first part of this article (see IEEE Computer Sept 2001), we introduced agile software development through the problem it addresses and the way in which way in which it addresses the problem. In this second part, we describe the effects of working in an agile style.

What is being called agile software development is a development approach that primarily addresses the problems of rapid change: changes in market forces, systems requirements, implementation technology and project staff occuring within a single project's development period. As the rate of such changes increased over recent decades, a different development style showed advantages over the traditional in handling the ongoing, late-breaking changes. This is the style being called agile.

A dominant idea in agile development is that the software team can be more effective in responding to change if it can:

To reduce the cost of moving information between people, the agile team works to

To reduce the time from decision to feedback, the agile team

By making user experts available to the team, the developers get rapid feedback on the implications to the user of their design choices. The user experts, seeing the growing software in its earliest stages, learn both what the developers misunderstood, and also which of their requests do not work as well in practice as they had thought.

The term agile, coined by a group of people experienced in developing software this way, has two distinct connotations.

The first connotation of the term agile is the idea that the business and technology worlds have become turbulent, high speed, and uncertain, requiring a process to both create change and respond rapidly to change.

The second connotation is implied by the first: An agile process requires agile people and organizations. Agile development focuses on the talents and skills of individuals and molds process to specific people and teams, not the other way around.

Agile is for People

The largest single implication to managers working in the agile manner is that much more emphasis is placed on people factors in the project: amicability, talent, skill, and communication.

Amicability, morale, community and the quality of communication become first-rate items of concern for the would-be agile team. Skill development is important, so that each person becomes able to deliver more value with time.

The attention to the human issues gives agile projects a particular feel. It is not simply a matter of reducing paperwork and hoping that everything else will fall into place. To paraphrase one developer, "A small, rigorous methodology may look the same as an agile methodology, but it won't feel the same."

The concept of the agile group grows to span teams, organizations and other working relationships. It is very difficult for agile people to function well in a rigid organization—and visa versa.

Individual Competence

Agile development teams focus on individual competency as a critical factor to project success.

If the people on the project are good enough, they can use almost any process and accomplish their assignment. If they are not good enough, no process will repair their inadequacy ("people trump process" is one way to say this).

However, "politics trump people." Even good people can be kept from accomplishing the job by inadequate support.

A recent update of the Chaos Report from the Standish Group outlines a recipe for success that includes ten items. The first three are executive support, user involvement, and experienced project management.

These are certainly key items, and we agree with having those three in the top ten. However, "competent staff" is buried inside the 10th item: "Other."

While it is true that lack of user and executive support can kill a project ("politics trump people"), it is equally true that the developers won't manage to produce a system if they are lacking the basic competency for the job.

Interestingly, people working together with good communication and interaction can operate at noticeably higher than their individual talent levels. We see this time and again in brainstorming and joint problem-solving sessions.

Therefore, agile project teams focus on increasing both the individual competencies and the collaboration levels.

Marcus Buckingham and Curt Coffman discuss the outcome of a long-running research program by the Gallup organization, in which 80,000 managers in 400 companies were interviewed over a 25-year period (Now, Discover Your Strengths, Simon & Schuster, 2001). In this book, they highlight the interplay between talent, skill, and knowledge. Regarding high-performance working environments, they write:

Extending their ideas, it’s not that organizations that employ rigorous processes value people less that agile ones, it’s that they view people, and how to improve their performance differently. Rigorous processes are designed to standardize people to the organization, while agile processes are designed to capitalize on each individual and each team’s unique strengths. One-size-fits-one—every process must be selected, tailored, and adapted to the individuals on a particular project team.

Too many software engineering and rigorous process adherents confuse process and competence. Process can provide a useful framework for groups of individuals to work together, but process per se cannot overcome lack of competency, while competency can surely overcome the vagaries of a process ("people trump process" again).

Look under the cover of XP, Scrum, Adaptive Software Development, Crystal Methods, Feature-Driven Development (FDD), or DSDM and the emphasis on people and their talent, skill, and knowledge becomes evident.

This is a competency attitude, not an elitist one. Whether it’s the practices of pair-programming and mentoring in XP or chief programmers and inspections in FDD, the goal remains consistent—improving the knowledge and skill of individuals through working jointly. The recent book of one agile development practitioner is therefore appropriately entitled - not software engineering - but Software Craftmanship (Pete McBreen, Addison-Wesley, 2001).

Team competence

Agile teams are characterized by intense collaboration and self-organization.

Here we distinguish between collaboration and communication. Communication is the sending and receiving of information. Collaboration is actively working together to deliver a work product or make a decision.

Agility requires that teams have a common focus, mutual trust and respect; a collaborative, but speedy, decision making process; and the ability to deal with ambiguity. Self-organizing teams are not leaderless teams, but teams that can organize again and again, in various configurations, to meet challenges as they arise.

The DSDM manual, as an example, identifies the differences between traditional and agile project managers, one of which is this: "A traditional project manager will normally focus on agreeing a detailed contract with customers about the totality of the system to be delivered along with the costs and timescales. In a DSDM project, the Project Manager is focused on setting up a collaborative relationship with the customers."

Scrum projects are characterized by intense 15-30 minute daily meetings in which participants constantly adjust to the changing realities of high-change projects.

All too often, project teams are given the ultimate accountability for product delivery, while staff groups—project offices, process management, data administrators—are given decision power. In order to innovate and react to change, agile teams reflect a better alignment of accountability and responsibility. It is again an emphasis, at the team level, on competency rather than process.

Agile Organizations

An agile team working within a rigid organization has as difficult a time as agile individuals working within a rigid team. Many project teams we have interviewed report that when they responded to customer’s requests and to technology platform changes, to deliver usable value to the customer, they were admonished by their management for lack of conformance to the original plan.

Agile organizations and agile managers understand that demanding certainty in the face of uncertainty is not dysfunctional. Agile companies practice Leadership-Collaboration rather than Command-Control management. They set goals and constraints, providing boundaries within which innovation can flourish. They are macro-managers rather than micro-managers. They understand that who makes decisions isn’t as important as collaboration on information to make informed decisions. They understand that agility depends on trusting individuals to apply their competency in effective ways.

Newtonian Neurosis is the label give to traditional project management by Doug DeCarlo. Neurosis in trying to attack complex, non-linear problems with simplistic, linear processes.

Agile Ecosystems

A project is built from people having differing personalities and differing skills, working in a physical environment within an organizational culture. The people, the environment, the organizational culture, all influence each other. When a strong person leaves, the organization rearranges itself to compensate; when the team spreads itself across multiple floors, communications change; and so on. The project is an ecosystem.

Using the word "ecosystem" to convey the totality of the project at hand, we get into the appropriate discussion of processes, ecosystems, and fitting the two together.

When installing a process within this ecosystem, there are two choices: fit the ecosystem to the process, or fit the process to the ecosystem. In reality, both change, but the agile approach is to honor the ecosystem, and recognize that not every process will work in every ecosystem.

Agile Effectiveness

The Cutter Consortium conducted a survey of agile and rigorous methodologies in the summer of 2001. Nearly 200 people responded, from a wide range of organizations in North America, Europe, Australia, India and other locations. The survey showed three interesting results.

First, many more organizations said they were using at least one of the agile methodologies in this study than in a similar study conducted late in 2000.

Second, the agile methodologies showed slightly better delivery performance than rigorous methodologies in terms of business performance, customer satisfaction, and quality.

Third, agile methodologies scored better than rigorous ones in employee morale. This is particularly surprising in the light that 54% of the respondents were IT and executive managers and only 12% were developers themselves.

One study is of course, only one study, and so the conclusions should be viewed accordingly. However, these preliminary results motivate the effectiveness and contribution to morale of agile approaches.

Agile Domains

Agile development is not for everyone. Imposing agile principles on process-centric, non-collaborative, optimizing organizations is likely to fail. Imposing a change-embracing process on sedate project teams may not be reasonable. Attempting to get close user collaboration with organizations that have little time to spend with developers won’t work. It is harder to be agile with larger teams.

Bearing all the above in mind, it is interesting to occasionally find successful agile projects with 120 and even 250 people. More relevant still is the statistic that the average project has only nine people, well within the reach of the most basic agile processes.

Agile development excels in exploratory problem domains—extreme, complex, high-change projects—and operates best in an agile, people-centered, collaborative, organizational culture. It has proved to be effective at solving many problems and at forging attractive work environments in many organizations. While it is not suited for everyone, it is suited for many.

Alistair Cockburn is Consulting Fellow at Humans and Technology. Contact him at arc@acm.org.

Editor: Barry Boehm, Computer Science Department, University of Southern California, Los Angeles, CA 90089; boehm@sunset.usc.edu

(This article appeared in IEEE Computer, Nov 2001)