Agile Development Requires IT/Business Communication


Agile software development isn't the most polarizing issue I've ever written about. (That "honor" goes to the H-1B visa.) But agile seems to provoke some pretty heated reactions among developers. When I wrote about agile earlier last week, I decided to follow a reader's suggestion and hit the Slashdot forums so I could see what he said were "overwhelmingly negative" comments about agile.


Slashdot's most recent discussion about agile focused on Mozilla's use of a hybrid agile model for its flagship Firefox Web browser, a topic I also wrote about last week. The comments weren't "overwhelmingly negative," and they included some knocks on the traditional waterfall method of software development as well as agile. But I did see quite a few negative comments, many of them hitting on agile's "chaotic" approach, which in theory can drive up costs and inefficiencies. One commenter wrote:


One of the things I've noticed suffers most in agile is the documentation because there's an implicit belief that this will all change again, so people skimp on it even more than usual to document it when it's "final." The result is often that things are kludges made to extend things rather than actually going back to refactor, because people spent very little time thinking about a long-term design in the first place.


Agile won't solve what this commenter sees as a huge development problem: Users that don't really know what they want. In fact, agile can exacerbate this, the user wrote. I didn't have to go far to find a similar take.


Our own Ken-Hardin, IT Business Edge's VP of subscriber products, said most users have trouble envisioning the business processes needed to attain the desired end state, which makes it hard for them to communicate what they want to developers in a way developers understand. Not to put the blame entirely on users, Ken said many developers think they know more about business processes than they actually do. (Please send angry comments to him, not me.)


Ken sees himself as an "ersatz business analyst" who likes to draw business workflows and thus is -- in theory -- better equipped to communicate them to developers. This gap in understanding was Ken's biggest knock on agile, since agile requires more frequent communication between developers and business users than the waterfall development process. (Though I suspect trouble communicating requirements hurts just as many waterfall projects as agile products.)


Larger companies may employ business analysts, and not just "ersatz" ones, to serve as a liaison between business users and developers during development projects. Forty-one percent of BAs interviewed by Forrester Research for a 2009 study said they use agile techniques. Forrester said BAs increasingly will be expected to understand the principles of agile development.


Communication between business users and software developers is one of the key tenets of agile, agreed Steve Hardin, ITBE's VP of software development, when I spoke to him Friday. This is why agile tends to work better for smaller companies with collaborative cultures than it does for big companies with more management layers, he told me


Steve, who has worked at companies of all sizes, from ITBE with our 40 employees to big conglomerate General Electric, thinks agile is more common at startups and other small companies. "Their development teams are often younger and more energetic. If they've got a question, they'll just go ask. In a company where the management structure has more layers, it can be a lot more difficult to get feedback from the VP of marketing."


When done right, agile encourages closer alignment between developers and business users, Steve said. "Sometimes the development team is separate from the business. You want to ensure there is business representation on the development team, not doing actual code, of course, but helping with the process." It's easier to "get people excited and focused" with agile, which also emphasizes breaking a software project down into smaller increments and producing more frequent deliverables.


Scope creep, mentioned by Ken and by some of the Slashdot commenters, is perhaps somewhat more commonplace in agile than in waterfall projects. More frequent feedback sessions afford more flexibility in adding new features, which can sometimes be a bad thing, acknowledged Steve.


When scope creep occurs, he said, "you have to go back to the original business need" and make clear it'll require extra time and money to add some features. A nod to waterfall, from the modified agile development process used by IT Business Edge parent NarrowCast Group says "... signoff and more in-depth documentation steps will be included."


Communication gaps can also make it more difficult, though not impossible, to use agile with offshore development teams, Steve told me. A few months ago, I shared some thoughts from Peter DeYoe, director of consulting company Computer Aid, Inc., on improving the odds of success for agile teams with an offshore element.