Sunday, December 28, 2008

Kanban tidbits

Here are some tidbits

  • "Kanban", the Japanese word translates to "signboard"
  • Taiichi Ohno developed Kanban
  • Toyota management were looking at ways to reduce/eliminate waste. One of the ways that they discovered to eliminate waste is by reducing the inventory, and to build the product "Just in Time". They were inspired by the supermarket system because supermarkets stocks only what is needed for their customers and this is based on buying patterns.Customers can walk in with confidence that the product is available, and choose whatever they want. The items are replenished as and when the stock goes down and everything happens "Just in Time"
  • JIT manufacturing was the brain child of Kiichero Toyoda, founder of the Toyota Motor Company
  • Kanban is a means through which JIT is achieved
  • Kanban is more of an implementation process rather than a planning process

Monday, December 08, 2008

Agile means no documentation - common misconeption

Before I begin my Agile training programs, I provide an opportunity for the participants to share their understanding about Agile. Most commonly heard definition include
"Agile = No Documentation".

This is the most commonly misused and mis-communicated definition. I don't blame the newbies however it is the value

Working software over comprehensive documentation

that has been defined at a higher level of abstraction by Agile Manifesto that creates such a misunderstanding coupled with inexperienced Agile evangelists.

For most of us, as soon as we hear the word "documentation", the first thing that comes to our mind is the "Microsoft Word" document, and the ISO-CMM level prescribed requirement/design documents that we might have written in the past, isn't it ?
So, when a newbie reads the documentation related value from Agile manifesto, they generally assume that one needs to dump documents, and rely purely on running code(working software). However, Agile manifesto is trying to say that "prefer" working software over (not abandon) comprehensive documentation. What it means is, try to create working software, because this is the only thing that adds value to the customer's business and not the extensive documentation.
Next question I generally get is "if we don't do extensive documentation, then how do we retain the knowledge ?', "what is the contingency plan for attrition as this would result in loss of precious knowledge ?"
My take on this is, "do document" in whatever way you can to protect the customer/yourself/project to retain knowledge. Agile value is trying to say that, don't do documentation for the sake of doing it, however document information from the context of adding value to the customer.

In one of my past experiences working on an Airline and defense related projects, we had applied Agile methodology, and found that extensive documentation was indeed a must to conform to various standards. We wrote necessary documents as it added value to the customer, and customer was willing to pay for that.

Documentation not necessarily mean capturing information on "Microsoft word" ! one could write something on the white board or flip chart and take pictures using a digital camera. The images stored could be considered as a project document. Similarly, recorded videos, good java docs(for example), screen captured images, etc could well be considered as project documents.