What can ‘Agile’ tell us about how Business & IT could work together better?

I blogged recently about the need for joint collaborative business-IT teams in the early phases of business change or business transformation exercises. Anyone who's had exposure to IT software development will recognise similarities in the criticisms I made about current dysfunctional approaches to the criticisms of the old approach to software development, the so-called waterfall approach.

In this methodology of course, the requirements were gathered by one team before the analysis and design was carried out by another, before the development carried out by another, before the testing by another etc. It was real manufacturing production-line thinking about one group of specialists working in isolation on the task they have expertise in, before passing the work ('over-the-wall') onto the next isolated group of specialists.

It’s now well known and accepted that it never worked very well for IT software development and implementation. My feeling is that this is similar to the logic in my comments on how we need to now realise that a silo-based 'over-the-wall' approach doesn’t work well for business-IT engagement in business change design exercises either.

Of course in the software development world iterative, and more recently 'agile' methods have come into being as the dominant methods. Agile software development techniques are founded on principles like collaborative working, early engagement, iterative design and delivery, and frequent rationalised reviews. Good practices like this have demonstrated that they can help deliver more relevant software solutions that are (for example) more likely to achieve what was actually needed rather than what was initially thought to be needed, to deliver what was desirable to the user rather than the designer, and to deliver what was actually achievable rather than what was thought to be reasonable.

Now I'm not going to repurpose the word 'agile' here to my points on joint-teams, as many have borrowed that word for other domains already. But the commonaility in intention and concept is interesting. And even if (as some would point out) agile didn't really invent these concepts, for me it still illustrates some good practices that we actually need for Business-IT engagement approaches on a broader level beyond just software development.

Technorati Tags: Agile Business Relationship Management Enterprise IT