Kaizen and Radical Helpfulness

Context

I recently spent two days with other students in a Kanban class (see Wikipedia’s definition of kanban at http://en.wikipedia.org/wiki/Kanban). An effective kanban system minimizes the degree to which any part of the process needs to wait for input from its predecessor (called blocking), and maximize task completion. Loosely associated with kanban is kaizen, which, in the western business world, signifies a process of continually improving operations based on feedback and experimentation from people at all levels of an organization.

 

Ice Cream

During the mid-afternoon break on the second day we were invited to go next door for free ice cream (!). I arrived to find a substantial line. (Backlog!) The process was quite inefficient. Each “customer” stepped up to the ice cream bar, took a scoop from a metal container filled with water, scooped his or her ice cream, and returned the scoop to the metal container. Making matters worse, the ice cream bar was located in a place that was ill-suited for this flow, so entering and exiting the scooping area made it take even more time.

Seeing this, Sam the kitchen manager came over and offered “I can do this for you much more quickly.” Strangely, the person about to scoop ice cream ignored him. He may not have heard Sam. The second person also ignored Sam. I was the third person, and I enthusiastically gave him my bowl and said “Go for it!”

It must have been frustrating for Sam watching us flounder like that because when he finally got the go-ahead from me, he dove for the scoops. Like a sheriff in the wild west picking up his six shooters, he lunged toward the metal container, grabbed one scoop in each hand, and plunged them in two ice cream tubs at the same time. Then he did it again with the other two scoops and tubs. Hmmm, there were four scoops and four tubs, what a fortunate coincidence (not!).

This was a brilliant application of kaizen. I was pretty excited to share this story with the class, and eventually had my chance.

After relating my story, Ken, the instructor offered his own. I’m paraphrasing, but basically he said “Did you notice that yesterday and today, the lunch line was really long, and it took forever for some people to get their lunch? The lunch table was placed against the wall so that only one line could pass. From a throughput point of view, that’s the worst place it possibly could have been.”

Doh!!! Epic fail! We could have halved the time it took to get lunch (which felt like 15-20 minutes for some) by merely sliding the table over a few feet. We like to think of ourselves as pretty smart, but sometimes, um, not so much.

So I thought to myself (cough, retrospective, cough), why did this happen? Why, in a room full of professionals, many of us engineers no less, did no one think of this? Here are some possible answers.

Not My Job

It is common for us to assume rigid lines bounding our responsibilities, and focus our energies inside those lines. This is, after all, the basis on which our value is judged; no one ever got a raise or promotion by picking up someone else’s garbage. And while there is a legitimate weight for this, in its extreme it is selfish.

Fear of Embarrassment or Rejection

What if I make a suggestion and it turns out to be a silly one? Or what if the person responsible would be angry if I moved the table, saying that I should mind my own business?

Laziness

If I just wait my turn, I can avoid the effort of embarking on this mental journey to solve the problem, and avoid the social effort required to enlist the support or permission of others.

Low Self Image

I’m not good enough to figure out a solution to this problem, so I won’t bother trying.

It Didn’t Occur to Me

Most likely, it doesn’t even occur to me to try to solve the problem.

It Was Where It Needed to Be

Of course, there’s always the possibility that this alternative had already been considered and rejected for good reason. I’ve found that sometimes when I’m sure I know better, I don’t – and that’s another opportunity for growth, but outside the scope of this article.

 

The Toronto Hotel Fire Alarm

I attended a conference in Toronto a few years back, and a false fire alarm sent everyone out into the street. There were probably a hundred people waiting a pretty long time for the hotel to call us back in. Two parents and their children were standing there in their swimsuits, obviously quite cold. I found a hotel employee, pointed to the family, and said “those folks look pretty cold, is there anything we could do for them, maybe get them some towels?” A couple of minutes later they had towels around their shoulders and smiles of relief on their faces. Though I may be projecting, it occurred to me that they were happy not only to be warm, but from the nice feeling that we get when we receive (or give) help.

Why wasn’t the hotel staff scanning the crowd to see how they could make their customers more comfortable? And why didn’t it occur to the parents to ask for help? Sometimes the best window into ourselves is that which we notice in others. What would I find if I examined my mind to see if I share those self-imposed limitations? How can I train myself to go beyond them?

 

The Helpful Procurement Suggestion

At one of my employment positions, I noticed that the procurement process was dismally broken. The system we had in place was this: When you run out of stuff, go to the store and buy it. No inventory. One time a presentation to a potential customer almost didn’t happen because a blank CD couldn’t be found, and someone had to race out to the store to get one in time.

I remembered the admonition not to complain about a problem without proposing a solution, so I put together an email message outlining a system I thought would work well for us. I sent it to the guy in charge.

In contrast to my polite and respectful tone, he replied with what was probably the most vitriolic email message I’ve received in my entire career. He accused me of inventing fictitious problems, and told me to mind my own business and stick to software development. (My coworkers confirmed my statements.)

Given reactions like this, is it any wonder that so many of us do just that, mind our own business, ignoring opportunities to further the collective goals?

This is why it’s so important for a work group, department, or organization to show by their actions (words are good, but by themselves not enough) that they require respect and fair play; otherwise, how can they complain if their people lack initiative?

 

How the California Highway Patrol Saved My Life

It was late at night a few years ago, and I was driving from San Francisco to my friend’s place about an hour outside of the city. I was getting sleepy. Suddenly I heard a siren, and noticed flashing lights in my rear view mirror. I pulled over. The highway patrolmen told me I had been weaving, and asked if I had been drinking. I hadn’t. Since I had no recollection of weaving, or anything, before being pulled over I’m pretty sure I was asleep. If I hadn’t been stopped, I might have died that night.

How did they know, was it coincidence?  Did they just happen to be driving near me? Since then I learned that anyone can call #77 and be connected with the local or state police appropriate to that location. It’s possible that a good Samaritan saw me and notified the authorities.

Since then I have called #77 many times, once for a car fire, several times when people were weaving (including trucks!), and many times when I encountered a road hazard such as a box on the highway.

Is it my job to do so? Not really, but how boring would my life be if I only did things I had to do? And besides, what nobler thing could I possibly do with my life than save another’s?

 

Surely You’re Joking, Mr. Feynman

In the book “Surely You’re Joking, Mr. Feynman”, the great physicist Richard Feynmann relates (among other things) his experiences as a child working at a hotel run by his aunt on the beach. His playful uber-geeky brilliance is a fun read as he relates his incessant ill-fated attempts at process improvement at the hotel and the angry reactions of his elders. In his defense, it would be unfair to judge his inventions by the very first iterations of them, and he didn’t get the opportunity to refine them. You can read this online at pp. 25-30 of the book (go to http://books.google.com and search for “Surely You’re Joking Mr. Feynman”).

 

Extending this Principle to the Broader Human Experience

The lack of initiative so often found damages productivity in the workplace, but if we extend it to the broader human experience, we can see that much suffering has occurred due to apathy and selfishness. Edmund Burke said “All that is necessary for the triumph of evil is that good men do nothing.” It is natural for us to think of ourselves and our families first, our wider groups and nations next, and “the rest of the world” last. We’re wired that way. But it would also be prudent, helpful, and good to acknowledge how much damage and suffering that selfcenteredness has caused, and work to mitigate it.

Conclusion

Gerald Weinberg says in his book “The Second Law of Consulting” that “No matter how it looks at first, it’s always a people problem.” We want to be part of the solution, not the problem, right? So here are some questions we can all ask ourselves:

  • Do I care enough to go out of my way to help my coworker, even when that is outside the scope of my measured (rewarded) performance?
  • Do I actively seek opportunities to be helpful?
  • When someone makes a suggestion to me, do I give it serious consideration? Do I feel grateful for the suggestion? If not, why not? Do I communicate that gratitude to the other person?
  • If I have authority over others, how do I respond when they make suggestions that differ from my own ideas and opinions?
  • Do I feel happy or envious when a coworker is recognized for excellence?
  • If everyone behaved as I do, would my organization be a better or worse place? In what ways?
  • Do I monitor my thoughts and actions and notice when there is need for improvement? If so, do I make an effort to correct myself?
  • Do I ask myself what am I not thinking or doing that I should be (as described in the Toronto Hotel story)?

What other questions would you add to this list?

Interview with Corey Haines, August 2011


Our first post is a voice interview I did with Corey Haines in Dulles, Virginia, on August 18, 2011.

Corey

After 12 years of coding for money, Corey Haines said enough and went on a year-long, journeyman pair-programming tour. Traveling the world, pair programming for room and board, he spent his time teaching, learning and just living as a knowledge-cross-pollinating, little, software craftsmanship bee. For the past three years, Corey has focused his attention on helping developers improve their fundamental software design skills through the use of focused-practice events, such as code retreats. 1

The Pairing Journey

In the first part of the interview Corey tells us about his inspiring and unconventional journey, which began with, of all things, being fired from his job. He immediately picked himself up and planned his next move. Thinking outside the box, he set out to teach and learn from his colleagues in the technical community, starting with David Chelimsky of RSpec fame. That is, he literally set out, visiting them for up to a week at a time, sleeping on couches, absorbing their wisdom, passing it on to the next people and offering some of his own. Corey is now an internationally known and respected member of the Ruby community, leading code retreats all over the world.

Corey’s Thoughts and Observations

In the second part Corey shares his observations about organizations, teams, and individuals in the workplace. Here are some of my favorite quotes from it:

“…most of the companies that I really admire, they don’t call it agile, they just call it software development, so for the techniques that XP has, they wouldn’t dream of not doing automated testing, because that’s irresponsible for your client. Now, they do it and they learn about it, they find pain points with it, and instead of abandoning it, they inspect it. Are we potentially doing it wrong, are we potentially doing it in an immature fashion, are we doing it in a way that we can fix, and so they’re constantly inspecting.”

“You can bring inexperienced people in, but don’t put them in a corner and have them sit there hacking out code. Bring inexperienced people in and treat them as equals, treat them as people that you’re mentoring, treat them with respect, and they’ll strive to do that, and if they don’t you cut them. If they’re not that kind, then you get rid of them and you bring in the people who are of that nature.”

“I think the most effective way [of collaborating], which does not mean it’s the only effective way is big open room, big huge monitors, live input devices for everybody, so two keyboards, two mice on a machine.”

“The companies that ate together that would either bring lunch in or people would go out and bring it back or they would go out in groups of six or something, but if you eat together, it just was wonderful because you got in in the morning and it was your family that you spent the day with…those places I loved. It just breeds that excitement about it, and it breeds responsibility, and the better you know your teammates, and the more affection you have for them, the less you want to let them down, and you’re willing to work on your own skills to that you don’t let them down.”

(Q: “In the places you’ve encountered that have been the most productive and successful, what are the leaders like?”) “I think they all seem to be very engaged, they all seem to like the people, they want the people to be happy, and they tend to be engaged in the day to day stuff. Either they’re actually sitting on the floor with people working, or they are in there a lot, or they are in the meetings a lot, but they tend to be very engaged, and have a good philosophy about both software and people.”

…and my favorite one:

“Software development is a very social activity.”

I hope you enjoy listening to this as much as I did.

Corey can be found on twitter as @coreyhaines or at http://www.coreyhaines.com. Screencasts and articles about Corey’s programming tour are available at http://programmingtour.blogspot.com (check out the older posts).

- Keith Bennett, http://about.me/keithrbennett

Show Notes:

00:20 – The adventures of Corey Haines and traveling around the world

  • Spending time with people with different experience levels and personality types
  • Meeting people and building a network
  • Connecting people together

02:00 – Tendencies to work in a very insulated community

  • Working around others gives you a view of where you stand between them
  • These people are better than me/I’m better than those people
  • Self-realization in skills; what I’m good at/what I’m lacking

03:05 – Finding people and having them find you

  • Pairing for room and board
  • Video interviews with everybody he stayed with
  • People started noticing Corey
  • Acquired notoriety on Twitter
  • People started inviting him to come to them

12:30 – All of the above stemmed from a “negative event”: getting fired

  • Firing people who just don’t fit in is an effective company practice
  • Support after getting fired helped to lift him back up

16:25 – Establishing a reputation within the Agile community

  • Talking to people
  • Shaking hands
  • Attending conferences
  • Forced himself to meet people and overcome shyness
  • Became more able to hold a conversation

19:40 – Using Ruby

  • Previously using the Microsoft ecosystem
  • Professional programmer since 1996
  • First Ruby he ever wrote was in 2006

23:50 – Different ways of doing things/insights

  • Small teams work best
  • Internalizing extreme programming
  • Agile versus software development
  • Giving the most value to clients

28:07 – Hiring the best people for a job

  • You can bring inexperienced people in
  • Treat them as equals and mentor those who want to learn. Cut the ones who don’t
  • Software development is a very social activity

29:45 – Effective ways of collaborating

  • Big open room
  • Big huge monitors
  • Live input devices for everybody
  • Being co-located
  • Companies that eat together

32:15 – Who to pair with and when

  • It depends on an individual’s time cycle

33:35 – People who resist pair programming

  • Not an easy skill to learn
  • Resist because they’ve never had an effective pairing session

37:06 – Leadership

  • Engaged in day to day activity
  • Want to see people succeed
  • Participate in meetings
  • Good philosophies on software and people

38:08 – Learning new technology to do your job

  • Set aside time to focus on practicing it
  • Your company should not get paid by their clients to learn technology
  • Good companies want you to learn

44:40 – Where is Corey today (as of interview, August 2011)?

  • Lives in Chicago
  • Working on a start-up app with his girlfriend called Mercury App–an application to help individuals and teens make better decisions
  • Side projects
  • Internal training at companies and talking about taking time to practice
  • Code Retreats

Notes:

  1. This paragraph copied from Corey’s bio with his permission.

Welcome to TechHumans.com!

 

Human, nontechnical issues routinely make and break billions of dollars worth of software projects.  They also have a huge impact on the happiness or misery of software professionals.  Why is it, then, that so little is said about them?

 

TechHumans.com is a nontechnical blog for technical people.  We discuss maximizing project success and team happiness by:

  • exploiting individual diversity rather than treating developers as interchangeable parts
  • cultivating a sense of shared purpose so that a team *feels* like a team
  • encouraging developers to share expertise with each other and creating an environment of collaboration, not competition
  • making the workplace a place people look forward to being every day
  • getting to know colleagues better
  • supporting efforts to better learn the craft
  • ensuring that people feel valued, respected, and safe

This blog is primarily for developers, but managers, executives, and others are welcome too.

If you have any ideas, suggestions, or would like to help out, feel free to email me, or join the Tech Humans Google group at https://groups.google.com/d/forum/techhumans and post there.

I expect we’ll be posting articles, audio interviews, and videos. Our goal is to be entertaining and engaging in addition to being informative. Sometimes the best medium to accomplish this is story telling. If you have a story you’d like to share about the dramatic effect of human issues on a project or in an organization, we’d like to know about it.

Check out our podcasts here.

Thanks to Avdi Grimm whose WideTeams blog inspired me to start this one.

Keith Bennett
Reston, Virginia, USA
July 2012