Jiri’s Notepad

Apologies for slacking off from blogging, but there has been too many things to do. On the positive side, I had plenty of time to think about, think through and then re-think some of the ideas I started earlier this year. Now getting back to the subject  I started on before I took my writer’s break.

Starting Point
Lean is more of an operations philosophy rather than set of techniques and that’s why it requires looking first at its principles before dwelling on techniques. Let’s start with the principles set by Womack & Jones’ in the book that started it all:

• Specify value (or know what your customers want & need);
• Identify the value stream (or understand the sequence of steps leading to delivery of the end result within and without your organisation);
• Flow (make sure there are no stop-gaps in the process);
• Pull (reconfigure the process to be driven by customer demand as much as possible);
• Perfection (which seems to me very similar to continuous improvement).

Process Improvement & Its Costs

A quick search will show that the core of the techniques originating in Lean, that are actually used, focus on process improvement (principles 2,3).  It is hard to argue against process improvement, but the way that it is supposed to be applied to IT as part of Lean poses some interesting challenges.

Identification of the value stream is something popular and achievable even if it is not not exactly easy. Unless your operation is CMMI level 3 or above, your existing process are probably blurry or missing in places. To sort out the holes or blurry patches mean formalising, rationalising and agreeing the end-to-end process:

• This is possible for repetitive activities, such as live service support. ITIL gives a reasonable reference process framework to start with this. It is not the easiest process but certainly can be done;
• Solution delivery processes are harder as they fall largely into the Barely Repeatable Processes category. Firstly, projects are rather varied when seen from the viewpoint of an enterprise Process to design a new website is rather different from a process to decide how to upgrade your desktop, which is different from a process to improve your data quality). Secondly, big projects are not repeated that frequently. Considering large projects of each type happen perhaps once every 5 years, what benefit does a detailed process definition gives;
• Front-end process activities are also hard. For tasks such as identification of potential projects or initial project scoping, lack of detailed process is a benefit rather than drawback as it enables creativity and innovation.

If mapping the value stream is not easy, reconfiguring it for flow is even harder:

• Firstly, making IT requires more than just agile process (that is the boilerplate answer from Lean proponents in IT). There is a number of other things that you don’t need to care about as a developer, but that are really important from a management perspective, e.g. how capacity management is,  staff cross-training, how much spare staff do you want to pay whilst they aren’t doing anything useful and others;
• Secondly,  some of the biggest issues IT faces are upstream - facing off to the customer - rather than downstream. Making the upstream process flow hints on business-IT alignment, which is a subject that has been one of the consultants and academics’ favourite for almost 20 years, but still remains a problem.
• Thirdly, I would claim that as long as the IT organisation provides a good service to its customers (e.g. does not discourage them), it will be facing demand that is much less predictable and homogeneous that that of manufacturers. Under certain conditions, loss of flexibility due to over-optimisation may become a bigger issue than the perceived waste in the process.

Questioning the Benefit

Let’s now move to benefit side of the equation, starting with Womack & Jones explanation of the implications of the Flow principle:

when we start thinking about ways to line up all of the essential steps needed to get the job done into a steady, continuous, flow with no wasted motions, no interuptions, no batches and no queues, it changes everything: how we work together, the kind of tools we devise to help with our work, the organisations we create to facilitate the flow, the kinds of carreers we pursue, the nature of business firms (including non profit service providers) and their linkages to each other and society.

From the quote it is clear that the expected business benefit of Lean comes from eliminating waste. The problem is that waste in IT is much harder to identify and quantify, especially when compared to manufacturing which has a pretty large, single and visible source of waste called inventory. The people who interpreted Lean into IT  domain will tell you that IT process waste consists of unfinished, unneeded functionality, processes, multi-tasking, delays and handoffs etc. The issue with this list is that is rather long, full of small and often hard to quantify inefficiencies, rather than a large, single and visible one, which makes reducing IT process waste harder and its payoff smaller.

Considering the level of disruption when adopting Lean, lack of a single large category of benefit greatly erodes the benefit case and the support you can expect from the CIO or the board for an enterprise scope implementation.

In Summary

The implementation challenges combined with difficulty of developing a robust enterprise-wide benefits case, means Lean is not as groundbreaking as some of its advocate think. It still makes useful operational improvement approach that can deliver a reasonable business benefit. When take and go with it, it is important to consider the type of operation you want to apply it to and start where the cost/benefit ratio is the best. If you have a good relationship with business,  it may be worth addressing  your business architecture and portfolio management as  enablers of a wider application of Lean in IT delivery.

There are few more implications that I won’t go into here as I’m running out of space & time, so you can look forward for one more post on the subject.

This is a follow-up to Lean v. Agile.

Most of what I read about Agile and Lean is coherent and relatively believable, but I still can’t get rid of a feeling that there is something wrong. When I dug deeper, I then realised that the key sources of my cognitive dissonance (apart from over-generalisation and over-zealous marketing) is the fact that

1. Their benefits of these methods are poorly formulated and
2. The benefits of across-the-board implementation probably do not stack up if you judge it by implementation difficulty

But I am getting ahead of myself. To understand whether Lean and Agile are worth the effort, means understanding cost, benefits and limitations.

Case 1: Agile
To understand how is the business benefit a problem in the case of Agile, let me play out a scenario of me going to one of my senior IT execs asking for sponsorship for an internal project to drive Agile into some parts of our business. The situation is imaginary, but is likely to have happened if I tried to do something like this in one of my gigs during last 2-3 years.

Sponsor: “So what is this Agile thing about?”

Me: “It’s a reshuffle in our delivery process. We’d be basically using a kind of a  ‘Just in Time’ and make our delivery process smooth and produce a lot less documentation”.

Sponsor (looking at me with expectations): “and that would give us?”

Me (channelling David Nicolette): “Our customer will like the incremental delivery and demonstrations of working, value-add software, starting with the most valuable features as defined by the customer. From the earliest iterations we will demonstrate working software to their customer. Our customers have never received results that good from traditional method.”

Sponsor: “That sounds good in theory and I can see how architects would like that, but I am not entirely convinced if business would really see this as a major breakthrough. Sure, the responsiveness is an issue, but when push comes to shove, getting the new customer management system and cleaning out the duplicates in asset data is likely going to bea much higher priority. Money speaks you know and these two things will generate lots of revenue and lower costs.”

Me: “Ehm, um”

The problem is that if you prioritise a wholesale internal process change against delivery of new business capabilities (or an improvement of existing ones), it is typically business capability that wins over internal process. Having said that, there are definite situations where quick and adaptive delivery of new business or IT capabilities is critical. The only question is which one are these. And this will be constrained by the fact that some activities will be inherently difficult to make agile because of capacity, contractual, commercial or plain physical limitations. This means that the right questions relative to Agile arenot if it is worth it but,

• What are the niches in which delivery of small and frequent iterations are indeed business critical rather than desirable
• Which IT delivery activities can be realistically turned agile without impacting dependent activities

Case 2: Lean

Lean is a slightly different story. When compared with Agile, adoption of Lean in manufacturing industry shows  business benefits that would make my execs listen rather intently. For instance if you interpreted some of metrics quoted in Cliff Ransom’s A Wall Street View of Lean Transformation, you could surmise that in the context of an in-house IT organisation it could help to increase total output by 12% to 15% without related increase in cost.

That looks appealing, at least until you find out this  issue of Strategy+Business with Booz&Co consultants saying:

Lean manufacturing may not be rocket science, but implementing it is like advanced rocket science. There has been no shortage of initiatives intended to revive established manufacturing locations in North America and Western Europe. But the failure rates for plant turnaround in these areas are striking. Few manufacturing professionals today have any difficulty describing their vision of how excellent factories should operate. They are highly knowledgeable about the leading manufacturing techniques. Knowing the theory is one thing, of course; making it work in practice is quite another. Despite the fact that practically all of the relevant elements have been public knowledge for nearly 20 years, few brownfield plants have successfully made the transition to lean manufacturing.

So in case of Lean, the question worth looking at are:

• Do the factors that generate the kind of benefits Lean manufacturing companies benefit from apply to IT?
• Would implementation of Lean in IT be more or less difficult than in manufacturing?
• Is partial implementation of Lean in IT feasible and what kind of benefits it would give you?

If you find the above remotely interesting, stay tuned as the follow-up posts that I have in progress.

I received and started reading The Affluent Society this week and although I still reserve my opinion on the book, the first chapter is so great I thought it is worth writing up. As someone who has been always quite strong on following his own way, I can relate too well to its subject of conventional wisdom. Even if its language is a bit dated, it is pretty much on for modern social and business life of 2009 . If Galbraith was a cartoon strip writer rather than an economist, we might have had Dilbert 30 years earlier! Anyway, below are some most pointed quotes from the book:

What people proclaim and what they really mean

At the same time … originality remains highly acceptable in the abstract. Here again the conventional wisdom makes vigorous advocacy of originality a substitute for originality itself.

Why people don’t get tired of conventional wisdom

There are many reasons why people like to hear articulated that which they approve. It serves their ego: the individual has the satisfaction of knowing that other and more famous people share his conclusions. To hear what he believes is also a source of reassurance… Further to hear what one approves serves the evangelizing instinct.

In some measure, the articulation of the conventional wisdom is a religious rite. It is an act of affirmation like reading aloud from the Scriptures or going to church.

Becoming a pointy hairy boss

The high public official is expected, and indeed is to some extent required to expound the conventional wisdom…Expounding of the conventional wisdom is the prerogative of business success.

How conventional wisdom dies

The enemy of the conventional wisdom is not ideas but the march of events. The fatal blow to the conventional wisdom comes when the conventional ideas fail signally to deal with some contingency to which obsolescence has made them palpably inapplicable… At this stage, the irrelevance will often be dramatized by some individual. To him will accrue the credit for overthrowing the conventional wisdom and for installing the new ideas. In fact, he will have only crystalized in words what the events have made clear.

Why is conventional wisdom to the society

Few men are ever unuseful and the man of conventional wisdom is not. Every society must be protected from a too facile flow of ideas. In the communist countries, stability of ideas and social purpose is achieved by formal adherence to officially proclaimed doctrine. In our society, a similar stability is enforced far more informally by the conventional wisdom.

Benefits of peddling conventional wisdom

Nor is it supposed that the man of conventional wisdom is an object of pity. Apart from his socially useful role, he has come to good terms with life. He can think of himself with justice as socialy elect, for society in fact accords him the applause which his ideas are so arranged to evoke. Secure in this applause, he is well armed against the annoyance of dissent. His bargain is to exchange a strong and even lofty position in the present for a weak one in the future.

Images courtesy of Wikipedia & Ol.v!er