A newspaper, by its nature, has key agile elements baked right into the very business process. Rapid, regular iterations. Constant feedback. Fixed deadlines, variable content. Corporate IT projects have no such advantages.

You mention that “agile is a mindset.” While mindsets are notoriously difficult to shift, they are like quicksilver compared to the steel-reinforced concrete of large enterprise funding models and business planning cycles. There are lots of corporate cultural forces that lead (as if by an invisible hand!) business and IT planners to continue to craft enormous giganti-programs, even in the face of all experience that ties the chance of success to the smallness of the effort. And given that the business case is too often hung on delivering the ENTIRE system (because, IMO, the business case is too frequently poorly thought out), challenging this approach and breaking the program down into manageable iterations can be quite difficult. What do you see as the key leverage points for prying this monolithic megaprogram culture loose?

1. Supply chains, markets and power; Cox, A et al 2002; ISBN 0-415-25727-1

2. Business Relationships for Competitive Advantage; Cox A et al 2004; ISBN 1-4039-1904-6

The second is a development of their thinking and puts their thinking into a practical framework that I found very compelling. He also provides a good critique of the different forms of relationship management and why one size does not fit all. I think that for agile to work one of the key ingredients is defining the relationships, and that definition must be consistent across all dimensions: commercial, legal, technical etc. Of course, much easier said than done!

As a result, many organisations find themselves at a pretty pass, a singularly vicious circle. They don’t believe in their IT departments because they “don’t deliver”. The departments don’t deliver because the requirements are unstable and hard to articulate. To solve this they need to think and act Agile. This requires them to trust their IT folks. But they don’t. Because they “don’t deliver”.

This is another reason why it’s much harder to embed agility in a large organisation. Every system depends on half a dozen others, and each forms a critical part of a hundred business processes – either the whole shooting match “goes agile” (which is harder anyway, because of all the integration issues), or most of the benefits are lost.

In my previous project we were lucky enough to be responsible for a single system doing one job with a limited user base. We initially saw all the cynicism you describe from users and “the business”, but they were prepared to let us give agile a try (after all, IT always deliver everything late and it never does what we want, right? What harm could a new approach do?)

At the first release planning meeting we eventually managed to get over the “just deliver everything, and come back when it all works” attitude, and agreed on the highest priority stories for the first iteration, but it was still very “them and us”, and the level of trust and cooperation was far from ideal.

Two weeks later, the agreed stories were released to the live, and they worked. The business people started taking notice. Another two weeks, another release, and they were pretty much agile converts. A few iterations later, when they asked for a small new feature partway through, and had it developed, tested, delivered and in use eight days later as part of the normal process, any lingering doubts had gone.

So the question is: how do we reproduce this journey at an enterprise-wide scale? Is it even possible? Maybe large-scale agility can only happen with many, semi- autonomous systems, rather than a few tightly-integrated monoliths.

Or maybe all it needs is a few small projects in an organisation to prove the benefits of a genuinely agile, cooperative relationship between business folks and IT. Perhaps agility will eventually spread across the business community to become mainstream, in the same way as it has over the past few years amongst IT people.

I, too, did journalism over 25 years ago. My case may have been a bit less ordinary than yours. I did performing arts criticism (mostly dance); and I wrote for a weekly, a monthly, and a quarterly. (One of my pieces from that final category got anthologized and makes for an interesting “feature” in my resume!) The “distortions” of those experiences led me to learn more about the daily newspaper; and, even though it lives on the cusp where the printing press meets the Internet, there is a lot of agility around the printed version. That is because, even when everyone knows that they get “the latest news” from broadcast media and RSS feeds, the daily paper still tries really hard to keep each print run up-to-date, anticipating the changes required to accommodate that hold-the-presses last minute scoop. Yes, the process still does not run at “Internet speed;” but the daily paper still runs on an ethic to being timely by being agile!