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.