Category: Four pillars

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.

1. 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.
2. So there’s always an immovable deadline, as a result of which we see a number of desirable behaviours, outlined below.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.

Hugh pointed me at William Hurley’s post Seven Reasons Microsoft Loves Open Source. I don’t agree with many of the reasons, but that is not the point of this post. Maybe some other day.

I agree vehemently with one thing William says. In reason 6, he makes the point

Microsoft doesn’t fear open source; it fears what the competition can do with it.

This is true for all companies, and for all Because Effect infrastructure. By itself not to be feared (the With); yet feared for what your competitors can do with with (the Because Of).

The moral of the story is: As infrastructure moves from the With state to the Because Of state, make sure you move with it. Because if you don’t and your competitors do, you’re on the road to Toast.

You’re right, this is not something people regularly associate with me; at school, my precis used to start three times the length of the original.

John Howard set a new record for comments on this blog by posting a wikipedia link as his comment. I loved the comment and the link.

It brought a number of other examples of brevity to mind, examples I savour and enjoy. So I thought I’d share them with you.

1. Peccavi: “I have sinned”, Charles Napier’s legendary one-word message signalling the conquest of Sindh province. I believe it to have been a hand-carried message rather than a telegram.

2.  Adam/Had ’em : Ogden Nash’s delightful couplet On The Antiquity of Microbes.

3. On the Advantages of Sleeping Alone: Groucho Marx’s opening chapter in his book Beds, consisting of the chapter heading, a blank page, and a footnote from the editor indicating that the author had refrained from submitting any material for the chapter.

4. Quite right is all right, all right is quite right, but quite all right is all quite wrong: HW Fowler showing his scorn for the phrase Quite All Right.

5. The inane goddess (6): The ultimate cryptic crossword clue. Closely followed by Australian orgy (10). I first read them in Anthony Grey’s Crosswords From Peking, but I’m not sure whether they were of his making. He may have illustrated his points with the clues.

6. Satisfactory: Nero Wolfe at his best.

Any other brevity favourites out there?

[Admit it, you were just about to accuse me of not knowing how to spell his name. But before you do that….]

This post is about a different Steven King, and about a film he produced in 1972, called Computer Networks, the Heralds of Resource Sharing. I’d heard of the film many years ago, in the early 1980s, but for the life of me I couldn’t find anyone who had a copy. And I’d forgotten all about it. Until yesterday.

Yesterday, John Howard (thanks! John) commented very briefly on a post I’d written on information filtering; all he did was leave me with a link to the wikipedia article on Postie. As he would expect me to, I read it again, and the relevance of Postel’s Law (or the Robustness Principle) to the discussion became clear.

And, as happens with these things, I read on. And wandered aimlessly around the article and its environs, in a way that one could not do with the physical construct of the information. And while wandering aimlessly I came across the precise video I’d been looking for, which features Jon Postel very briefly.

Unintended consequences of the blogosphere.

I’ve loaded it on to my VodPod, visible on my sidebar, and also left you a link to the Google video here. If you want to get a contemporaneous idea of what people expected to do with the ARPANET and early internet, it’s definitely worth watching. I found it spellbinding. But then I’m weird that way.

By the way, the video is around 26 minutes long, there appears to be about four minutes of “nothing” at the end. You have been warned.

I said I would post further on David Weinberger‘s Four Strategic Principles as outlined in his new book, Everything is Miscellaneous .

David’s first principle is to filter information on the way out, not on the way in. I’m still working on it, masticating it, there’s some work involved, but I like the early flavours I can taste. So I thought I’d share with you the kind of stuff that went through my head when I saw that sentence and read what followed. Humour me.

1. In order to filter on the way in, we need to have filters, filters which can act as anchors and frames and thereby corrupt the flow of information. We’ve learnt a lot about anchors and frames and their effect on predilections and prejudices and decision-making. With David’s first principle, we reduce the risk of this bias entering our classification processes too early.

2. I think it was economist Mihaly Polanyi  who talked about things that we know we know, things that we know we don’t know and things that we don’t know we don’t know. Again, filtering on the way in prevents us gathering the things that we don’t know we don’t know.

3. The act of filtering is itself considered necessary to solve a scale problem. We can’t process infinite volumes of things. But maybe now it’s okay to be a digital squirrel, given the trends in the costs of storage. [Sometimes I wonder why we ever delete things, since we can now store snapshots every time something changes. We need never throw away information]. Filtering on the way out becomes something that happens in a natural-selection way, based on people using some element of information, tagging it, collaboratively filtering it.

4. I like the idea (proposed by David) of there being no need to throw stuff away. You just have to not-find it. If you can’t find it you might as well have thrown it away, and if it all costs the same then who cares? Reminds me of the Douglas Adams definition of flying: jumping off a tall building and missing.

5. Collecting information this way is fine, but it has no value unless someone tends to it, someone looks after it. So maybe I shouldn’t be thinking ‘not-find’ and instead I should find ways of incentivising people to clean up their information. Maybe there is a Silent Spring for information. I somehow like thinking of bad DRM and proprietary tools, methods, structures and standards as weeds that strangle the life out of good information. But then I would, wouldn’t I? Walled gardens have the worst sort of weeds.

Just musing. Comments welcome.