Karmona Pragmatic Blog

Preview

* 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”

Ken Schwaber was quoted giving this mind-blowing Scrum / mother-in-law allegory:

“imagine that your mother-in-law believed her daughter could do better… and then imagine that she moved in with you… that’s what Scrum is like”

Think about it…

Assuming we shouldn’t aim to completely avoid all errors in software development (since this is an inherent part of any human creation) but rather to spot them as quickly as possible before they become real problems.

And… since Scrum is indeed a very good “tool” to bring the problems in-your-face without any mercy in a daily manner.

So without even getting into the continuous improvement possibilities with mother-in-laws, I really liked the Mother-In-Law allegory :)

By the way, with great anticipation I have proudly joined the Haiku contest @ the famous Ktorium – Wish me luck! :)

“Cogito Ergo Sum Pragmaticus” (= I think, therefore I am Pragmatic | I am not a native latin speaker but the sound felt right ;)

I will dare to claim that eating restrictions and drinking contradictions for breakfast* is one of the first steps in the pragmatic** manager journey.

The ability to combine a revolution-like sense-of-urgency characteristics

• Opportunistic result oriented thinking with basic strive for early result (a.k.a. Constant search for simple low-hanging-fruits)
• Edgy pro-activeness in identifying and mitigating possible risks, bottlenecks or any other result-pooper
• Choosing the right battles with healthy pareto mindset

Spiced with René Descartes methodological skepticism

• Constant questioning and reflection: Why are we doing it? What problem are we solving? Is it really worth it? Is there an easier way? What will happen if we will drop it?
• Embrace doubt in current assumptions, restrictions, taboos, procedures, personal and corporate comfort zones or any other sacred cows
• Decipher the important vs. the urgent

With some Chinese long-term thinking

• Define a clear vision and goals
• Team building
• Invest time in analyzing market trends and technological direction

Are only some of the basic elements needed to reach a pragmatism Zen (!)

_______________________________________

Three Pragmaticus Tips:

* Don’t Skip Breakfast – Breakfast is the Most Important Meal of the Day! ;)

** Schedule a weekly recurring meetings in your schedule to proactively reflect on your life contradictions

*** Google engineers have launched a new Google Blog Directory – Very inresting reading…

“All my best thoughts were stolen by the ancients” — Ralph Waldo Emerson

Jerry Madden retired from NASA in 1995 as Associate Director of Flight Projects at Goddard Space Flight Center.
During his distinguished 37-year career, he have collected more than 100 observations about project management

IMHO, these are the best three:

(#14) Never ask management to make a decision that you can make. Assume you have the authority to make decisions unless you know there is a document that states unequivocally that you cannot.

// I have deleted the last part since I really think that people should strive to make decisions even if there is a document that states that you can’t…

(#16) Never make excuses; instead, present plans of actions to be taken

// IMHO, NO Results with a GOOD excuse will never even resemble Results

(#59) Running does not take the place of thinking. For yourself, you must take time to smell the roses. For your work, you must take time to understand the consequences of your actions.

//You better THINK!

When “The Moscow Cats Theater” came to New York, the Russian clown Yuri Kuklachev was interviewed:  “the secret of training them is realizing that you can’t force cats to do anything [...] If the cat likes to sit you can’t force her to do anything else [...] Each cat likes to do her own trick [...] Maruska is the only one who does the handstand. I find the cat and see what they like to do and use that in the show [...] I have a cat now that loves to be in the water…”

– REUTERS, 2006

__________________________________________

Personally, I think that managing engineers is much more complicated than herding cats (although I didn’t have the twisted pleasure to herd a cat yet)

When you go out of your way to hire the best people around than soon enough you will find yourself herding a superior, class A, hyper-developed mutant Ligers* who are much more knowledgeable than the herder (a.k.a. you)

In this environment you have to learn to simply trust your people (although this is not simple at all :), mark the vision, let them loose and only help to get rid of the stones in their way (this concept was best described as the Open Kimono** policy in Peopleware)

Well…. Managing the Delver Engineers is like Herding Legendary Ligers and you need to make a superior effort to see what these ligers “likes to do” and run fast enough to set the Vision and move the rocks out of the way.

__________________________________________

* The Liger, is a (huge) hybrid cross between a male lion and a female tiger

** Open Kimono Attitude: You take no steps to defend yourself from the people you have put in positions of trust.

By the way, The best answer I found on the origin of the term “Herding Cats” was in Google Answers

“The British merchant ship Madagascar set sail from Melbourne in August 1853, headed for London and carrying 60,000 ounces of gold dust. – She was never seen again…” (http://www.futilitycloset.com/2008/01/29/overdue/)

Well… Saying “no more gold dust” is the only way I know to close a software release on-time…

P.S. Did you noticed that the Mona Lisa has no eyebrows. (http://www.futilitycloset.com/2008/02/12/trivium-16/)

1^st Warning: Chaotic post below

Software project are chaotic system and are highly sensitive to their initial conditions (a.k.a. the butterfly effect) and dynamics (e.g. wrong design, vague requirements, team professionalism etc.).

To master (/control) a software project you must be able to breathe (/smoke ;-) the project – inhale the chaotic butterfly movements around you and exhale with the needed adjustments or you will be crushed on the nearest project failure shore with zillions of butterfly excuses.

2^nd Warning: Smoking software project is bad for you health

After a decade of software projects smoking I find myself easily doing a background-surfing on the chaotic edges of my projects like I drive my car in the same daily well known route back from work but since I am part of the same chaotic system I am trying to control, I know that my background-surfing is like forgetting my own butterfly wings.

Software project smoking isn’t a social event and can’t be easily shared but it is also one of the key factors in projects surfing – If you will not be able to share your surf experience with your team, your own butterfly wings will bring the next tsunami.

3^rd Warning: Don’t practice management if you don’t like the butterflies

My rough estimation is that the number of software project managers in the world is smaller in (at least) one scale from the conceived time-estimation techniques and this post is my humble four-cents contribution on how to do pragmatic time estimation for software projects (just finished one in Delver).

• Start with the mother of all lists to store your Product Manager wish list– We use eScrum Product-Backlog to store our work-items
• Prioritized them – We use 0-Yesterday; 1-Must; 2-Important; 3-Nice-to-Have and 4-”Forget-About-It”… ;-)
• Get relative estimations on all items
  • Granularity is the bronze-bullet for time estimations – Strive to the finest grained possible in reasonable time-frame  e.g. We usually aim for 2-5 days granularity in 2-3 days of time-boxed-estimation-period since the finest granularity in planning without reasonable time-box might take twice the time of doing the planned work (a.k.a. The Estimation Paradox)
  • Experience can turn your bronze bullet into silver one (ye ye, a silver one) – Relative estimation is calculated relatively upon a common scale of known work items from the team history e.g. We use Scrum “Story Points” and constantly measure the team velocity for time estimation adjustments
  • Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 etc.) can be used to “embed” the complexity and risk of rough (with insufficient drilldown) estimations e.g. if your estimation granularity for specific task reach ~40 days then your pragmatic estimation should be around 55 days (= the closest Fibonacci sequence) since it is reasonable to believe your (insufficient) granularity conceals risk, complexity and unknowns issues which requires Fibonacci-like-”buffering”
  • Strive to synchronize your time estimation techniques into very simple one – different time estimation conventions in the same development team is the 2nd reason for time delays. (I will give 0.95$ grant if you can guess what the 1st reason)
  • I know I am different but personally, I do prefer to have “pragmatic hours” vs. the normal Agile “ideal hours” and to start the project when 1 “Story Point” =  1 “Pragmatic Day” so long everyone understand this will change as soon as you start the project and then you need to return to velocity tracking to calculate the end
  • Don’t be naïve (a.k.a. “Ideal  Days”) with two known flavors:
    • Optimistic time estimations,  assuming 24*7 of concentrated programming ability with no outside interference (a.k.a. no such thing)
    • “Stupid” hand-waiving time estimations a.k.a. It is only 10 min to code this (but ~5 days to Integrate, Review, Design, Test, Schema and DAL changes, I18N support, Styling etc.)
• Get the rough project estimation = Sum of all product backlog story points / 22 (work days in month) / Number of relevant people
  • Usually this calculation will show you don’t have enough time for the project (even without project dependencies buffer which can be added later)
  • Start the “Tradeoff Game” – Try to cut items (content) based on the relative ROI
  • Revalidate your priorities since they will be the main tool (beside dependencies) for creating the project work plan.

As I see it, estimating software projects in a realistic time-frame is a statistic prediction of chaotic, time-delay-series of events and will never be straightforward nor easy so you can only do your best in the estimation and then track the project as it goes and make the needed adaptation on the way upon crystal clear project priorities.

Good Luck!

* The 1st manned landing on Earth’s Moon was the Apollo 11 mission on July 20, 1969 and the last one was Apollo 17 on December 7, 1972
* Current U.S. Vision for Space Exploration calls for a human landing on the Moon no later than 2019

2019-1972=47 (!!!)

Someone wise once gave this as a metaphorical example for a common engineers disorder, he called experience-anxiety-disorder, claiming that NASA stopped sending manned missions to the moon since they now know much more about the complexity and risk with doing this.

During the early seventies, it was a nice, naive working implementation but when NASA engineers started thinking about the next release they have built a five-decades-project-plan simply because they considered all the technological experience they have gained into large complexity buffers.

The Moral Lesson
Keep-it-simple can-do-approach and don’t over-complicate things with the long-tail-little-details when not needed or the project will take 5 decades to finish.

How do you know you are have an experience-anxiety-disorder?
If someone ask you to add a button to change the database schema and this make you feel a mixture of fear, apprehension, heart palpitations, nausea, chest pain, shortness of breath and headache.

What to do?
Sit down and relax, drink a cup of water and then add the damn button!

Last Long-Tail-Detail
Well… I don’t want to ruin this lovely moral lesson with the long-tail-little-detail but the real facts behind this 47 years gap were politics and money (as always) and not that NASA engineers got a severe experience-anxiety-disorder.

Google Trends (a.k.a. my experiment – part IV – Almost forgot…)

• Betty Casey
  
• Most Haunted Life
  
• Piercing & Tattoos
  
• Madonna
  
• World War III (…)
  

Chronicle of a Death Foretold = Waterfall Shmoterfall = Checkmate in 10 moves
* Note: I did see, participate and lead some successful waterfall projects (mainly due to some adoption of agile methodologies ;-) and this is my view of the projects which failed…

1. Release scoping start with marketing high-level-copy-paste-from-last-year-marketing-presentations MRD in ~1 month delay
2. 1 month of quick lets-write-all-the-features-we-can PRD – This is also the last time you hear from the product manager until the next milestone-demo-crisis.
3. High level design for a couple of weeks which sum-up to a Very Rough Time Guesstimate a.k.a. VeRTiGo
4. Release time-frame is set ~1 year ahead with the needed VeRTiGo “squeezing” and high level time-frame is determined:
   • 2 months of the waste above and last release leftover
   • 1-2 months of Planning (functional and technical design)
   • 4-5 months of Development – with ~3 Major Milestones
   • 3 months of QA & stabilization
   • 1 month of Project Buffer
5. Very soon the development teams are scattered like lonely wolfs – everyone for himself until the next integration or major milestones months away.
6. First milestone is ending with:
   • 20% of the content is really Done a.k.a. “Even a Blind Chicken Finds a Kernel of Corn Now and Then”
   • 50% is “done” with dirty bugy code, low quality, performance issues with missing or wrong functionality
   • 30% is just not ready
7. Developers and low level management remind themselves yet again to put more buffers…
8. The PMO suggest (in relax and trusting tone) to postpone the milestone or remove content.
9. Management doesn’t get in panic (they have seen it before ;-) and decide not to decide: “Let’s see if we can cut the drawback in the next Milestone” a.k.a. The classic do {} while(timeRemaining > Last Milestone)
10. Next milestone has much more content and the pressure builds up… until the last milestone blaming game which usually ends up with ~2 month delay and half of the planned content.

Checkmate