• White Papers |
• Blogs |
• Video |
• Webcasts |
• Podcasts |
• Events |
• Solution Centers |
• Newsletters |
• Magazine |
• RSS Feeds

Getting Clueful: 7 Things CIOs Should Know About Agile Development

By Esther Schindler

February 06, 2008 — CIO — Though it may surprise cynical IT managers to learn this, developers care passionately about the software they write.

Managers want top-notch, bug-free applications delivered on time, which meet or exceed user expectations—and the people who build that software have the very same intention.

How managers and developers achieve those goals, however, can be far different. The "old" school of software development followed a path in which software specifications were defined explicitly in the form of an inviolate requirements document. Then managers told the development staff to write that application...and come back when finished.

The result, too often, was a great answer to the wrong question: software that's late, that does interesting things but doesn't solve the user's need, and—well, you're probably too familiar with the results.

Over the last decade or two, software engineers have invested a huge amount of energy in finding better methodology for creating great software that users love. Agile development embraces several processes, such as test-driven development, and extreme programming (XP). There are quite a few more processes, each with its adherents and evangelists. But they all consider themselves agile.

They have quietly been taking over your development department, too. According to recent research from Evans Data (registration required), more than half of North American developers are using agile methods today. But IT managers may not be on board.

Agile has crossed the chasm, and "the majority of organizations are doing agile, and agile works better in practice," says Scott Ambler, author of several books (including Agile Database Techniques: Effective Strategies for the Agile Software Developer) and practice leader for agile development in IBM's Methods Group.

If you aren't a programmer, or if it's been so long since you coded that you get nostalgic for JCL, it behooves you to listen up. I asked online of more than 50 developers, "If you could get the boss to understand one thing, just one thing, related to agile development...what would it be? Why that?" Their summarized answers will help you prioritize the essentials to incorporate these development practices into your software projects.

Steven Smith, CIO of Lake Quincy Media and also a software developer, wraps up most developers' opinions succinctly: "I wish management understood that the quality value provided by agile technologies, and most especially from well-tested code, pays big dividends in terms of reduced QA expense and faster time to market for any significant-sized project. We have some projects in-house that were developed in an agile fashion, and others that were not—we dread touching the ones that were not."

1. Agile Creates Better Software

Agile methodologies aren't something that your development departments adopt because it's a cool way to write code. They see the major benefits in business terms, just as managers do.

In the experience of Kelly Anderson, C# developer and technical team lead at Sonic Innovations, the agile approach is less expensive. "If you count the cost of bugs that make it too far downstream in the process, there is simply no way to financially justify any approach except some kind of agile approach," he says. "Poor quality costs money. Lots of money. Agile leads to higher quality, enough higher that it is cheaper."

Plus, Ambler adds, it's easier to govern agile projects than it is to govern traditional projects.

"Agile development can reduce the cost of late changes, making it easier for IT organizations to respond as stakeholders' needs evolve," says Cem Kaner, author of Lessons Learned in Software Testing and Testing Computer Software.

Kaner, who is professor of software engineering at the Florida Institute of Technology, adds: "The most important thing the executive can do is keep asking the critical question, 'How does this practice (paired programming, test-first programming, whatever the group is proposing this week) make us more able to be more responsive later?'" If those implementing the process can't answer this question convincingly, Kaner says, it's a big red flag.

Agile's business value comes from organizations' ability to focus on which projects to do, what features to include in those projects, and which processes to use, according to Kent McDonald, business systems coach at consulting firm Knowledge Bridge Partners. "Value is provided by only doing the important things that directly contribute to the sustainable competitive advantage of the organization, and value is detracted when activities are performed that do not contribute to that sustainable competitive advantage," he says. "Organizations can adopt a focus on value without necessarily adopting agile development practices, but it is a cornerstone of those approaches."

"Enterprise agility means that the enterprise can respond to business needs faster—and that it can maintain this," adds Alan Shalloway, CEO of Net Objectives. "It means that product managers select functionality that will make the most sense to the business and deliver in stages so resources can be reallocated as necessary to provide the greatest value."

The business benefit is a key message for CIOs and IT managers. But it's not the issue about which developers feel most passionate.

 

 

 

Email

Print

Comments

Digg This

SlashDot