Agile Development Requires IT/Business Communication

Ann All

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.



Add Comment      Leave a comment on this blog post
Feb 1, 2010 4:59 AM Al Gibson Al Gibson  says:

Good column.  Fair enough.  Agile is fine in very small shops and startups with few workers, I will admit.  The problem with it, like any movement or religion, is that the zealots must apply it as a one-size-fits-all with scalability.  By zealots I mean the consultants who spend their days prosthelytizing in all the IT industry pubs, speak at expensive conventions, and those who leech on to big companies by convincing the PHB that Agile can not only wax your floors but also act as a dessert topping.  The other problem with Agile is the lack of successful high profile projects other than the occasional dotcom (very small shops and startup with few workers).  Remember that the creation of Agile was birthed during a years-behind, way over-budget project with Chrysler about ten years ago.  Too bad a serious, impartial firm hasn't properly polled those at larger companies or on larger projects who have suffered under Agile and the variants (Scrum, Waterscrum, et al) because I believe there are many in IT with experience who view it negatively.  I'm also not saying that Waterfall is the end-all/be-all to software development.  I also concur on the crucial role of a good BA.

Reply
Feb 2, 2010 2:33 AM Dave Rooney Dave Rooney  says:

The suggestion that the business and the IT people building their software must communicate ranks up there with "buy low, sell high" in terms of obvious advice.  It doesn't matter what process is used to deliver the software, if there is real collaboration between the business and IT then there will be success.

Collaboration doesn't mean one group gathering requirements in isolation, presenting them to the business people for sign-off.  Collaboration doesn't mean another group analysing those requirements in isolation and creating a functional spec for business sign-off.  Collaboration doesn't mean the developers going away for 6-12 months to build the system, followed by acceptance testing by the business.

Collaboration means that business people, BA's, QA, developers, infrastructure, possibly facilities, HR, etc. are all involved constantly from the time the idea is discussed to when the solution is delivered.

That level of collaboration allows that whole 'community' to steer the project to successful completion, delivering not only a system that's high in quality, but also much more suitable to the business task.

I've been building software professionally for over 21 years now on teams large & small.  In all cases, the best systems were created using this collaborative model.  No document can communicate as well as people gathering together for a discussion.

Agile Software Development simply puts a name to this level of collaboration.  I've been involved with Agile for almost 10 years now, and it's by far the best all-round approach to delivering software that I've encountered.  I've seen some failures, but many more successes.  In every case, the team/group/company evolved the process to suit their particular circumstances and business domain, and especially the people.  The prescriptive processes with which I have worked assume that every person is simply another cog in the wheel - they're a 'resource'.  Agile assumes that we're all human.

As for scope creep, here's an analogy.  Let's say you're renovating a bathroom, and you planned to change the sink & vanity, reuse your existing tub & shower, and put down ceramic tile on the floor.  After replacing the sink & vanity, you decide that you do want to replace the tub & shower after all.  In order to stay within your budget, you decide to forego the ceramic flooring, and install less expensive vinyl instead.

Those are changes, NOT scope creep.

While doing all this you realize that since the new vanity has a granite countertop, and you want granite counters in the kitchen as well.

THAT is scope creep.

Reply
Feb 3, 2010 2:32 AM Al Gibson Al Gibson  says: in response to Dave Rooney

Dave, you sound like an Agile acolyte.  I love your analogy, as it demonstrates the absurdity of Agile with it's constant excusing of poor planning.  Only somebody who thinks Agile is the bee's knees would replace a sink and vanity first before deciding what to do with the rest of the bathroom, particularly the flooring. 

Reply
Feb 3, 2010 9:22 AM software development company software development company  says:

Thanks for sharing this article in your blog.It was very nice.Looking for more..................

Reply

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

null
null

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.