Free Newsletters

   All InfoWorld Newsletters
New York CTO | Jon Williams » Agile's weakness - not 3 steps ahead

September 12, 2007 | Comments: (0) | TrackBacks: (474)

Agile's weakness - not 3 steps ahead

After having lunch recently with a vendor leading us through an Agile process, I mentioned what I believe to be a drawback in the process. Agile does not look far ahead of a project. While this clearly has benefits (i.e. Heads-down on current deliverables, no 100+ requirements doc), it can mean the big picture view getting lost.

I recall a panel at Infoworld's CTO forum in 2002, where Kent Beck and Grady Booch argued this exact point. Kent claimed that the Agile (XP at the time) team would come up with a grand architecture, and Grady said it would be half-baked. By the way, this was probably the best panel I've seen at a conference. The moderator took notes on index cards from the audience right from the beginning.

I think that managers need to look 3 moves ahead separately from the Agile process, and then figure out how to share or infuse that thinking with the team, again outside the Agile process. Dare I say best of both worlds? I would be happy to hear contrary opinions or experiences here, and I'll admit I've not researched if there are ani long-term Agile models.

Posted by Jon Williams on September 12, 2007 11:34 AM


RATE THIS ARTICLE:





 

  •  
  • COMMENTS




Indeed. The goals of an Agile team are often in direct conflict with the goals of the enterprise architects: http://www.infoq.com/news/2007/09/AM_and_EA

Posted by: Gavin Terrill at September 12, 2007 02:05 PM

A few thoughts:
1. You need to go beyond "Agile out of the box". Many of the popular/cool agile processes such as XP or Scrum don't include explicit "look 3 steps ahead" practices. Then again, they don't prevent you from doing so but do suggest that you be smart about whatever you do.
2. In the Agile Modeling methodology, http://www.agilemodeling.com, we describe how to look ahead effectively through agile approaches to modeling which don't exhibit the costs and risks that we see on traditional teams. This includes doing initial requirements and architecture envisioning at the beginning of a project, something that 77% of agile teams do in practice according to Dr. Dobb's 2007 Agile Adoption survey. We also model storm on a just-in-time basis to get the details that we need, and, egads!, we will also "model a bit ahead" to explore near-term upcoming requirements which we haven't gotten to yet. So yes, agile teams which are smart will in fact look a few steps ahead, but because we're smart we're not trying to look 1000 steps ahead.
3. When you scale agile approaches to address the real-world concerns that you run into commonly, such as conforming to industry regulations, fitting into your overall IT governance structure, distributed teams, or complex applications, then you quickly discover that "agile out of the box" doesn't always work for you. That's not to say that throwing a bunch of bureaucracy at the problem will help, which invariably seems to be the traditional strategy. Agile software development does in fact scale well to meet the complex needs of modern environments, if you choose to have an open mind.
4. If the goals of an Agile team are in conflict with the EA team, then perhaps your EA team could learn a thing or two. I'm a firm believer in both EA and in Agile, and can safely tell you that EA can definitely be enhanced through the application of Agile concepts. I've written more than a few articles on this very subject, and a good starting point is http://www.agiledata.org

- Scott W. Ambler
Practice Leader Agile Development, IBM Rational

Posted by: Scott Ambler at September 17, 2007 10:05 AM

Technology White Papers

 

InfoWorld Technology Marketplace

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert

Find out when the latest white paper is available:
 
 
» BUY A LINK NOW

Sponsored Technology Links