FIND InnoNuggets


Tuesday, January 15, 2008

Ohno Circle in Software Development

My friend Suresh asked an important question in the Yahoo group called NWLEAN ( as follows:

i am in a group that is trying to spread lean in our software services company... i am often left wondering how to do real gemba (go see yourself) in this sort of set up, where the work is virtual and not visible! do you have any experiences of having done this? pls share!

I must say this was really an important question - I asked myself - my response is the following

Hi Suresh,

Lets us look at what is really Ohno Circle (for the uninitiated Ohno Circle is described here) in software development and who should be standing in the Ohno Circle for software projects or software intensive projects? In the non-software, physical world of manufacturing, there is a physical movement that is seen as it happens and flows and value stream decelerators can be observed through non-involved, objective observation. However, in software development as Mary said it is not really possible for someone in the ohno circle to observe, especially if the person has not developed software on his/her own.

This brings to the question how to create Ohno Circle in software? Well, I personally would recommend become the software, that is being developed. When you become the software, you can feel the pain of the software, how much it is sent from one person to another, how much it is chopped and then re-integrated. I have, my personal experience of becoming a software bug, a software project response typically called the RFP response, have also become an ERP system. The value stream that comes out when I become the subject myself is amazing, in its all gory details, i get the emotional pain of the software being developed as it is being worked on various software developers and engineers.

Of course it is easier said than done, but with practice one can I assume become the software that is being developed. Of course it requires tremendous amount of co-operation from the developers as one needs to communicate with all humbleness and dignity that it is not, and I repeat NOT an evaluation of their productivity or assessment of their capability. It is a study to understand what really happens in the software development scenarios and to reduce what I call project cacophony - which is exactly the reverse of Takt delivery (seems to be more prevalent in software development projects) - How close to Takt delivery the project is depends upon whether the design has been crafted as independent units of usable functionality. If yes, then it can be made closer to Takt delivery, else we get into cacophony.

Coming to who should become the software- who should stand in the ohno circle. In my opinion one by one all the team members should stand - and over a period of time they understand the FLOW needed in the software development projects.

Post a Comment

My Book @Goodread

My GoodReads