* Gemba (現場) in Japanese means “the actual place” or “the real place”
* Kaizen (改善) in Japanese means “improvement”

In business, Gemba refers to the place where value is created and the general notion is that the best improvement ideas will come simply from going to the Gemba (‘bottom-up’ vs. ‘top-down’)

The ‘Gemba Walk’ is an activity that takes management to the front lines to look for waste and opportunities a.k.a. to practice Gemba Kaizen which is similar to the “western” concept of MBWA (Management by Walking Around)

My view

As I have posted before “To master (/control) a software project you must be able to breathe the project – inhale the chaotic butterfly movements around you and exhale with the needed adjustments…” (The Software Chaos | Feb. 2008)

Although we wish it will be different… the best optimizations are “simply” very deep into the details and I have found out that a daily practice of ‘Gemba Walk’ can be very helpful to your project “well-being” (and I must admit that it took me several years to find out that my weird walk actually had a Japanese name/theory ;)

“less important than a gnat’s toot in a hurricane” :)

Seven tips for an healthy ‘Gemba Walk’ / MBWA

1. Visit everyone
2. Go alone – Daily standup meetings aren’t enough
3. Don’t bypass middle management e.g. don’t change priorities, requirements or design
4. Observe, ask and LISTEN
5. Be genuine, have fun and strive to catch your engineers doing something right and not something wrong (you are not the “fun-police” ;)
6. Share your dreams and vision
7. Don’t “disturb” the Gemba – Timing is everything…

What next?

1. Correlate the Gemba / ‘bottom-up’ observations with your ‘top-down’ understanding
2. Identify waste, risks and opportunities
3. Kaizen – Improve and optimize accordingly

Good Luck!



________________________________________________
Random News from BBC – Gauguin ‘cut off Van Gogh’s ear’

“Vincent van Gogh did not cut off his own ear but lost it in a fight with fellow artist Paul Gauguin in a row outside a brothel”

In this context, last summer I wrote, coined and trademarked the Pessimistic Developer Paradigm.

Early this week I have interviewed a very interesting dude* who saw this old article hanging on my office and introduced this amazing poem by Robert Graves which I must share in this pessimistic context…

In Broken Images (by Robert Graves)

He is quick, thinking in clear images;
I am slow, thinking in broken images.

He becomes dull, trusting to his clear images;
I become sharp, mistrusting my broken images.

Trusting his images, he assumes their relevance;
Mistrusting my images, I question their relevance.

Assuming their relevance, he assumes the fact;
Questioning their relevance, I question their fact.

When the fact fails him, he questions his senses;
when the fact fails me, I approve my senses.

He continues quick and dull in his clear images;
I continue slow and sharp in my broken images.

He in a new confusion of his understanding;
I in a new understanding of my confusion.

* Thanks Tomer and Good Luck!

I will argue that pareto principle conceals one of the most important princples in software (and not only in software) management – Don’t try to do more. Just do more of the right things!

exempli gratia

* Don’t invest too your time in dark software corners since the same principle will catch you with investing 80% of your force with only 20% value (e.g. What will happen if someone disconnect the database network cable 1 minute before DST transition… etc.)

* Don’t over design since you will bump into the 80% investment for only 20% value again – Don’t drill the holes for air-condition system before you have one, since you might find yourself a bunch of holes in the wall…

* While planning, always ask yourself if you can do more for less and try to find that thin-gray-line that cross the 21% effort for the 81% value* - try to identify how to invest minimal effort (~20%) to create enough (~80%) business value.

* In performance tuning you want to find the silver bullet that with minimal effort (let’s say 20%) solve 80% of your issues (a.k.a. low hanging fruits)

* Workforce wise – Jack Welch’s vitality model has been described as a “20-70-10″ system. The “top 20″ percent of the workforce is most productive, and 70% (the “vital 70″) work adequately. The other 10% (“bottom 10″) are non-producers and should be fired. Rank-and-yank ideologues credit Welch’s rank-and-yank system with a 28-fold increase in earnings (and a 5-fold increase in revenue) at GE between 1981 and 2001 – Obviously, this is a tremendously competitive model of organization and all criticisms of both the morality and (in)effectiveness of such a Dog Eat Dog method of social cohesion apply but as a manager you must take this in mind since reality and statistics (law of large numbers) do show that the “top 20″ percent of the workforce is most productive and is doing 80% of the work…

I would even dare claiming that, perfectionism is a strong indication for weak leadership!

——————————————–
* Note: I was told that everyone knows this principle but the question is how to do it… so my tip (and I promise to post more around this dilemma) is to handle this with-in the scoping of the feature or module; efficient scoping should get very fast to ROI (look for the items with low ROI) and risk analysis (look for the items in high risk and try to understand where the risk come from) and soon after the tradeoff discussion which is the perfect time to take the hard “cutting” decisions and for doing this you must have someone in the room with deep customer understanding; e.g. In most systems it is very “easy” to cut enterprise-readiness features to simplify development (I18N, Security, Upgrade, Scalability, High Availability, Distribution, Monitoring etc.) and many of those features can be added later if needed with no real overhead (warning: you must know what you are doing to make it work so don’t try this at home if you don’t have professionals with you);