Agile Grows Up

By Tony Baer

Five years ago, a group of software development gurus issued a call to rethink the way software development is managed. Responding to the fact that classic software engineering processes were growing too cumbersome to keep pace with the rapid changes demanded by iterative development, they introduced the concept of Agile development.

The goal of agile was to "welcome" changing requirements, no matter how late in the process by decomposing development projects into iterations lasting only a few weeks. With such short project cycles, software development can constantly be retuned as necessary as business or client demands change.

According to Todd Little, program director of the Agile 2006 conference, agile is now beginning to confront scale up issues as organizations seek to implement the approach on an enterprise scale.

Little, whose day job is senior developer for the Halliburton subsidiary, Landmark Graphics, said the shift towards scaled-out adoption places new governance pressures on a methodology that traditionally emphasized self-management.

For instance, Agile planning tools providers like Rally and VersionOne are adding enterprise features to their offerings to accommodate organizations that seek to spread Agile methods across larger swaths of their development groups.

According to Brad Murphy, senior vice president and general manager of Valtech's outsourcing division, there has been an upsurge of interest in large financial services companies whose complex software projects typically undergo numerous changes between concept and release.

As Agile projects scale, there is new requirement for leadership skills. At first glance, that sounds like a contradiction in terms, since Agile evolved with small teams that were largely self-governing. Furthermore, given the smallness of the operation, in most cases, developers typically took the lead roles, rather than relying on management.

It's a methodology that's also being stressed by the growing tendency to outsource development to offshore teams who do not enjoy the close proximity with customers so essential to the Agile approach.

Murphy responded that the key in such situations is to separate the portions of a project where the requirements are clear vs. those that require close contact.

"When we run an application building project in the US where a large percentage of the development team is in Bangalore, we must be good at differentiating the part of the backlog requiring interaction with the key stakeholder vs. that which doesn't," he said.

The issue, he said, isn't proximity, but time zone differences. On the east coast of the U.S., teams have at most a couple hours each day when both the U.S. and India are at work.

On the other hand, the nature of Agile, which divides projects into short increments means that in most cases, 70% of the work is probably well enough understood so as not to require constant communication.

As for the rest, if you're in India and have a question, you put that piece of the work aside and hold off until you have a chance to get your questions answered the next day.

Not all Agile practices have held well over time. For instance, the idea of "paired programming" has not always gone down well with developers. The practice requires one person to do the development while the other looks over his or her shoulders.

"In our company, a lot of our developers are PhDs, who tend to be rugged individualists," observed Little.

Little added that Agile approaches are not necessarily a cure-all. He said that Agile fits best during the early stages of a project when the idea is in formation undergoing frequent changes, rather than in the latter phases where the software is largely in maintenance mode.

Referring to MIT professor Michael Cusumano's "Microsoft Secrets" book, which described the company's software development practices, Little noted that the company adopted many agile practices before they had a name. But now many of the products developed under Agile approaches are mature, while the software development teams have grown large in numbers.

"Microsoft is struggling with agile now," he said.