There’s no real point in having “Agile” IT departments in waterfall business contexts; in fact it isn’t even possible. Agile is first and foremost a mindset; it leads to a way of working; the way of working has a number of desirable outcomes; many of the desirable outcomes are manifested in successful IT implementations.
But there’s no Agile without active and enthusiastic business participation. Which leads to a problem. It is not uncommon to find significant pockets of organisational cynicism about IT; partly as a consequence to the boom and bust of the late 1990s, partly in response to the Battle of Professions, and partly resulting from poor experiences with IT in the past, there are many executives that find it hard to trust IT. As the saying goes:
Perception is reality distorted by the lens of experience.
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”.
How can we get around this? By educating everyone. Which is why I post regularly about Agile, seeking to describe what happens in analogues, so that we can achieve a greater understanding of what Agile means.
So today’s sideways look at Agile is rooted in journalism. Let’s take a look at what happens in a weekly magazine.
- The time and date of production are immovable and regular. Every week, at a fixed time, the presses must roll and the magazine must hit the neswstands and the postal services.
- So there’s always an immovable deadline, as a result of which we see a number of desirable behaviours, outlined below.
- The first is an understanding of the critical chain of events that would lead to the achievement of that deadline, working backwards from the desired outcome. When the page proofs must be okayed. When the pages must be made up. When the galley proofs must be okayed. Editorial copy deadlines. Advertising copy deadlines. You get my drift. Note that these sub-deadlines are independent of the content of any particular issue.
- In similar fashion, there is a stream of activity that distinguishes a particular issue from another. The theme of the issue, the editorial direction, the cover story, the cover illustration, content-driven layout and graphics, and so on. These too have deadlines, with sub-deadlines easy to infer.
- The deadlines implied in points 3 and 4 often interact with each other, making planning and predictability very hard. Unless some steps are taken to reduce complexity of interaction.
- Which brings us to a level of relentless standardisation. Advertisements are taken in standardised sizes, thereby simplifying the layout process. Style guides are drawn up in order to improve the quality and consistency of the output, reducing error rates to do with spelling and punctuation, with fonts and formats, with look and feel in general.
- There’s always a modicum of stuff ganging aft agley, so there have to be some contingency measures, some Blue Peter things-prepared-earlier. Articles kept in abeyance for that time when you need to pull an article in a hurry. Arrangements with customers for discounted “late-availability” advertising slots. Ready-to-use topical filler.
- And all this happens with teams of people working together in an environment of high pressure. Poring through drafts of what each issue looks like, critiquing mockups, pulling out all the stops to make deadline, then celebrating the outcome.
What do I know? I haven’t really been a journalist for over a quarter of a century, but that’s what it was like back when. And the parallels are interesting.
- “Requirements” captured by iteration through a series of drafts.
- Focus on outputs rather than inputs, a clear understanding of the critical chain of activities and the underlying constraints.
- A base of reusable components made available in a predefined architecture.
- Slack built in for the unexpected rather than the mismanaged.
- A willingness to throw away and start again while treating the deadline as sacrosanct.
- A distributed operation with staff all over the globe, yet a production process that focuses very heavily on facetime and collocation.
- A consistent ratio of fixed and predictable to volatile and unpredictable.
- A number of tasks that can be done in advance, a number of tasks that must be done in advance, and a number of tasks that cannot be done in advance.
- Creative activities underpinned by processes steeped in regularity and standardisation.
I think we need to keep looking at Agile business practices that have nothing to do with software, in order to learn more about how we educate our business partners.
Business agility is no longer a nice-to-have, it is an imperative. It can only be arrived at by implementing Agile processes from cradle to grave, from soup to nuts, across the board. Agile is not about IT per se, but about business outcomes. So we need to educate educate educate.
Comments welcome.
JP, I suspect that only the most rabid positivist would still hold to the believe that the lens of experience distorts reality! The rest of us believe that it is through experience that we CONSTRUCT reality and through Mead’s symbolic inactionism that the construction is a social one! Then again, those rabid positivists are the only ones who believe in hard-and-fast rules. The rest of us know that we are always bending those rules (if not breaking them), because that is part of the sloppy nature of “real life.”
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!
Our large-company clients almost all distrust their IT departents, and with good reason. But one of the main issues is the requirement to apply ‘systems’ and ‘standards’ (security, governance, business continuity, HSE, data protection, etc.) each of which leads to a tick-list of requirements that have to be built in to every project. It’s difficult to be agile when you have to fill in so many forms.
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.
The question is valid beyond the enterprise and its IT / Operational folk. It is a question that extends across the whole of the supply network. I substitute “agility” with “engagement”. The key demand of agile working from downstream business partners is that there is true engagement. This means that the IT folk have to truly engage with operations to understand their business. Conversely the operational folk have to put time, effort and energy into engaging with teams considered to be “suppliers”, either internal or external. Now is it possible to force this engagement? Probably I think through committed leadership across all functions as well as having shared vision / common purpose. Now here’s the crunch: to achieve this seems to me to require open, collaborative relationships. One of the questions I ponder on frequently is how do you balance having open collaborative relationships against the almost innate traditional supplier-buyer power based behaviours we observe in business? Its tough to see yourself in the supplier position (internal or external) brow beaten down on price to be then told that “we’re going to work in an open collaborative way”. It just seems inconsistent. So my argument is that the question about agile working is one about building the right type of relationships whether they be within or outside of the business we operate in – an interesting subject in itself. Do I believe that this type of relationship is the only one that we should use within business? Absolutely not. Buying commodities is different to buying or building strategic assets. Where goals are critical it seems that a re-think is required in some behaviours to get the right outcomes. Don’t know whether you’ve come across him JP, but Andrew Cox from Birmingham University writes some intersting stuff about business relationship management. I can let you know the references if you want.
MNB, I’d love to look into the Andrew Cox references, I haven’t really come across him. So please go ahead. Thanks
There are two:
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!
Fascinating. Thanks. I’ve been working on taking some of the ideas in Erik Brynjolfsson’s Theory of Incomplete Contracts and applying it to a world of enterprise collaboration, so this seems to be slap bang in the middle of that stuff.
Again, one I’ve not come across. Will have a look! Thanks.
JP,
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?