Project Management Institute

Full speed ahead


Agile software projects dangle the promise of high-quality results delivered quickly, but project managers must make some major adjustments in how they—and their team—work.

SOFTWARE DEVELOPMENT PROJECTS have a notoriously bad reputation when it comes to delivery—and with good reason. Over the years, a bevy of studies have shown a shockingly low percentage of these projects come in on time and within budget. It's a small wonder then that many companies are heralding agile development as a miracle cure.

Focused on adapting to changing requirements, agile aims to solve many traditional development problems by breaking software projects into smaller chunks. Functional, fully tested pieces of code are then delivered to the client on an iterative basis. Because clients approve each stage, the end product is hopefully one that will meet user needs.

And indeed, there's a glimmer of agile's potential in 2006 Chaos Research, a biennial look at software project results conducted by The Standish Group International Inc., a research and IT project analysis firm based in Boston, Massachusetts, USA.

Only 35 percent of software projects were delivered on time, on budget and within requirements, according the study of more than 10,000 global software projects completed between October 2005 and November 2006. Although that's certainly not great, it's an improvement, which the report credited in part to the increased adoption of agile methodology.

One of the reasons agile works is that it requires ongoing testing. This means flaws are caught early—or so the theory goes—and the team is building on a “bug-free” foundation.

“Software applications can be a lot of smoke and mirrors. You can build something with a weak infrastructure that looks nice, but wouldn't know it until new updates are requested and it starts to fail,” says Aarti Sharma, PMP, program manager at Viatech Inc., a systems engineering company in Eatontown, New Jersey, USA. “With agile, you must look constantly under the hood and make sure that the software will be robust.”

Moreover, project sponsors can specify the features they want addressed throughout the process—eliminating one of the biggest problems with mainstream software projects.

“The inability to deal with change is the main reason software projects fail,” says Khaled El Emam, Ph.D., a senior consultant at Boston-based Cutter Consortium's agile software development and project management practice, and an associate professor at the University of Ottawa, in Ottawa, Ontario, Canada. “If you are building systems that are not finished for two years, the business you are trying to support may not even exist any more.”

But adopting agile hardly guarantees success.

”[Our research] suggests that use of a critical mass of agile techniques can have positive outcomes for software quality, team productivity and stakeholder satisfaction without a significant increase in cost,” says David Parsons, Ph.D., senior lecturer at the Institute of Information and Mathematical Sciences at Massey University in Auckland, New Zealand. “Of course, like any software development approach, agile methods have to be managed properly and implemented effectively.”

Although agile is more flexible than methods used on traditional software projects, there is a process. “The general impression of agile is that it means ad hoc, but done properly, it's a very disciplined process,” Dr. El Emam says.

And it's a process that requires project managers to change their approach.

With agile development cycles typically measured in weeks rather than months, there is a great deal of back and forth as the team reacts to changing customer requirements and estimates. And the project manager should be in the throes of it all.

“Instead of the traditional project manager role, an agile leader is more hands-on, more likely to be looking at code than a Gantt chart,” Dr. Parsons says.

That may be a change of pace for some. “I've been on projects where the project manager is just a scribe,” Ms. Sharma says. “You have to be more than that in agile. You have to have an inside view of what's going on.”

To keep abreast of changes, agile teams depend on constant updates. And it's up to project managers to keep everyone on the same page.

“Communication is critical. That's one of the things the methodology overall really promotes—short communication loops and the information being readily accessible,” says Bill Schneider, PMP, senior project manager at Command Information, Herndon, Virginia, USA. “Developers, testers and clients all need to know what the status is, what's being worked on and whether all previous functionality is still working.”

To strengthen communications, agile project managers typically rely on two tenets:

1. Get everyone in one place. The concept is simple: Communication is easier when your team member is sitting two desks down, and problems can be immediately tackled and hashed out. It's not always possible on larger projects, and there are certainly some challenges—including a lack of privacy—but working in close quarters can lead to a more cohesive team, Mr. Schneider says.

“If something's going wrong, everybody knows it in enough time to make a decision.”

2. Make sure customers are in on the action, too. “All agile methods have users on the development team,” Dr. El Emam says. “Living, breathing and working with the development team is one of the critical success factors for agile.”

Agile allows users to prioritize the features they want on each iteration, which translates to a shifting development landscape that may make some sponsors and managers uncomfortable. “Customers are not used to being so involved, and people tend to want that magic sign-off on requirements,” Ms. Sharma says.

All this boils down to an increased need for negotiating skills from the project manager. For example, users might pinpoint three features they want on an iteration, but the development team may only be able to deliver two. “You have to go in and negotiate and get them to accept delivery in stages, and do it without alienating them,” Dr. El Emam says.

“This is where it becomes hard,” adds Mr. Schneider. “I'm giving users control over scope, but forcing them to make the decisions. Business users haven't had to deal with this.”

Clients and project managers aren't the only ones that must change the way they operate. Team members, too, must be prepared to adapt to the unique challenges of going agile. Not everyone is cut out for the job—and project managers need to keep this in mind as they set up their team.

“In general, agile team members need a broader range of skills than the traditional software engineer,” Dr. Parsons says.

First, they should be able to draw from a well of experience, Mr. Schneider says. “You're not going to be able to do agile with five guys straight out of college,” he says. “Generally speaking, you're going to want slightly to significantly more senior people.”

Team members must also be able to tolerate a lot of company, as agile teams are usually located in the same room. “Some software developers like sitting in a dark room by themselves,” Ms. Sharma says. “Those are not the right kind of people for agile.”

They also must have a high tolerance for change. “Look for people who can deal with uncertainty well,” Dr. El Emam says. “You start working on something and priorities change and you don't have a complete picture—this is continuous. I've seen teams where people have to ask to leave because of this.”

And, of course, they must know how to communicate, as agile lives and dies on the team's ability to roll with the punches. “Communication is an absolute requirement,” Mr. Schneider says.

Project managers may also want to institute some ground rules to ensure the agile team members play well together. Mr. Schneider advocates what he calls “self-organized teams.” The thinking is that with so much together time, teams need to sit down before the project kickoff to agree on some basics.

“One of the things we usually do during the first iteration review is come up with a set of rules around how we work together—things like core hours,” Mr. Schneider says. But they also drill down to the level of rules about whether the lights are on or off, or whether food can be thrown away in the team room. Once the framework is set up, Mr. Schneider tries to let go and let them work. “Part of my job is to stay out of their way and not be authoritarian,” he says.

And in the end, striking the balance may be one of the best things an agile project manager can do. “Teams will do well if they can get the freedom to do whatever works best within the confines of getting software built,” Mr. Schneider says. “It's my job to get them there.” PM

Carol Hildebrand is a freelance writer based in Wellesley, Massachusetts, USA. A former senior editor at CIO, she has also written for Computerworld.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI.




Related Content