Like many of their peers, software developers at the Texas Education Agency (TEA) previously started a project by documenting detailed requirements. Only when they finished that labor-intensive phase did they start writing code. And only when they finished the code did they show the application to the customer.

Customers weren't always thrilled. "By the time the product was being implemented, the requirements were stale and had already changed," said Martha Reesing, program manager of core technology in TEA's IT services division.

Business needs evolve -- that's a fact of life. And it's a big reason why some government IT shops are forsaking traditional software-development models. Instead, they're adopting a range of approaches known collectively as agile development.

Agile development has no hard-and-fast definition. Numerous methodologies -- the best known are Scrum and Extreme Programming -- live under the agile umbrella. But experts point to core principles that apply to agile models. Specifically agile development:

• Stresses collaboration and communication. Team members, customers and other stakeholders work together.
• Is highly iterative. Teams work in short development cycles -- perhaps two to four weeks -- and deliver a functional, tested software module at the end of each cycle.
• Is self-organizing. Agile uses formal processes but allows teams to govern themselves as much as possible.
• Emphasizes customer value. When customer requirements change, that's a normal part of the process, not a nuisance. Success is measured in value delivered, not in days ahead of schedule or dollars under budget.
• Encourages continuous improvement. After each development cycle, team members reflect on what went right and wrong, and propose improvements.

Agile development contrasts sharply with the development model known as "waterfall." Under that traditional approach, developers finish one project phase completely before moving to the next, cascading from requirements to design, implementation, verification and maintenance.

Waterfall development doesn't work well because humans can't predict every function and feature they will need in an application, said Scott Ambler, worldwide practice leader of agile development with the IBM Software Group. When customers see how software is shaping up, they refine their ideas. "If we go against human nature, we actually increase the risk," he said.

Since laws, business conditions and users' ideas are bound to change, some people decided they should build change into the development process, said Paul Clanton, CIO of Douglas County, Colo. "They concluded that we need a lot more conversation," he said. "We needed to shorten the process and deliver something in [the customer's] hand in a much shorter period than in the stereotypical 18-month project, where you deliver something that's no longer needed."

It's difficult to get a handle on how widely agile is used, said Elizabeth Zucker Barnett, principal analyst with EZ Insight, a consultancy in Bedford Hills, N.Y. In part, that's because people define agile in many different ways. Also, some agile teams operate under the radar. "It's hard to find a Fortune 1000 company that's not doing some agile work, but it's hard to understand how much is going on within any one company," she said.

Photo: Elizabeth Zucker Barnett, principal analyst EZ Insight

Productivity, Quality, Satisfaction

Organizations that go agile say the approach makes them more productive, improves software quality and makes stakeholders happier, according to Ambler, who conducts an annual survey on the subject for Dr. Dobb's Journal, which is now part of InformationWeek. Agile doesn't