I write a lot about the general importance of improving communications between IT and the business and the havoc that poor communication between the two camps can wreak.
Considering the strategic importance of software applications to many companies and the high costs of development and, in particular, of going back and doing major code fixes, development is one process where communication would appear to be especially important. There's also users' general dissatisfaction with enterprise applications to consider.
Close communication between users and developers is a key characteristic of a process Computerworld calls application development 2.0. I'm no expert, but I think the article is referring to Agile software development, which departs from the traditional waterfall development process in a number of ways.
As is the case with a number of other tech trends, Agile first gained popularity with consumer-oriented applications and is making its move to a somewhat skeptical enterprise. Looking at it from a high (and admittedly non-technical) level, I am not sure why companies seem so suspicious. Agile values flexibility, simplicity and getting tasks accomplished quickly -- three characteristics that are hard to see as negative.
I learned a little about Agile development in a recent discussion I had with Doug Mow, senior VP of marketing for outsourcing provider Exigen Services. Perhaps the single biggest difference, says Mow, is that "Agile methods assume that change is inevitable and seek to incorporate change, not resist change."
In outsourced application development, a competitive force, regulation or other factor that leads companies to ask for a change not included in original design specifications leads to a change in scope and a change order with added cost. While added costs may not be as obvious for an in-house project, delays do drive up costs and also often create ill feelings between the business and IT. As Mow puts it:
There's often this gap of IT saying, "The business can't make up their minds" and business saying, "IT can't keep up."
Agile's emphasis on speed and its iterative nature result in greater user participation, fewer hard feelings and hopefully, happier business people. Says Mow:
One of the benefits of this is that you deliver working code much sooner. The business community can request changes in between each one of these iterations. The business community is watching this system become more malleable instead of more rigid. The changes they request are actually being incorporated. The issues they raise are addressed sooner in the process. Their participation actually has an effect on what happens -- this isn't always the case with more traditional development methodologies. You really get a greater degree of alignment between IT and the business.
A caveat: Whether a project is in-house or outsourced, Agile requires a high degree of collaboration between IT and the business, something that not every organization is prepared to offer.
According to the Computerworld article, which echoes many of Mow's points, 70 percent of developers participating in a recent TopCoder online coding competition said that traditional corporate development teams could benefit from newer techniques, especially incremental feature releases, speedy user feedback and quality assurance programs involving users.
The article offers five suggestions for tech executives who want to try Web 2.0 development:
- Encourage close contact between developers and end users, and involve users in quality assurance processes;
- Stress simplicity;
- Use dynamic scripting languages like Ruby, Python and Perl rather than Java or .NET;
- Emphasize frequent releases;
- Users, not developers, should determine new features.
Another endorsement for Agile: General Electric engineers apparently use Agile methods for frequent tweaks to the company's much-vaunted SupportCentral network, which serves 400,000 users in 6,000 locations around the world.