Iterate the PDSA Cycle Quickly to Speed Up Learning and Improvement

As you say learning is central to using the PDSA cycle. Those organizations that are most successful turn the PDSA cycle quickly and iterate. A significant part of such behavior is to intentionally design the PDSA to iterate quickly - break down PDSA cycles into smaller pieces that can quickly be iterated.

Comment on: What it Means to Turn the PDCA Cycle One More Time

Related: How To Create a Continual Improvement Culture - Using the PDSA cycle to improve management

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

Learning Can't Take Place Without Theory

Response to: The Secrets of Lean

I think you make good points, but I think you make a mistake stating:

"This system of learning has come from experience, not theory."

For some reason, culturally, we created this idea that theory was about disengaged people (away from the gemba) thinking in a way disconnected from practice. But this is not what theory is.

Learning can't take place without theory. Experience doesn't lead to learning. Experience with a theory and an informed observer that questions what they see can lead to learning.

It seems to me accept theory that is separated from the gemba as what theory is and then say theory is not useful, experience is. But we are making a mistake when we think this way. The problem we see in theory being used disconnected from feedback from the gemba is a bad use of theory. But the problem is not that theory needs to be eliminated, but that theory disconnected from the gemba is not useful in learning about systems and improving our organizations.

Related: Experimentation is an iterative process - Effort Without the Right Knowledge and Strategy is Often Wasted

System Imposing Burden on Customers Driven by Pointy Haired Boss

When Begging for Customer Service Scores Hurts Customer Service

I always think… you want patients to say you give “excellent” service and care… then focus on providing excellent service and care! Don’t guilt trip me or don’t manipulate me… that makes me feel a bit worse about the service, when that’s not the intent. Employees shouldn’t be put in the position of begging for scores… help them provide the best service possible, instead.

The practice of telling your customer they must save you from horrible management is terrible. Managers designing a system that puts a burden on customers to rescue people from harsh treatment is about as lame as management can be. Definite Dilbert's pointy haired boss level idiocy.

Any company with this setup likely has little clue about how to use data. When you mistake the data for the proxy indication it is suppose to be a measure of you can't manage at all. Giving huge incentives to people to make the number good (like having employees impose a burden on customers to have a number better which directly burdens the customer) is idiotic.

Relate: Managing to Test Result Instead of Customer Value - Distort the data instead of improving the system - Jiro Dreams of Sushi

The Tendency for Lean Experts to Distrust Technology

My thoughts on Why can't we use technology to accelerate Lean adoption across my company? [the broken link was removed]

I think biggest objection is how often and badly technology efforts fail. This makes a knee jerk reaction against jumping to technology fairly wise.

I think the second reason is technology expertise is often not found in the same people that have lean expertise (it can be it just isn't super common). Combined that with number 1 and the fact that making technology projects successful requires great system (rare) or can be made more likely with a deep understanding of technology and management systems (but I just said they often don't have the tech expertise) so again a reason to shy away from tech.

If a good lean consultant saw the organization had great system for making technology projects, countermeasures etc. successful they would support such efforts even if they were weak on tech. I'll also say most lean consultants aren't great. They don't understand lots of stuff about respect for people, management systems, customer focus, gemba etc.. Due to fear I think many that don't have strong lean understanding will shy away from technology.

I think technology solutions can be great. There is nothing wrong with them, when conditions are right. Conditions are almost never even decent - forget right. Technology projects and efforts are much more likely to be messed up due to bad systems and lack of expertise.

Technology solutions can have huge impacts - there are many good things possible with technology. The problem is so often technology wielded inside organizations (human systems) fail for many reasons very closely tied to bad management practices. The better the management practices the less likely technology will backfire in my opinion. The stronger the management system the more likely technology projects will be managed sensible, tested at the gemba, adjusted by people with a strong understanding of the gemba, project managed by people with an understanding of lean thinking practices (deliver working code fast etc.)...

The fear of technology projects is those reasons and more. Things like the same problem with brain-dead implementations shoving down a horribly inflexible ERP program or shoving down a 10% across the board budget cut and many other such efforts. Technology efforts really are no different than others but there are some difficulty in the problems of technology often being more difficult for people to see.

Technology also is often seen as this wonderful simple quick fix by executives - letting them avoid the gemba and just put hope in a essentially magic bullet solution.

The whole effort to make problems visible is much less likely to be done well around technology (which has to do with some issues with the domain but also with the lack of technology expertise [especially software development] of management and decision makers). Lots of the efforts in lean software development and agile have very good practices for technology efforts.

Related: Deming and Software Development - Involve IT Staff in Business Process Improvement - Mistake Proofing Deployment of Software Code

Ex-Toyota Manager Consulting with Porsche in 1994

Interesting article from 1994. Shock therapy for Porsche [the broken link was removed]: The prestigious German car firm was speeding to destruction, so its chief swallowed his pride and hired Japan's top consultants to improve outdated methods of production. John Eisenhammer charts the brutal remedies they prescribed at the company's plant near Stuttgart:

The results are already impressive. The production time of the new Porsche 911 Carrera has been reduced by a third, to 86 hours. That is still some way behind the best comparable Japanese time of 50 to 60 hours, but Porsche claims to be well on target. Whereas 70 per cent of Porsches three years ago required expensive rectification at the end of the production line, the proportion is now half that. Inventory levels have been reduced by 44 per cent: 7,000 square metres of shopfloor space have been freed and rented out. A worker suggestion scheme, which in the past generated fewer than 20 ideas a month, has now exploded to around 2,500

While respect for people is an important part of the Toyota Production System, the practice of former Toyota managers were often the "tough love" variety. Today, many people are often too timid, in my opinion, to call out things that need to be improved for fear of making someone uncomfortable. Where that balance properly lies though is based on the culture of the organization (and what needs to be done - occasionally there is a need to "shake people up" in order to make change take place more effectively).

In his own gruff way Mr Iwata agrees. 'We are not here to praise,' he growls. 'But there is hope for Porsche.'

Related: Early "Lean" Thinking - Pay Practices Say More About Respect for People Than Words Say - Respect for People and Understanding Psychology - Respect for Everyone Funny item from the story:

When not discussing production-line changes or conducting workshops, the Shin-Gijutsu people are ambushing staff. 'When I see one of Porsche's fine engineers, I do not say 'good morning',' grins Mr Nakao. 'I say, 'show me your hands. They must be dirty - engineers must always have oily hands'.' Used also to checking the soles of shoes worn by managers in the finance department, to see if they spend enough time walking around the factory, Mr Nakao was devastated to discover the trick did not work with Germans, who are used to resoling old shoes. 'We do not do this in Japan,' he says. 'How can I see if a man is doing his job properly if he keeps changing his soles?'

It is also illustrates that your practices need to adjust to the system. Time at the gemba is important and transfers. Your specific means of checking that might have to be adjusted.