Personal Blog (scroll down)
Why Do IT Projects Slip, Part 2
Why Do IT Projects Slip, Part 2

Why Do IT Projects Slip, Part 2

In response to my original article, Why Do IT Projects Slip, I received some responses suggesting that Agile was the solution.  Two thoughts cause me to speak to these responses.

First, Agile is a software development methodology and software = IT = software is not a true statement.  “IT” is more than just software.  Second, Agile, as a software development methodology is ‘new,’ and increasingly ‘popular’ as a topic.  Like many things new, purists are prone to blindly promoting it as a cure-all for software development’s ills.

Without making this an in-depth Agile discussion… Agile supports more-rapid delivery, by breaking work down into numerous smaller iterations. This work is done by (ideally) self-organizing teams, with minimal-if-any planning. An ideal ‘Agile team’ includes a customer representative (e.g. business analyst). The BA is important for helping define what the team’s to do…as well as keep things on track.

As a result, I not believe Agile really addresses the core problem in the context I presented it (Why Do…). Agile can help you get to ‘90%’ more quickly<g>, and likely with a better product. Yet it does not itself, as a methodology, solve the crux of the problem.

This past year I’ve met with numerous companies, including the world’s 5th largest PC software publisher, and not found a single one that can claim to be even close to ‘fully adopting’ Agile. For the most part, they adapt the parts that make sense to them and then struggle to extend adoption across the rest of the organization. (Note, I’m talking mid-to-large software companies…and…again…this discussion’s not constrained solely to software.)

Every Agile users group meeting I’ve been to generally involves a very healthy dose of discussion around the core tenets of my original article: communication, leadership, and time lines. They also tend to be very tactical in nature. Rarely do they even acknowledge active involvement with Product Management, for instance. Again, typically -very- tactical in nature. And this isn’t just one, two, or three events I’m talking about.

While Agile as a methodology can help accelerate quality work iterations, it does just that. The methodology is designed to allow flexibility in the face of fast-changing requirements and/or external inputs. (There’s another risk: fast-paced project change introduces scope-creep risks as well…) Agile itself actually does not speak to ‘completeness.’ Its decentralized leadership function can also risk a loss crisp focus.

In the end, Agile is a methodology, a way of getting work done. I can paint my house using a brush, a roller, or a sprayer. It doesn’t make sure the job itself—got done.  Making sure things are -done- still demands effective leadership, strong communication, and commitment.

(Photo credit: sibaudio)


Comments are closed.

%d bloggers like this: