Getting Clueful: 7 Things CIOs Should Know About Agile Development

Agile methodologies for software projects can help organizations create better software faster. Yeah, yeah, you've heard that before. Here, experienced programmers explain the key ingredients to make those goals achievable.

1 2 Page 2
Page 2 of 2

Berteig is often surprised how often this concept is a revelation to executives. "Most of our organizational cultures in the corporate world are based on distrust and a decided lack of truthfulness. To change to a culture of truthfulness is a deep, long and difficult change—just like any other culture change!"

Yet, he asks, without a culture of truthfulness how can one learn from the inevitable mistakes? How can an organization create mutually beneficial relationships with clients? How can you be certain that at the end of each iteration the team is delivering what it really says it's delivering, or be certain that the stakeholders really want what they say they want? Berteig adds, "Traditional bureaucratic processes and procedures are often a result of a lack of truthfulness and an attempt to make up for that deficit."

4. Agile Doesn't Mean "Chaos is Good"

Managers who are comfortable with one-step-at-a-time methodologies may be uncomfortable with the iterative nature of agile development. But agile development doesn't imply disorganization.

Isaac Sacolick, vice president of technology at BusinessWeek and previously founder of TripConnect, says that while agile gives sponsors the ability to react to market conditions and reprioritize requirements, "Agile does not preclude long-term planning, architecture, standards or project management. Enterprises have to think through how and where to apply agile development."

The how and where matters. Few developers believe that agile is appropriate for every project and for every team—and they hope the CIO understands when to set it aside. Marshall Presnell, development architect for Village Voice Media, says, "The agile model of development is optimally suited to rapid and chaotic requirements changes." And Gary Rowe, director of Froot, an agile development consultancy, recommends agile for projects with unclear or shifting client requirements.

Where's it the wrong choice? John Miano, owner of Colosseum Builders, says it's not suitable for projects that will have a long lifetime and those where complete reliability is required.

Organizations that adopt agile principles don't change the basics of defining problems. "Agile development doesn't mean that you don't do requirements analysis and design," says Mike Emeigh, QA Manager at Deltacom. Good agile teams do requirements analysis and design, he says. "They just don't waste a lot of time committing it to reams of paper [or] have a whole bunch of people who can't possibly grasp all of [the issues] try to study and understand it before they commit it to working software."

But the iterative nature of agile development—in which developers and users work together to design and cocreate the application—sure doesn't sound like it's easy for a manager to track. CIOs want to know the status of every project in company, but agile implies that requirements and schedules are always changing. Adherents insist that's a wrong assumption.

Responds Christopher McMahon, QA tester at SocialText, the enterprise wiki company, "We estimate the work for each iteration. Because our estimations get better over time, we know from iteration to iteration exactly what we can deliver, and we can project that into the future with relative ease. Because we track stories in the backlog on burndown charts and use other Big Visible Charts to broadcast our status, that status is easy to check. And because we have Iteration Managers whose job it is to keep the work moving, we have an expert available on each project to answer any detailed questions."

According to Ben Weatherall, configuration manager at pharmacy technology provider PDX, the workflow involves more than just the programming staff. "Just because development is practicing agile methods does not mean that configuration management should be ignored," he says.

Agile development includes version control on code and requirements; defect, issue and enhancement tracking, and some way to relate their status to the code changed to resolve them; and a way to capture, track and index communications with the customer to indicate changes to the requirements, success or failure of demos and tests, and so on. Adds Weatherall, "The tools used to facilitate CM in an agile environment need to be 'tuned' to that environment just like the development tools do."

5. Agile's Benefits Are Worth the Wait

As with any process change, the effects won't be seen immediately. It takes time for the process to take hold.

James Kricfalusi, service delivery executive at TEKSystems, says, "Sponsors and executives equate agile with immediate results. This is not realistic. Trust the team, relax and let them do their thing. Lower your expectations in the beginning because most of the initial advances cannot be in the functionality of the first release."

According to Kricfalusi, in the early work on an agile project, initial iterations are an investment in frameworks, new ideas, process definitions and understanding of the requirements. The initial release may miss the mark, but the team will have developed a cheap and effective means of providing effective feedback to improve later versions. Judge the results relative to the time frame of the existing processes, Kricfalusi advises. "If your prior project time frames were 6 months to a year, it will take about that long before you can have the proper perspective to evaluate your progress."

Don't get lost in those initial iterations, either. Remember: They aren't intended to be the final version. Ivan Brusic, lead Web developer at Mansueto Ventures, says, "Sometimes a prototype is just that: a prototype. Early project iterations might get thrown away, but that tends to happen only when the initial requirements were not understood."

Sutton urges CIOs to tell everyone involved that you will support their efforts to deliver working software in a month, every month. "Back them up 100% like you promised—on training, wacky new ways of working—whatever they come up with. Try it for a month and see what you get, then do the whole thing again for the next month until you get the phenomenal results!"

For the changes to take place, says Pollyanna Pixton, president of Evolutionary Systems, stop micromanaging. "Recognize that agile practitioners will deliver business value in increments. Leaders should stop placing importance on 'old school' measurements such as schedule and costs, because in rapidly changing markets focus should be on value creation."

Agile tools like burndown charts will enable managers to see value creation and value velocity, so leaders can make the go/no-go decisions early in the projects, Pixton says. And, in so doing, avoid building any of the 64% of features rarely or never used.

6. Agile Isn't a Silver Bullet

While agile can offer businesses a lot of improvement, it won't solve every development problem.

"Bad programmers/communicators can still fail with agile," points out developer Kelly Anderson. "Give competent and invested people agile, and you'll have happier people doing better work more rapidly. Give incompetent, unempowered people agile (or even worse, just the word agile), and you'll still fail," he says.

Neil Roodyn, author of eXtreme .NET: Introducing eXtreme Programming to .NET Developers, says that agile will not convert a bad development team into a good one. "Agile is not a religion, a methodology or a solution to allow mediocre software developers (which is most developers, by the nature of the term) deliver awesome software."

Ed Cowsar, CEO and managing principal at Inside Methods, says, "There is no middle ground in agile software development—radical success or miserable failure are your only options."

Excellence requires care and attention to detail, as in any endeavor. "To successfully adopt agile development, teams need self-discipline, a rigorous approach to their work, management support and time to learn. Good managers can supply the latter two. A good coach or technical lead can help the team achieve the first two," says James Shore, an independent consultant and author of The Art of Agile Development. "Excellence is hard; people like to take the easy way out. But the big gains people associate with agile development come from excellence, not mediocrity."

Don't adopt agile because it's popular, says Shore. "Don't go out, buy a bunch of 'agile' project management tools and certifications, and declare victory. Have your conscientious and thoughtful leads take the time to truly delve into the ideas and philosophy of agile development, including why those tools and certifications aren't central to the agile approach."

7. Success Depends on People

Just as agile may not be suited to every type of development project, it may not be the right option for every team, peoplewise.

Miano, the owner of Colosseum Builders, says, "Agile-type development also tends to be very personality dependent. If you put 10 people together in a room, they all had better be compatible.... The people working in such an environment need to be able to ignore the personal quirks of the others."

Others believe that agile can bring teams together. Steve Reiser, a senior software engineer, says that a team's ability to respond quickly, with frequent periodic successes, makes team members empowered and happy. "When a project fails, the team fails. When the team fails, morale suffers," he says. "Agile keeps work levels high, success rates high, adaptability high, which all contribute to keeping morale high."

Is it a lot of work to make agile work for your team? Certainly. It requires a major change in the way that software is developed, and in the way that teams— including the user community—design applications. But, insist the people who use agile methodologies, it's worth it.

Copyright © 2008 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
7 secrets of successful remote IT teams