Jiri’s Notepad

With twitter traffic on low  and with my new assignment about to start, I decided it would be a good idea to break the holiday mood and finish off some blog posts that have been lying around as draft for quite some time. Happy new year to everyone!

Earlier this year I decided to have a look at lean and agile delivery methods. Why? They’re here and they are getting into a state where they are are bound to impact large delivery organisations. Agile, and to a lesser extent lean, seem to be all over the internet. Although it sometimes seems the subject is written about more often than actually practised, it still deserves a serious look.

But before going into the detail, it is important to spend some time on applicability. I will probably cover my views on Agile another time, but in short, I think Agile is not really too applicable in the context I most often work in, i.e. large projects run within a commercial customer-supplier relationship. It seems possible to use agile(ish) approach on a larger scale project run in-house, and some of my colleages have actually ran successfully smaller scale agile software development projects of a team size scale in commercial context. But doing both at the same time still seems to be too hard. (If someone saw a case study of where this happened, please let me know via comments).

Lean, on the other hand is a different kettle of fish:

1. It applies to a broader set of projects than Agile. It covers the whole life-cycle from inception to operations (i.e. when project delivers the value), and not only software development aspects, which is what Agile is applied to in practice
2.  Its application is about the mindset of continuous improvement rather than a one-off project that has, in my experience better chance of succeeding and producing some tangible results than a one-off project
3. Starts with customer value in mind, rather than a particular set of delivery techniques
4. It is process-based, but still acknowledging that skilled and motivated people are crucial, rather than espousing something over something else

In short, Lean is better suited to the large, commercial IT-heavy projects. People will sometimes counter-argue that Lean can not possibly applied to IT, because IT depends too much on creativity and one-off projects as compared to routine repetitive nature of manufacturing production in which Lean originates. I am not sure that really holds. With majority of IT budget currently being locked up in operations, the argument about the one-off nature does not neccessarily hold. Secondly, all manufacturers do do product development that is rather similar to IT projects. If there is Lean Product Development, why not Lean IT? That’s why I think that an intelligent reading of Lean can help to learn some things. This reasing cannot focus on techniques because these differ between industries, but needs to start with principles driving the organisation and management of work.