Jiri’s Notepad

Lean and Agile are often mentioned in the same sentence and many people assume they are similar. Admittedly, there is an overlap between the two methods – mostly in their focus on pull scheduling, just-in-time techniques and people - but that is where I think the similarities end.

Lean is more of a set of general operational management principles. Although it was originally developed for manufacturing it can be applied to other contexts, including services, or software development. As mentioned in my earlier posts on this subject, in IT Lean is probably best suited to live service support, although under certain circumstance it probably could be used for solutions delivery.

Agile on the other hand is a set of techniques that comes specifically from software development. Lean is more of a manager’s toolbox; agile is more of a maker’s toolbox. There are people out there who are trying to take Agile concept further, but I am personally too convinced about this as circumstances under which Agile works is much more specific.

Agile is often getting bad reputation. Some of that is caused by too much preaching that can be very offputting to the audience (including myself). Other times, Agile is often an excuse for shoddy delivery. Despite these negatives, my view is that using Agile can be very beneficial as can give you:

• Quick delivery of software features … due to trading off a size of the delivery unit for elapsed time to deliver it

• Solutions that are more fit for purpose… thanks to an increased quality of requirements achieved via disciplined involvement of the user

• More flexible incorporation of changes in requirements … due to generally short timescales

• Better quality of the constructed product … due to continuous integration

However, to get these benefits, one has to leave behind wide-sweeping generalisations Agile evangelists annoy the rest of the world with so often and define the right circumstances under which the approach can work. I would argue that as far as the right context, there are roughly three points that need to be thought of:

1. It needs to be used for the right type of problems

2. Delivery team needs to be very clear about the scope of the agile processes and where they integrate with non-agile ones

3. Customer and the delivery team need to find working arrangements to help deal with uncertainty in regards to budgeting

I will look at these three problems separately in the next parts of this series.

There is a small possibility that this website will soon disappear. I bought the domain several years ago from a small reseller of domain registration services and unfortunately that company went out of business. I now have some difficulty renewing the domain, only a few days before its expires.I hope I will manage to resolve it, but in case I don’t, I’m most likely to buy a different domain (name to be announced here).UPDATE: I have managed to resolve the issues and have the domain back. Expect some real posts in near future

(…continued from Deconstructing Lean’s costs and benefits)

I like Lean’s coherence and its focus on methods of achieving business change,  but I have some doubts about applicability of its mainstream form to IT. This post describes why and sketches out some speculations about alternative models to use for IT.

What is waste
To help you understand why I think the mainstream Lean may not work that well for IT, I would like to revisit Lean’s concept of waste. Because systematic and continuous elimination of waste is how Lean achieves its results, the decision on what counts as waste is the key to results you get. Yet, considering how important the concept of waste is,  its definition as applied to IT seems to be rather dubious.  There are the seven types of waste, but those apply to manufacturing and its translation to IT services seem rather questionable. You even can’t compare categories of waste between different authors. Go and have a look at Poppendiecks and John Bicheno’s definitions (quoted in Lean Services). You will realise they are so different you even can’t even put them in the same table for comparison purposes!

The difficulty is that that the definition of waste is context specific, and therefore varies across industries, companies and possibly across functions. For a start, it is quite obvious that types of waste will be different between manufacturing and service industries. Inventory is, for instance, one of the biggest types of waste in manufacturing; unfinished code and documents may be a nuisance, but their cost is nowhere near a courtyard full of half finished products. But the types of waste will also differ even between different types of service organisations. What can be thought of as waste in transaction-oriented businesses (think haircuts, Matalan suits, Wagamama meals, … or IT live service support) will be quite different from tailor-made business  (e.g. interior design, bespoke shirts service,… or many IT projects).

To illustrate my point, let me define a number of examples of waste in IT, all of which will be real and yet none of them will fit the categories of Lean Software Development: Loss of credibility due to incapability to deliver projects predictably,  delivery of projects that are not needed, use of inadequately skilled people, people on standby waiting for their turn on the project, solutions that do exactly what business users ‘want’, yet fail to meet the real business need, solutions that do exactly what is the business need, but are not supportable, etc. etc.

It may seem a list like this is arbitrary… that’s it… until we revisit the first Lean principle.

Customer value

My main point of contention with mainstream lean is its preoccupation with process, and its effficiency, which are to me only one of the many possible customer values. If you want to disagree with efficiency as a central point, there is a need putting up some framework around customer value to help deal with its seeming randomness.

There are undoubtedly several ways how to do this; the framework that can be useful in our case is Treacy & Wiersema’s value disciplines. The idea is simple: every organisation has three choices as to where to create long-lasting value: customer intimacy, product leadership or operational excellence. According to Treacy and Wiersema, every organisation should aim to be excellent in one of these disciplines and aim at doing OK at others.

I would argue that what is considered waste will differ depending on which value discipline you will see as core:
- Operational excellence - losses in productivity
- Customer intimacy - any issues affecting customer relationship
- Product leadership - failure to use creativity, loss of innovative ideas

This makes clear (at least to me) that mainstream Lean, including its techniques, is most suited to operational excellence problems. I have not thought about this too much but I suspect that other value disciplines will need rather different methods to address their ‘waste’ (probably more in a category of  relationship building, consulting skills, communities, individual skill, though there is undoubtedly going to be some process too). Having said that, there is still a space to use Lean to get to an acceptable level of efficiency, at which it is invaluable.

Please add your comments if you disagree or have additional insights.