Quality and Innovation

If you have at least 5 years broad experience in quality, please help us validate the “Quality Systems Development Roadmap” originally published in Quality Progress in 2008 (http://asq.org/quality-progress/2008/09/basic-quality/starting-from-scratch.html). This is part of an expert systems project developed by Doug Jin, a student at James Madison University, under the guidance of Nicole Radziwill, JMU faculty member and ASQ member leader.

The 5-page, 13-question survey will be available until January 15, 2011 or 1500 responses are received, whatever comes first, so contribute now at http://www.surveymonkey.com/s/W2LYFYP!

I was talking to a group of professors from James Madison University yesterday, when the topic shifted to “discrete event simulation”. They asked me if I knew anything about it – I said no. I don’t think I had ever heard of those words strung together in the same phrase, and so immediately assumed that this domain was just something I had never been exposed to. They also told me that they were using ProModel to do a lot of their discrete event simulation.

I’m addicted to learning new things, so I checked out to see what ProModel was all about so I would know what “discrete event simulation” was. And guess what! That’s the term for plant layout, for simulating new manufacturing processes, for designing kanban systems, for designing supply chains and other networks, for setting up queueing systems, for doing SPC and for managing your Six Sigma analytics. So I guess I do know something about “discrete event simulation”! I’m also wondering why I’ve never seen this product advertised in Quality Progress – it looks like it’s pretty good, and pretty comprehensive.

This reminded me that jargon can impede or enhance communication, depending upon the capabilities and understanding of the communicators. Neil Ward-Dutton, in a December 2006 post, collected some articles on this theme and reflected on them in “On jargon, and creating a common language.” He contrasts a message about the benefits of Web 2.0 presented in two ways: one filled with technical jargon, explaining the way it came to be, and one explaining the same thing but from the perspective of how Web 2.0 influences and affects people. The use of jargon – or the avoidance of jargon – can either communicate competence in a field or alienate people who need to know more about it.

Awareness of whether a term or a phrase is jargon can help us understand whether we are communicating accurately.

If I was aware of the nature of the term “discrete event simulation” I would have said “Sure! I really like discrete event simulation. In fact, I really enjoy designing plant layouts (which can be useful for designing software systems too), I am insanely enthusiastic about inventory models, and these are the kinds of analytical things that we do in Six Sigma projects all the time.” But no, I missed an opportunity to communicate – and maybe even to learn new things about modeling – because of jargon.

It reminds me of when I was a meteorology student several years ago. In one of our dynamics classes, I was dumbfounded by the number of times the professor referred to “zonal” and “meridional”. I had no idea what these two words meant – I could guess, but I might be wrong – so I searched all through our textbooks to find anything that would tell me about these two words. They were NOWHERE. And the dictionary was no help either. So one day I asked the professor, in class, what “zonal” and “meridional” meant. Her response is etched in my psyche forever: “If you don’t know what those words mean, then you shouldn’t be in this class.” Now this was in the days before Google, so I couldn’t just go look it up. What do you think I did? I felt totally embarrassed, crushed because I didn’t know something that was apparently so easy, decided to hide my lack of knowledge, and struggled through the class. I was even too embarrassed to ask my classmates. Years later, when I figured out the answer to my simple question, everything fell in place and I understood what went on!
The far more constructive answer from my professor would have been: “Zonal refers to the east-west direction and meridional refers to the north-south direction. So if we have zonal flow, it’s oriented predominantly east to west, and if we have meridional flow, it’s oriented primarily north to south.” My response would have been “Excellent! That’s simple! Now I understand what the equations are trying to say!”

The lesson here: no questions are stupid. Sometimes, a stupid question just reflects that someone’s trying to break through the barrier of jargon. This is a positive thing – it means they’re trying to figure stuff out! After this experience with my dynamics professor, I vowed that I would never think someone was totally stupid if they were asking (what I thought was) a simple question. I hope my coworkers and staff members feel that I’ve followed through on this.

(It reminds me of another time in that same course. We did a lot of multivariate calculus and differential equations, and the professor kept referring to “zed,” but for the life of me I couldn’t find the “zed symbol” in any of the equations. And none of my books would tell me what the “zed symbol” looked like. I’ll leave this joke as an exercise for the reader.)

This is the fourth and final installment of my collaboration with John Hunter and friends on the Year-End Management Improvement Carnival, where we review the best management improvement blogs and share which posts we found to be the most insightful or helpful. Today I have the privilege of bringing you a few gems from the iSixSigma blogosphere.

PART 4 of 4 – The iSixSigma blogs are written by a cast of columnists who share their experiences with the practice of quality improvement. The favorites I’ve picked out here are only the tip of the iceberg… there are many more on the site.

Innovation and Six Sigma (5/9/2008) – This article aims to answer the question “Does Six Sigma kill innovation?” In addition to being a thought-provoking article, the collection of comments is worth reading as well. I particularly liked this perspective: “I’m reminded of a story I was once told about an author who decided to write an entire novel without using the letter E. You’d think this would be incredibly limiting, but in fact the author ended up learning many, many new words and taking his writing in entirely new directions. The structure forced him to break old habits and think in new ways.”

The iPod Did Not Come From a Focus Group (3/3/2008) – Development of the iPod is an example of customer and market-driven innovation. The author of this article notes that “your company probably knows more about what is possible than most of your customers; but the lesson I take away from the Apple example is this: some of our customers know a lot more than we do, and we ignore them at our peril.” There’s also a pointer to an excellent 2002 article in the Harvard Business Review.

Six Sigma: The Laissez-Faire of Politics (1/28/2008) – In this article, the author explores how to solve a real public policy issue using Six Sigma: reducing the consumption of plastic bags (like the ones you get at the grocery store) on the national level. “If there is one area in society that definitely needs an injection of Six Sigma, it’s politics. Just like the working world of business, people want a silver bullet quick fix that sounds good and will make people feel good. Politicians often open their mouths without performing due diligence and as a result only partially address an issue.”

What You Measure is What You Get (12/22/2008) – This post reflected on the role and meaning of measurement (one of my favorite issues). “Perhaps what you measure is what you get. More likely, what you measure is all you’ll get. What you don’t (or can’t) measure is lost” – H. Thomas Johnson

Six Sigma Project Failure (7/28/2008) – What’s required for a Six Sigma project to fail? Conflicting definitions are explored in these survey results. (This is somewhat related to Eight Reasons Why Projects Fail (4/24/2008), another good post.)

Return to Part 1 of 4 –>

Return to John Hunter’s Management Improvement Carnival: 2008 Year in Review –>

This is the third installment of my collaboration with John Hunter and friends on the Year-End Management Improvement Carnival, where we review the best management improvement blogs and share which posts we found to be the most insightful or helpful.

PART 3 of 4 – Clarke Ching’s stream-of-consciousness blog covers random musings, cartoons, links to useful articles, recipes, mathematical puzzles and games, and thoughts about quality-related techniques including Theory of Constraints and software development.

Testers – the worst thing that happened to software development? (5/30/2008) – This story describes a first-person view of how software quality can be achieved more easily – by studying the successful approaches used by good maintenance teams. “There’s a huge amount that development managers (i.e. those that work on bigger projects) could learn from the way good maintenance teams work. The first would be to break down their work into smaller chunks.” (Again, this reminds me of “stackless thinking”which really appeals to me.)

Critical Chain Scheduling (8/22/2008)- Clarke wrote an article, published over at stickyminds.com, covering how to use the critical chain method to improve scheduling in agile development environments. “Critical Chain, as I’ve described, is a great way of rebuilding trust between managers and their staff. In fact, it is THE best way I’ve found. It’s also sorely needed, judging by some of the comments.”

Lord Kelvin (9/13/2008) – Why measure things? On a trip to Scotland, Clarke reflected on this question as he pondered the intro to Douglas Hubbard’s book, How to Measure Anything: “When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the state of science.”

Go to Part 4 of 4 –>

This is the next installment of my collaboration with John Hunter and friends on the Year-End Management Improvement Carnival, where we review the best management improvement blogs and share which posts we found to be the most insightful or helpful.

PART 2 of 4 – Europe’s ”#1 Blog for Software Development Managers” has posted an excellent review of the most popular 2008 articles from their site, based on the site traffic throughout 2008. Here are my personal favorites.

A Theory of Everything for Software Development (8/7/2008) – Physicists pursue the grand unified theory to explain space, time and everything in between… while noop.nl attempts to reconcile the myriad of approaches to software development by reminding us of context-dependent approaches. Here’s a sample: “Unix and Windows are both proper solutions, though each in its own limited cultural context. And they cannot both be the best solution at the same time and place. (And might I suggest that, in the case of operating systems, a Theory of Everything has already been found with the invention of virtual machines? Just a wild thought.)”

Simple vs. Complicated vs. Complex vs. Chaotic (8/20/2008) – You can have predictable, complex, and chaotic systems that are simple – or, you can have predictable, complex and chaotic systems that are complicated. This is the best description (and collection of online references) I’ve seen to explaining the differences between these concepts. “My computer is complicated. My software project is complex. My house is complicated. My household is complex. My blog is complicated. My thoughts are complex. Your dinner is complicated. Your dog is complex.”

Thank You, Stupid Americans (4/23/2008) – This is an interesting blend of software development insights and politics! Although I don’t personally equate simplicity with stupidity, and I realize there are plenty of smart Americans too, I found this to be a lighthearted and stimulating read.

How to Handle Many Simultaneous Projects (9/30/2008) is also an excellent commentary. I don’t know any manager who doesn’t have this issue – whether they are a quality manager, a technology manager, a construction manager, or a manager of software development.

Go to Part 3 of 4 –>

I’m privileged to be partnering with John Hunter and friends to produce the Year-End Management Improvement Carnival. Our goal is to review the best management improvement blogs out there, and find out what gems were posted during 2008 – then take you on a guided tour of the past year’s most intriguing management insights.

PART 1 of 4 - The first three favorites on my list come from David Anderson’s http://www.agilemanagement.net, a blog that focuses on effective and productive implementation of agile methods in software development and management.

Providing Value with Lean (3/31/2008) – One of the most important considerations while implementing a quality program or process improvement initiative is that you focus on the right aspects of the problem at the right times. This is much easier said than done, especially since the problem solving environment is socio-technical – and as a result, complex. But David makes the excellent point that “doing lean” means more than just eliminating waste. You have to take a systems perspective, and first consider how value is to be added, then analyze the process for flow, and then work on eliminating waste. Sometimes, to get a better process, you have to add waste before the improvements can be realized in a sustainable fashion.

Recipe for Success (9/5/2008) – David says: “This is the mechanism I use to achieve sustainable pace and to implement a pull system which provides a nice mechanism for simple prioritization. Prioritizing becomes easier when you have demand balanced against throughput of work items.” In addition to the two variants on the recipe he presents, another reason I like this post is that it reminds me of how the concept of “stackless” programming languages can inform efficient workflow.

Personal Hedgehog (11/2/2008) – What are you uniquely good at? What are you passionate about? What motivates you economically? The most productive people are in roles that fit them well, and the Personal Hedgehog concept can help you find your niche. (Might also be good for managers who want to help their team members find a good fit.)

(I’m also intrigued by David’s concept of an unconference.)

Go to Part 2 of 4 –>

One of the most critical skills that a technology manager can have – or any manager, really – is the ability to interpret data and assess whether or not it reflects reality. Why is this important? Because good managers base their decisions at least in part on data, so the quality of the decision is often related to the quality of the data on which the decision is based. (One of the tenets of Six Sigma, for example, is “data-driven decision making”.)

So what if you were basing a decision on the quality of the election polls currently being conducted? Six Sigma experts and practitioners, take note: today’s election polls offer up a really effective lesson on threats to validity which, if human subjects are ever a part of your quality improvement efforts, you need to be aware of these sorts of issues:

[Poll results and margins of error work] pretty well if you’re interested in hypothetical colored balls in hypothetical giant urns, or survival rates of plants in a controlled experiment, or defects in a batch of factory products. It may even work well if you’re interested in blind cola taste tests. But what if the thing you are studying doesn’t quite fit the balls & urns template?

• What if 40% of the balls have personally chosen to live in an urn that you legally can’t stick your hand into?
• What if 50% of the balls who live in the legal urn explicitly refuse to let you select them?
• What if the balls inside the urn are constantly interacting and talking and arguing with each other, and can decide to change their color on a whim?
• What if you have to rely on the balls to report their own color, and some unknown number are probably lying to you?
• What if you’ve been hired to count balls by a company who has endorsed blue as their favorite color?
• What if you have outsourced the urn-ball counting to part-time temp balls, most of whom happen to be blue?
• What if the balls inside the urn are listening to you counting out there, and it affects whether they want to be counted, and/or which color they want to be?

If one or more of the above statements are true, then the formula for margin of error simplifies to:

Margin of Error = Who the hell knows?

Because, in this case, so-called scientific “sampling error” is completely meaningless, because it is utterly overwhelmed by unmeasurable non-sampling error. Under these circumstances “margin of error” is a fantasy, a numeric fiction masquerading as a pseudo-scientific fact.

Read the whole article at http://iowahawk.typepad.com/iowahawk/2008/10/balls-and-urns.html. It’s a winner. (And thanks, Mary Pat, for posting this on Facebook.)