Last few days have been really busy for me, nevertheless even in such circumstances I still find some time to read up something - my latest lecture is Eric Ries’es "The Lean Startup" (http://www.amazon.com/The-Lean-Startup-Entrepreneurs-ebook/dp/B004J4XGN6/ref=sr_1_1?s=digital-text&ie=UTF8&qid=1376830687&sr=1-1&keywords=lean+startup). Book seems to be totally awesome (I’m still in the middle of it so can’t tell for sure), but there’s already something I’d like to write about: Genchi Gembutsu.

This Japanese statement means "Go and see for yourself". It’s considered as one of the pillars in "The Toyota Way" - collection of principles that has boosted Toyota’s production system. If you heard about Kanban, you should already know what I’m writing about. If not, get yourself up-to-date ASAP :)

Back to Genchi Gembutsu - it mainly refers to the importance of direct communication and cooperation with clients and users of what’s being developed. It’s about:

  • experiencing the scenarios that are being discussed
  • prototyping “in the field”
  • understanding the constraints and key success factors by learning the everyday activities product-in-progress will aid with

Some call it - Get out of the building” rule. I totally agree with all of that - these are clearly words of wisdom and they should be applied as widely as possible. But based on my recent experience I’d also extend their meaning:

  1. If you’re about to work using the technology / platform you have no prior experience with - start with PoC / go evolutionary. Don’t pretend you can plan it / design it. Having “remote experts” who will make “an estimation” is a waste of time. Put your actual hands on that thing!
  2. Technology can’t be learned in 30 minutes. If you’re making a 2 table (screen / page / queue / whatever)-big demo, you can usually easily create it with a knowledge gained by reading a tutorial on the web. But this doesn’t mean you can do the same with an enterprise-ready solution - it requires practical experience, gained by personally using given technology.
  3. Analogy is bullshit. PL/I developers can’t jump into .NET world “just-like-that” and perform like .NETters, even if they’ve spend 10 years on software development. They need to have hands on experience with the platform they’re going to use (in this case - .NET).
  4. Don’t forget about maintenance - your tech ops are your users as well. Find out personally if the final product will or will not be maintainable at all - sit with them side-by-side and go at least through typical and most burdensome scenarios.

To summarize - “go and see for yourself” - all the "official Point of View presentations" are useful only as a starting point for further read that will prepare you to start practicing. Don’t try to be "an expert" who "doesn’t know the details, but knows how to google them"

Share this post