Learning From Process Improvement Efforts

Comment on: How to Improve (at just about anything)

1. The classic way:

Do – make an improvement
Do – change a process
Do – implement some training
Do – install a system

When you have been through the 4 do’s keep right on doing.
2. The recommended way:

Plan – develop an idea or innovation, work out how you will implement it.
Do – carry out the plan on a small-scale, test it to see if it works.
Check – study what happened, did the plan work? If not why not? What can you change?
Act – adopt the change and roll it out, abandon it or learn from it and adapt it.

Another huge benefit to the PDSA cycle in my experience is to learn. I can't remember how many times I would see in the do-do-do-do organization that

do#1 was x
do#2 was y
do#3 was x again
do#4 was z
do#5 was y again

Um, ok, yeah why are we trying things we already know don't work (they are presented as fixes not, as well this old way wasn't great but jeez it was much less bad than the mess we have now so lets go back). Why are we thinking x is going to work when we just dumped x because it wasn't working? PDSA makes you think about the process, study the historical data and document your predictions. The learning will

Related: How to Improve - Document Your Decisions to Learn More Effectively - Learn by Seeking Knowledge, Not Just from Mistakes - Write it Down

Businesses Need to Capture Potential Information and Use the Creativity of Employees

Comments on: Asking the Employees

The problem I see is that management systems can't be seen as independent from the specific tactic in some area (for example getting employees to share ideas). So the effectiveness of soliciting ideas from employees varies mostly by the overall management system unrelated to the specific tactics of the attempt to get ideas from employees. The specific tactics matter but less than the management system (which is often a mess and something no one wants to address).

My father wrote an article a long time ago on how to use ~"two resources, largely untapped in American organizations: potential information and employee creativity."

I think it provides worthwhile ideas.

Related: Trust Your Staff to Make Decisions - Leading Improvement and Enjoying the Rewards - Do What You Say You Will

Deming Wanted Managers to Understand the Systems They Managed and to Visit Where the Work was Done

Comments on Deming wasn’t a fan of Management by Walking Around

Deming’s view is entrenched in Lean management practice in the form of “Genchi Genbutsu”, literally “go and see” at the “real place”. Where practitioners of Management by Walking Around merely visit the workers for a chat, practitioners of Genchi Genbutsu stay with the workers to understanding what is going on.

True, and the details you provide are important. It wasn't managers going to the gemba Deming was against. What mattered is the system. Some people did Management by Walking Around (MBWA), even decades ago, in a useful way - with understanding. But most did not.

Gemba walks are much more likely to be useful (because the expectations are for a more engaged leader) but there are plenty of times those are not done well, and are no better than bad MBWA. Jim Womack has a book out on Gemba Walks which provides good details to managers on what they should do (and what Deming wanted them to do).

Related: Out of Touch Executives Damage Companies, Go to the Gemba - Leadership and Management - Jeff Bezos Spends a Week Working in Amazon’s Kentucky Distribution Center (2009) - Customer Gemba

What is a Lean Program, Deming Program?

Thoughts in response to: Dr. Deming’s Last Interview & Jack Welch’s Thoughts on Him by Mark Graban.

Deming sure provided some great quotes in that interview; those you listed above and more (in fact I posted about one this week in To Achieve Success Focus on Improving the System Not On Individual Performance). From Mark's post:

I’m not sure what 'a Deming program' is anymore than I know what 'a Lean program' is sometimes.

This is so true. Basically organizations can be making good progress but essentially none that *have* a Deming or lean program. Toyota is sensible to consider the closest - I mean lean after all originally was just documenting Toyota and calling it lean instead of Toyota management or whatever. But Toyota does plenty of things that are not what even Toyota says how things should be done.

And beyond that lean has evolved away, IMO, from just being able to say anything Toyota does is by definition lean. Lean and Deming are more about a philosophy of managing - continual improvement, respect for people, etc. than prescriptions. So you can't really have a checklist and say that if your org can check off all these things they are lean or Deming.

The fact that the management systems can't be reduced to a checklist is a necessary given the long lasting power they offer. When you reduce the ideas for management that far (so you have a checklist of exactly what to do) you get a stupid system that can't be used for managing large systems of people. Organizations doing the best job of being worth of claims of being true to the management systems are likely to have the widest understanding of all the ways in which they are failing to live up to that vision.

I continue to think Toyota is doing a very good job. But they also have plenty of room to improve. And they continue to be tempted by becoming more like other companies instead of recommitting to the principles of lean and Deming.

Related: Rethinking or Moving Beyond Deming Often Just Means Applying More of What Dr. Deming Actually Said - Long Term Thinking with Respect for People - Deming and Software Development

Building a System to Reduce Interruptions for Software Developers

I feel strongly about the damage done by interruption to maker's focus. My appreciation for this damage to system performance was greatly enhanced as I became a software developer.

In my work prior to software development I could see that interruptions were not ideal but they were not so damaging to my work and they do also have value. But work that requires extra focus, and software development sure did for me, the damage increasing greatly.

Over 20 years ago at the Madison Area Quality Improvement Network they had a simple visual management sign at everyones office and cube. You could dial between various settings - GREEN available (free to interrupt)... RED busy, don't interrupt... There were 3 to 5 settings. It worked very well for them.

Of course such a system is highly dependent on the overall management system. Just putting that up in most offices would likely fail. MAQIN was an organization that embodied modern management practices (Deming, lean, respect for people, organization as system, etc.). It worked very well for them.

When building a software development team I tried to protect developers from interruption while having very open communication between developers and program managers (product owners). As is often the case, the real roles didn't line up exactly. In our organization, the people that needed us to develop software (to varying levels) didn't want to take on the responsibilities that agile would suggest (setting priorities etc.). Nor did the that organization want to deal with the conflicting priorities of the various people in their organization had for software development. As part of making things work, I took on a bit of the priority setting roles.

One of the things I did was explain to those that had us do software development was why it was critical to allow software developers to have uninterrupted time to focus. I shared various articles and reports over time and would talk about this as I interacted with them. I encouraged people to talk to me first (at that time I had transitioned from developer/software-development-program-manager to nearly entirely a program manager role).

We also had weekly meetings (when it made sense) with the "product owners", me and the developers working on the software. We scheduled additional meetings when necessary.

I also encouraged people to use email when possible to just check on things, ask simple questions, ask to meet. Again I explained how just going up to talk to the developer could impose significantly higher costs to them being able to focus of their work than there were for interrupting my work or others that had work that could more easily be interrupted with lower consequences.

When there were very important deadlines I would increase these instructions not to interrupt the software developers. And I would talk to the developers about how things were going and if the developers wanted help pushing back a bit I would then do so - mainly by trying to work on the system (provide a set time to allow needed discussions, coach the "product owners" on the difficulty caused by interruptions etc.).

As you might expect this worked better with some people than others. It made a significant difference though. And in our organization it was actually a bit less effective because the software developers were all so nice. They could say how interruptions damaged what they could do systemically but were always super friendly whenever they were interrupted. I was by far the most willing to actually disappoint people face to face in the name of improving overall performance.

It is very hard to overestimate the systemic nature of all of this. By delivering great results we were able to reinforce that if we followed the modified Deming/agile methods we were using were important. Those needing work from us ranged from very skeptical to accepting of those ideas but our performance (both in meeting their desires for software and for interpersonal interactions) made them willing to go along with the methods we said were important.

Related: Deming and Software Development - Mistake Proofing Deployment of Software Code - Creating a Culture that Values Continual Improvement

A College Degree Isn't an Acceptable Hiring Screen

Comment on: Do You Need a Degree to be Hired to Develop Software?

In all the time I hired developers (about 10 years), I never made a college degree a requirement.

The best developer (who was also much more - designer, coach, architect, program manager...) I ever helped hire didn't have a college degree.

Our company had just hired a new HR person that started "showing their worth" with new rules such as the dictate that all hires must have a college degree. Thankfully our team agreed to hiring him was wise and the CIO decided that dictate was nonsense and we hired the applicant.

I have written about what a great software development team we created.

In addition to a college degree being a lousy hiring screen, so are most of the automated screen poorly designed HR departments use. Years of experience, experience with a list of specific software, keywords listed, etc. are just lazy and poor criteria to use to reject applicants.

Related: Dee Hock on Hiring (2010) - Hiring – Does College Matter? (2007) - Google’s Answer to Filling Jobs Is an Algorithm (but yours shouldn't be) - The Illusion of Knowledge - Working as a Software Developer

Did Deming and Drucker Agree on Important Management Practices?

Response to, Help needed fleshing out differences between Drucker & Deming? on The W. Edwards Deming Institute LinkedIn group.

Here are some links about the topic

• video of Drucker discussing Juran, Deming and himself
• Driving Out Fear and Other Similarities Between Drucker and Deming by Kelly Allan
• Podcast with Kevin Cahill and Joyce Orsini where they discuss the interaction between Deming and Drucker and their ideas

There were cases where Deming and Drucker disagreed but in many ways the ideas they proposed were compatible.

Drucker did propose MBO, his version was not the same thing we criticize. Drucker did criticize how it was being implemented. I think you can argue even with the way Drucker wanted it done, but that way isn't nearly as bad as the way it was done in practice (so don't think Drucker was promoting managing in the way MBO has often been practiced).

And also don't tie Drucker to just MBO, he had lots of ideas over a very long career and many work fine with a Deming management system. I think in many ways Drucker's stuff can be more easily molded to whatever someone wants it to be - this is one reason I think you see Drucker taught in business school. They can claim Drucker wouldn't object to many things, even though, really I think he would - I am not sure Drucker spoke out so directly (especially compared to Deming).

But Drucker was direct on some things, like how bad excessive taking of company's money by executives was. And MBA programs seem perfectly fine ignore this, even though what Drucker found horrible has become mathematically 10 times worse than it was.

I think Drucker was ahead of Deming on this. I don't know that Deming ever was clear on how bad this practice was, but I think he would be clear about it today (though that is just my guess, I could be wrong). I think Dr. Deming would add that to the list of deadly diseases. Remember the original list was 5 before he added 2, to make it 7.

Related: Deming's Point 11.b of 14 - Deming versus Drucker - Why There's No Right Way to Do MBO - 3 Deming-Based Alternatives to Management by Objective

The Value of Putting Pen to Paper

Comments on Learning by Writing… by Hand

The psychology behind the learning advantage of handwriting is starting to be understood... [Carol Holstead] "It turned out my theory was right and now is supported by research. A study published last year in Psychological Science showed that students who write out notes longhand remember conceptual information better than those who take notes on a computer."

I am also a fan of technology. And also a fan of learning and paying attention to research. Pen on paper has advantages for learning that technology has yet to equal. At the same time technology has many advantages also.

We seem to understand the advantages of using technology fairly well but under-appreciate the advantages of pen on paper. To make sure we don't lose out due to this bias we should think before we accept that pen on paper isn't worthwhile.

From a post I wrote in 2005, Measurement and Data Collection

I believe, it is better to focus on less data, really focus on it. My father, Bill Hunter, and Brain Joiner, believed in the value of actually plotting the data yourself by hand. In this day and age that is almost never done (especially in an office environment). I think doing so does add value. For one thing, it makes you select the vital few important measures to your job.

Lots of data will be kept in computers and that makes sense. But putting pen to paper has value that we too quickly dismiss.

Related: Experience Teaches Nothing Without Theory - The Illusion of Knowledge - Write it Down to Improve Learning (Ackoff)