Agile Process Showcased at IT Architect Event

Click here to receive your FREE subscription to Campus Technology

Home > Agile Process Showcased at IT Architect Event

News

Agile Process Showcased at IT Architect Event

10/25/2007

By Kurt Mackie

Last week, IT architects put their profession squarely on the map at the first annual IT Architect Regional Conference for Southern California. This local San Diego-based event, part of the International Association of Software Architects (IASA), wasn't just a typical forum for punditry on the sometimes obscure topic of service-oriented architecture (SOA). It was more a meeting of colleagues. The keynotes and sessions were frequently paused to answer spontaneous questions and remarks from attendees.

The first keynote speech, by Scott Ambler, IASA Fellow and IBM Rational practice leader for agile development, wasn't about SOA at all. It was about the agile software development process, which Ambler predicted would probably become the norm by 2010. Ambler spoke on "Agile Strategies for Enterprise Architects."

The agile process is usually defined as the use of small teams to create frequent software builds and releases. Agile teams typically create solutions without slowing down to document the process. In that sense, agile development is often contrasted with the traditional waterfall software development approach, which is heavily documented and prescribed. While that's a common way to characterize agile development, Ambler said no formal definition for the term really exists.

The majority of companies appear to be engaging in the agile software development process. Ambler cited a March 2007 Dr. Dobbs Journal survey of agile development where 69 percent of respondents said that their organizations were doing one or more agile projects.

Ambler called the concept of following repeatable processes in software development a "stupid idea." He said that teams work together differently and that the development process should stop catering to constructs formed by bureaucrats. People are not going to follow repeatable processes for the sheer joy of it, he said. What is really wanted is repeatable results.

In practice, you can't make decisions based on your documents (a traditional waterfall approach). There's nothing wrong with documentation, but agile developers are smart about it and don't try to write speculative documentation, Ambler said.

Writing the requirements first is not practical, for a number of reasons that Ambler described.

"We build software to meet the changing needs of our stakeholders," he said. "The stakeholders will change their minds. Trying to write a requirements specification -- trying to set up a design document early in the lifecycle -- is absolutely crazy. People are not good at defining up front what they want. We've known this for a couple decades now."

One reason to go with agile software development is that 45 percent of software functionality is not used on successful software development projects, per data from the Standish Group that Ambler didn't specify. Under traditional methods, developers may spend nearly half of their time creating functionality that their customers won't use and don't really want.