Category: Four pillars

How risk management affects agile approaches

As promised, I ordered a copy of Michael Power‘s new book, Organised Uncertainty. And I’ve given it my first riffle-through, preparing my plan of attack for the next wave through the book. It’s a fascinating read for people of my persuasion. [If you don’t know what my persuasion is, then please take a look at The Kernel For This Blog and About This Blog, both of which should be accessible at the top of this page, depending on how you got here.]

Power quotes Douglas and Wildawsky as saying in 1982:

Can we know the risks we face, now or in the future? No, we cannot: but yes, we must act as if we do.

Later on, Power states ….”More importantly for the purposes of this book, the emphasis of communication was increasingly on the process of risk management rather than on its content.”

I came across early vestiges of this, of the impact of reputational and similar risks on organisations and their management structures, very early on in my project management career. [And I guess I got so frustrated by what I saw that it was only natural that I found my way to The Audit Explosion, and much later on to The Risk Management of Everything. It was only a matter of time before I took steps to meet Professor Power; we had lunch sometime in 2004, and now, having read his latest book at least one, I realise it is time to meet him again.]

Until I read Organized Uncertainty, I never really made the connection between this overgrowth of risk management and the distrust of agile management techniques. I never really understood the Emperor’s-New-Clothes-Syndrome. Now, slowly, light is beginning to dawn, to leach into my landscape.

Once you switch focus from content to process, agile techniques don’t stand a chance. Agile in a “content” perspective leads to the Baconian “A man that starts with doubts shall end in certainties”; agile in a “process” perspective leads to the other Baconian statement “A man that starts with certainties shall end in doubts”. These two positions are polar opposites.

As Douglas and Wildawsky stated, people act as if they know the risks they face despite not knowing them; they then disparage people who act to discover and potentially mitigate hitherto unknown risks. The Emperor’s New Clothes.

More later.

Continuing to learn from my children

Information overload is of the commonest pushbacks against the take-up of social software “behind the firewall” in enterprises. I’ve always believed in “filtering on the way out rather than on the way in”. Now that’s great in theory, but the practice gets harder as the firehose grows in diameter and I get older. As a result, I’m always on the lookout for different ways of visualising things.

Recently I was pottering about at home while my youngest child (Hope, my daughter aged 9) was surfing, and I went to take a look at what she was doing. She was happily using StumbleUpon, one of my favourite tools, to go she knew not where. [Yes I do make sure that inappropriate content is blocked].

And she stopped at this video. As usual, I’ve made it available on my VodPod in the sidebar as well. [Incidentally, if you’ve ever wondered why I VodPod at the same time as providing the link, the answer’s simple. If you want to find the video link later you would normally have to search through my archives for the right post. Instead, by my using VodPod, you can get here straight from the sidebar.]

I think the Animusic videos are great ways of giving people a chance to visualise music, there’s something vaguely Heath Robinson-meets-Mozart about them. I will ponder over this for a while, trying to consider where else this type of imagery would come in useful.

Visualisation techniques are essential tools when dealing with information firehoses, and (IMO) are far more effective than filtering techniques. When you can add decent collaborative filtering, recommendation and ratings mechanisms to good visualisation techniques, the world is your firehose.

More on 21st century adoption curves

Looks like a week is a long time in politics and in social software. Last week I wrote about using Facebook as a proxy for looking at 21st century adoption curves. So far, I haven’t been able to collect information about usage or about age breakdowns, but I’m sure that will be possible soon enough.

In the meantime, let’s see what’s moved:

So let’s see. Every single classification moved up at least 10% in a week. Overall the apps were up by a quarter, or averaging over 50 new apps a day. The biggest mover was Politics (!), always an interesting trend in social networking. What fascinates me is the top 5: Politics, Events, Business, Education and Mobile. Between them these 5 classifications added about a quarter of the new apps.

Politics, Events, Business, Education and Mobile. Hmmmmm.

More later.

Failing at the edges of the network

David Smith, one of the first people to comment on my blog, remains on my everyday read list. Recently I noticed he linked to something I’d written on risk management, and I moved via his blog to Bruno Guissani ‘s commentary on Aula2006, including his coverage of Clay Shirky‘s session.

There are some real gems in the two posts I’ve referenced above, I urge you to read them. One that struck a particular chord for me was the following, from Bruno’s piece:

Shirky’s argument goes like this: when you explore really new ideas, it’s pretty much impossible to tell in advances the successes from the failures. The business world today is geared towards “optimizing” the innovation processes in order to reduce the likelihood of failure. That’s a significant disadvantage when compared with the open-source ecosystem, which “doesn’t have to care” and “can try out everything” because “the cost of failure is carried by the individuals at the edges of the network, while the value of the successes magnifies and adds value to the whole network”. “Ecosystems such as open-source get failure for free, and that produces some inevitable unexpected big successes – the Linux operating system – that nobody could have predicted but end up changing the world”

The cost of failure is carried by the individuals at the edges of the network, while the value of the successes magnifies and value to the whole network. Sometime ago I commented that opensource people tend to solve problems first and foremost rather than develop complex business models. I think that what Clay says is more articulate and far more elegant.

If you disaggregate the cost of failure it will drop. If you reduce the cost of failure then you increase the capacity to innovate. If the innovation is carried out by individuals at the edge then those costs drop as well. As all these costs drop there is a natural speeding-up. A lovely virtuous circle with the right feedback loops.

My thanks to David and Bruno and Clay, they’ve given me a lot of good food for thought.

Musing about creation, preservation and destruction

I’m fascinated by the process that anyone takes to shut down an application. I think there’s a lot I can learn from it, so every chance I get I watch very carefully.

For a while, maybe a decade ago, I was pretty much obsessed by it. At the time, I was working at the bank, and we had a large bunch of apps scheduled for retirement. So much so that we created a role called Head of Decommissioning, and only partially tongue-in-cheek, we used creation, preservation and destruction to describe development, maintenance and decommissioning. Why destruction? Maybe it’s down to my Saivite roots, who knows?

Anyway, here are a few rules about application “destruction”.

1. People will push back much harder than you would have expected. Organisational inertia and pushback against applications shutdowns quite often exceeds the pushback against new applications. I guess it’s a version of loss aversion. Or maybe it’s Stockholm Syndrome.

2. Time and cost estimates will always be greater than you would have expected. As a result of rule 1, something very strange happens in large organisations. A constant emerges, let’s call it the Shiva number or constant. The Shiva number can be represented as nX. It doesn’t matter which application you want to shut down, the answer is always n months and X million. At the first organisation where I came across this, n was 18 and X was 2.5. Consistently. Reminds me of the pre-crash internet business plans. Everyone projected revenues of $75m in 3 years, turning cash-positive only in year 3, and everyone showed an exit valuation of $1bn. Didn’t matter what the business model or segment was.

An aside: The Shiva number is a constant. Why? I think it has to do with spans and layers and risk-averse intermediaries, I think it has to do with the same people being asked similar questions and being able to reply regardless of context. That’s why I think it is only constant within a specific firm. If I am right, then n will tend to be similar in range everywhere, whereas X will vary by firm.

3. The actual time and cost will be considerably less than original estimates. Once, I was faced with a Shiva number and I couldn’t afford the time or the cost. And while I was mulling over what to do, the machine room had a flood. The app was irrecoverable,  it ran on hardware whose end-of-life was somewhere around Bishop Ussher time. And magically life continued with a shoestring replacement. And the moral of the story? Before you ask for estimates for shutting down an app, run a scenario where the app dies in a natural disaster or similar incident. Ask the team to come up with the fastest route to recovery. Price that route, that’s the best decommissioning price you’re going to get.

4. Declare victory on shutdowns one month after shutting them down. Keep absolutely shtum until then. Given the loss-aversion-driven estimation issues and traditional organisational inertia, there will always be someone over whose dead body you will have to cross before you shut his precious app down. Be nice to him. Tell him gently and politely about the shutdown, almost as if you were broaching a bereavement. Be diplomatic and tactful. Then, just as he begins to throw his toys, become even gentler. And in that extremely gentle tone tell him you did it a month ago. Works wonders.

5. Look out for Klingons. Particularly with enterprise architectures that specialised in DRM 1.o, otherwise called bad EAI, apps talked to each other using a variety of codes and reference data. Quite often, it was the largest app that defined the code set, and everyone else just had to go along with it. And quite often, even after the large app is as defunct as the erstwhile parrot, its codes live on.

Thankfully, all this is pre Web 2.0. One of the things that Web 2.0 gives us is the ability, the incredible freedom, to decommission apps at will, without having to create humongous and meaningless plans first. [Sean, see where I was going?] The cost of creating, preserving and destroying apps has begun to go down sharply. Which can only be a good thing.