Tag Archives: John Hunter

Deming and Software Development

I am sometimes asked about how use Deming’s ideas on management in a software development context. My belief is Deming’s ideas work extremely well in a software development context. The main issue is often unlearning some assumptions that people might have about what the Deming management system is.

It really is surprising to me how many “knowledge workers” respect Deming ideas but then say his attempts to treat factory workers as thoughtful people who should be respected and involved in improving their processes doesn’t make sense for them because they are “knowledge workers.”

There are many good things being done to improving the software development process. I think many of them are very Deming-like in their approaches (but to me miss out on aspects of the Deming management system that would be helpful). I think Dr. Deming’s approach to software development would focuses on the system of profound knowledge (the 4 inter-related areas below):

  • Understanding variation – software development has quite a bit of variation, some probably innate [unique work] and some due to not having good procedures, batching work, not fixing problems right when they are seen, quick fixes that leave the system venerable in the long term (when you make one simple change to the code it has an unanticipated consequence due to poor practices that could have been eliminated), etc.. Many good coding practices are effective strategies to deal with this issue. And building an understanding of variation for managers (and business process owners/product owners) is very helpful to the software development process. The ideas in agile and kanban of focusing on smaller delivery units of work (one piece flow, just in time, cycle time…), customer value, maintainable code, sustainable work conditions, etc. are directly found in a Deming management system.
  • Appreciation for the system of software development. Don’t just complain about bugs. Examine the process of development and then put in place mistake proofing efforts (don’t duplicate code, use integrated regression tests, don’t put artificial constraints on that result in system distortions – unrealistic targets…). Use things like kanban, limited work in progress, delivering value to customers quickly, think of success in terms of getting working software to customers (not meeting internal delivery goals), etc. that take into account our experience with systemic software development problems over the decades.
  • Theory of knowledge – how do we know what we know? Are estimates reliable? Lets look at what users do, not just what they say (A/B testing…). Software developers often appreciate the value of usability testing, even though they rarely work for organizations willing to invest in usability testing. In my experience when software developers object to usability testing it is normally really an objection to overwork, and the usability testing is just going to give them more work or criticize things they were not allowed to spend the time they needed to do great work. That won’t always be the reason but it is the main one in my experience (I suppose their is also fear and just the psychology of not wanting to hear anything negative about what has been created – even if the usability testing shows tons of great results people will often focus on the negative).
  • psychology and respect for people – This pretty much seems like it is the same for software development as everywhere else.

Continue reading

What is the Explanation Going to be if This Attempt Fails?

Occasionally during my career I have been surprised by new insights. One of the things I found remarkable was how quickly I thought up a new explanation for what could have caused a problem when the previously expressed explanation was proven wrong. After awhile I stopped finding it remarkable and found it remarkable how long it took me to figure out that this happened.

I discovered this as I programmed software applications. You constantly have code fail to run as you expect and so get plenty of instances to learn the behavior I described above. While I probably added to my opportunities to learn by being a less than stellar coder I also learned that even stellar coders constantly have to iterate through the process of creating code and seeing if it works, figuring out why it didn’t and trying again.

The remarkable thing is how easily I could come up with an new explanation. Often nearly immediately upon what I expected to work failing to do so. And one of the wonderful things about software code is often you can then make the change in 10 minutes and a few minutes later see if it worked (I am guessing my brain kept puzzling over the ideas involved and was ready with a new idea when I was surprised by failure).

When I struggled a bit to find an initial explanation I found myself thinking, “this has to be it” often because of two self reinforcing factors.

First, I couldn’t think of anything else that would explain it. Sometimes you will think right away of 4 possible issues that could cause this problem. But, when I struggled to find any and then finally came up with an idea it feels like if there was another possibility I should have thought of it while struggling to figure out what I finally settled on.

Second, the idea often seems to explain exactly what happened, and it often feels like “of course it didn’t work, what was I thinking I need to do x.” This often turns out to be true, doing x solves the problem and you move on. But a remarkable percentage of the time, say even just 10%, it doesn’t. And then I would find myself almost immediately thinking, of course I need to do y. Even when 10 seconds ago I was convinced there was no other possibility.

Continue reading

Leadership and Management

I don’t think the attempts to separate leadership and management are useful. I read plenty of things that are variations on Peter Drucker’s:

“Management is doing things right; leadership is doing the right things.”

A manager that is not concerned about doing the right things is a lousy manager. And a leader that doesn’t care about doing things right is a lousy leader.

Another theme of this contrasting type quote says some version of:

“Managers care about efficiency and leaders care about effectiveness”

A manager who doesn’t strive to be effective is also a lousy manager. It is also odd to suppose the detached leader (the type that lets the manager deal with the mundane while they dream), one that doesn’t concern themselves with customer focus, value chains, going to the gemba really has a clue about effectiveness. The idea seems mainly to view a manager is a cog looking at some tiny process and making it efficient without understanding the organization as a system or value chains or customer focus.

I think, the main problem is all of the attempts to contrast leaders and managers. Much of the time people are saying managers don’t do things they certainly should be doing.

The desire to express how leadership traits can be used by those without organizational authority are useful. Discussion of how certain traits can be seen as within the domain of leadership I suppose may be useful (it can help our minds see how various traits and practices combine to help get results – and we can categorize these under “leadership”).

Leaders that are primarily “big thinkers” and motivators without a clue about how to actually do the things they advocate (the model of “managers” deal with the implementation with blinders to the system while “leaders” are “above the fray”) is not useful in my opinion. It does note a somewhat common practice (in organizations today) but not one that is wise. Separating leadership from the gemba is not wise. Separating leadership from a deep understanding of customers is not wise. Separating leadership from how the organization actually works is not wise.

Plenty of others seem to disagree with my opinion though, there are many articles, blog posts, podcasts, talks… on separating leadership from management.

Continue reading

Lean Blog Podcast with John Hunter

Mark Graban interviewed me for the Lean Blog podcast series: Podcast #174 – John Hunter, “Management Matters” (listen using this link). Links to more information on what we discussed in the podcast.

More podcasts with me: Software Process and Measurement Podcast With John HunterBusiness 901 Podcast: Deming’s Management Ideas TodayProcess Excellence Network Podcast with John Hunter

George Box

I would most likely not exist if it were not for George Box. My father took a course from George while my father was a student at Princeton. George agreed to start the Statistics Department at the University of Wisconsin – Madison, and my father followed him to Madison, to be the first PhD student. Dad graduated, and the next year was a professor there, where he and George remained for the rest of their careers.

George died today, he was born in 1919. He recently completed An Accidental Statistician: The Life and Memories of George E. P. Box which is an excellent book that captures his great ability to tell stories. It is a wonderful read for anyone interested in statistics and management improvement or just great stories of an interesting life.

photo of George EP Box

George Box by Brent Nicastro.

George Box was a fantastic statistician. I am not the person to judge, but from what I have read one of the handful of most important applied statisticians of the last 100 years. His contributions are enormous. Several well know statistical methods are known by his name, including:

George was elected a member of the American Academy of Arts and Sciences in 1974 and a Fellow of the Royal Society in 1979. He also served as president of the American Statistics Association in 1978. George is also an honorary member of ASQ.

George was a very kind, caring and fun person. He was a gifted storyteller and writer. He had the ability to present ideas so they were easy to comprehend and appreciate. While his writing was great, seeing him in person added so much more. Growing up I was able to enjoy his stories often, at our house or his. The last time I was in Madison, my brother and I visited with him and again listened to his marvelous stories about Carl Pearson, Ronald Fisher and so much more. He was one those special people that made you very happy whenever you were near him.

George Box, Stuart Hunter and Bill Hunter (my father) wrote what has become a classic text for experimenters in scientific and business circles, Statistics for Experimenters. I am biased but I think this is acknowledged as one of (if not the) most important books on design of experiments.

George also wrote other classic books: Time series analysis: Forecasting and control (1979, with Gwilym Jenkins) and Bayesian inference in statistical analysis. (1973, with George C. Tiao).

George Box and Bill Hunter co-founded the Center for Quality and Productivity Improvement at the University of Wisconsin-Madison in 1984. The Center develops, advances and communicates quality improvement methods and ideas.

The Box Medal for Outstanding Contributions to Industrial Statistics recognizes development and the application of statistical methods in European business and industry in his honor.

All models are wrong but some are useful” is likely his most famous quote. More quotes By George Box

A few selected articles and reports by George Box

Continue reading

Software Process and Measurement Podcast With John Hunter

In my podcast with Tom Cagley, Software Process and Measurement Cast: John Hunter on Management Matters, as you might expect there was a bit of a focus on software development and agile software development as related to the ideas I expressed in Management Matters: Building Enterprise Capability.

photo of John Hunter at the Borobudur Temple

John Hunter at the Borobudur Buddhist Temple in Indonesia.


Continue reading

Podcast Discussion on Management Matters

I continue to record podcasts as I promote my new book – Management Matters: Building Enterprise Capability. This the second part, of 2, of my podcast with Joe Dager, Business 901: Management Matters to a Curious Cat. The first part featured a discussion of 2 new deadly diseases facing companies.

image of the cover of Managmenet Matters by John Hunter

Management Matters by John Hunter

Listen to this podcast.

Links to more information on some of the topics I mention in the podcast:

More podcasts: Process Excellence Network Podcast with John HunterBusiness 901 Podcast with John Hunter: Deming’s Management Ideas Today (2012)Leanpub Podcast on Management Matters: Building Enterprise Capability

Process Excellence Network Podcast with John Hunter

image of the cover of Managmenet Matters by John Hunter

Management Matters by John Hunter

Diana Davis with the Process Excellence Network interviewed me for their podcast series, process perspective – Management Matters: Interview with author John Hunter (listen to podcast). Additional details on some of the ideas we discussed:

Related: podcasts and interviews on Management MattersBusiness 901 podcast: Two New Deadly Diseases for BusinessDeming’s Management Ideas Today (podcast with John Hunter)

Business 901 Podcast: Two New Deadly Diseases for Business

I continue to record podcasts as I promote my new book – Management Matters: Building Enterprise Capability. In this podcast I discuss the 2 new deadly diseases facing companies. The second part of the Business 901 podcast will be posted soon.

Links to more information on items discussed in the podcast: Dr. Deming’s 7 Deadly Diseases + 2

Executive pay:

Copyright and Patents

I have created a new subreddit for posting links to interesting items about the new deadly diseases for business.

Related: Interviews for Management Matters: Building Enterprise Capabilityprevious business 901 podcastLeanPub podcast on Management Matters

Leanpub Podcast on My Book – Management Matters: Building Enterprise Capability

image of the cover of Managmenet Matters by John Hunter

Management Matters by John Hunter

I recently was interviewed for a podcast by Len Epp with Leanpub: Leanpub Podcast Interview #9: John Hunter. I hope you enjoy the podcast (download the mp3 of the podcast).

In the podcast we cover quite a bit of ground quickly, so the details are limited (transcript of the interview). These links provide more details on items I mention in the podcast. They are listed below in the same order as they are raised in the podcast:

The last 15 minutes of the podcast I talk about some details of working with Leanpub; I used Leanpub to publish Management Matters. I recommend Leanpub for other authors. They don’t just have lean in their name, they actual apply lean principles (focusing on the value chain, eliminating complexity, customer focus, etc.) to operating Leanpub. It is extremely easy to get started and publish your book.

Leanpub also offers an excellent royalty plan: authors take home 90% of the revenue minus 50 cents per book. They publish without “digital rights management” crippling purchasers use of the books. Buyers have access to pdf, kindle (mobi) and epub (iPad, nook) format books and get access to all updates to the book. All purchases include a 45 day full money back guaranty.

Related: Business 901 Podcast with John Hunter: Deming’s Management Ideas TodayInterviews for Management Matters: Building Enterprise Capability