Cult of the Lowest Common Denominator

One of the things that amuses me most (on almost a daily basis it seems) is the general lack of focus in the world-o-sphere of exactly what the major issues are in the software development game. For a field that is already so key in how our increasingly tech-dependent culture goes about it's everyday existence, it seems to me that everyone seems to be blissfully ignoring the most obvious obstacle which prevent software projects from entering a higher level of being - that of the Lowest Common Denominator (oh, and having already typed that term twice, from here on in I'll be using the rather natty acronym LCD).

This (incredibly sporadic) series of posts will highlight the various ways I've noticed LCD manifesting itself around myself and some of my more highly esteemed colleagues.

Are you sitting comfortably? Then we'll begin...

PART 1 - Agile
My most recent thoughts on LCD were sparked by David Peterson's blogging about the chasm facing Agile practitioners in getting general acceptance of the process by the mainstream corporate development communities. I completely agree with his main viewpoints, but feel the need to add a slightly cynical slant of my own...

Agile itself (and I'm using the term as a catchall for Agile/Lean/Scrumm/XP - you know all the good stuff that you're already doing, right?) is a duplicitous being. On the face of it, the techniques and processes that surround it seem simple enough that anyone and everyone feels confident in slapping the badge onto their CV and parading it before them like the Ark of the Covenant, feeling generally invincible. For example, TDD - what's so hard about that? It just means writing a test, and that refactoring malarkey is just about renaming stuff, right? And those Agile books, they're *really* thin - there can't be too much to it if you can sum it up in so few pages.

Unfortunately, this inherent simplicity is coupled with an incredible need for discipline and boldness in all aspects of the development cycle and it's this which will present the biggest obstacle to the Agile adoption process from my perspective for the following two reasons, only the second of which will be discussed here:

1. having the development team do it right
2. having the management team support it right

For those of you that are lucky enough to be working on a corporate software project and aren't yet familiar with the process, here's this week's LCD:

Most bigwigs don't trust their development teams.

In my (admittedly somewhat jaded) experience, project sponsors don't really like thinking about the situation on the ground - just make them look good by deadline X and they're happy. And if it doesn't work, then just remember that 90% of all IT projects fail and be sure to have someone to blame it on - (handy tip: Consultancies are perfect for this and adjust their rates and slavegrinding machines accordingly (once again, another post for another time)).

When Agile is sold into a corporate structure from the top down, it's usually done by a smartly-besuited evangelist reminding the bigwigs how all their IT projects seem to fail miserably and that there's a better way. What I imagine isn't conveyed so well is that in Agile there are no absolutes in terms of delivery. That halfway through the project, the development team may decide to drop velocity to fix something that doesn't, on the face of it, appear to be broken. That they will be right to insist on doing so because they are the most qualified to make that decision. That working evenings/weekends is not the way to deliver anything. And most of all, that even in the very short term, doing it right is cheaper than doing it fast.

Successful Agile projects require acceptance from the bigwigs that projects are as driven by the people on the ground as the business and it's the level of trust and maturity to "support" rather than "run" their development teams that make or break them.