Utah Open Source Planet

Peter Abilla
no nic
shmula

» Not Accountable, Not Responsible

Team size can make a big difference in the success of your service or product. What is counterintuitive for most people is that the larger the team size, the lower the likelihood of success for your service or product. Why? Entropy can set in and large teams are inherently bad vehicles for communication. More insipid, however, is that the larger the team, there is a higher likelihood of accountability and responsibility being diffused across the team.

When accountability and responsibility is massively diffused, then the mantra holds: if everyone is charge, then nobody is in charge. In this article, I quantitatively show the inverse relationship between team size and productivity & how team size does impact the effectiveness of communication and accountability & the eventual success of the service or product.

I’ve written about efficient teams before here and here. When I was at Amazon, teams were organized into small, delta teams called “2-pizza teams”: no team should be larger than 2 pizzas can feed. It’s a great approach to team size. In my short career, I’ve learned how true that rule is. Here’s another thing I’ve learned –

2 people are smarter than one
3, 4, 5, 6, 7, 8 people are smarter than 2
a team larger than 9 people is just a big dumb gelatinous blob (acronym: BDGB)

Okay, that’s not true at a wholesale level, but it sure feels like it. A small team with highly smart and capable team members can do much more than 10 mediocre team members. The Wisdom of Crowds mentality doesn’t work that well when it comes to efficiency in teams.

A more quantitative explanation is as follows:

One of the root causes of failure in projects is communication — either a lack thereof, miscommunication, or hand-off’s. Large teams are inherently vehicles for bad communication. This is basic combinatorics — for a given project, suppose there are persons A and B. In this scenario there is only 1 communication link. Add person C, now we have 3 communication links, A-B, B-C, C-A. Add person D, then we have 6; Add person E, then we have 10 communication links. Inductively, as team size grows, the raw combinatoric communication link counts grows geometrically, not linearly. To demonstrate this, we use basic statistics of the form n-choose-r, where !, such as n!, is equivalent to n factorial, to arrive at the formula for how many pairs we can choose from n items:

shmula.com, combinatorics

For the number of pairs, we can reduce the above formula to the following:

shmula.com, combinatorics

Visually, as team size grows, the communication links grows non-linearly, but exponentially:

shmula.com, combinatorics

A Rejoinder

Do not let the above dissuade you from large teams; if the product requires a large team, then that is what is needed. Caution, is what I am arguing here. The facts are that the larger the team, the more communication channels there are and the entire process then becomes more error-prone. If the product requires a large team, then expect the above challenge and manage it.

A Conclusion

There is wisdom in Bezos’ notion of the 2-Pizza Team. Small teams — provided you have the right people — work incredibly well. Also, there is wisdom in Toyota’s usage of Obeya or “The Big Room” as a way to mitigate defects caused by large teams. A combining of the two will most likely make for a great team and a successful product.

Articles on Ethnography and Design:

Articles on Leadership:

Articles on Queueing Theory:

Articles on Operations, lean and six sigma:

by psabilla at 4:56 PM under 2-pizza teams , agile , amazon , complexity , design thinking , drum-buffer-rope , dynamic systems , gemba , heijunka , ishikawa , it at toyota , just-in-time , kanban , lean , lean consumption maps , muda , obeya , operations , regression analysis , root cause analysis , simplicity principle , six sigma , software , supply chain , takt time , team size , theory of constraints , the visual factory , toyota , variation , visual management , waste (Comments)

Peter Abilla
no nic
shmula

» Maintain Forward Tension

One principle in Wing Chun is the maintaining of forward tension. To explain, I’ll draw the distinction between Tension and Energy and show how this principle in Wing Chun can be applied to Change Management.

Tension is a type of Energy

A Wing Chun maxim goes as follows:

soft and relaxed strength will put your opponent in jeopardy

That maxim means that forward tension is not necessarily using force, or forcing through a barrier or “pushing through”. But, there is soft force, or tension, such that when a gap presents itself, then the hand or arm shoots forward like a spring. The “shooting forward” is not done with force, but is an unleashing of potential energy.

Using that definition, then, Forward Tension is much different than the overly-used business term “Breakthrough.” In the context of Forward Tension, the notion of “breakthrough” is ridiculous, because it connotes a forcing of oneself or of one’s ideas. Forcing anything only invites resistance and rebellion, not conversion.

So, in sum, tension is really potential energy and when a gap presents itself, that potential energy becomes kinetic energy. Forward Tension works with the current context in such a way that does not invite rebellion or resistance or eventual back-biting. It is open, but straightforward.

Application to Change Management

Don’t force things on people. The most humane approach to change management is to treat those involved in the change as human beings; this means having a dialogue — listen, speak, listen some more, argue a little, and steadily deposit goodwill.

As much as I like love data, I also fully understand that data does not soften hearts or change people’s minds: true change happens when people feel heard, have given their opinion, are willing to try something new, and are part of the change. The challenge in change management is largely an emotional one; a psychological one; a relational one.

Hold The Tension

Without forcing or pushing of people, maintaining the tension encourages discussion, debate, and invites people to inquire and become curious about the topic of change. That is the key: behave in such a way that it invites people to learn, argue, debate, and eventually try it out.

Tension in Wing Chun

The video below shows Sifu Grados in Chi Sao (Sticky Hands). This sensitivity exercise demonstrates the principle of holding the tension and visually explains the principle of transformation of potential energy to kinetic energy very well.

NOTE: none of the movements are rehearsed. What is taught and practiced are the principles and how those principles are applied during Chi Sao depends on the situation.

Articles on Ethnography and Design:

Articles on Leadership:

Articles on Queueing Theory:

Articles on Operations, lean and six sigma:

Advertisement: compnay formation by Jordans

by psabilla at 7:36 AM under 5s , a3 report , bullwhip effect , business , change management , click-to-ship , complexity , customer obsession , customer service , design thinking , drum-buffer-rope , dynamic systems , efficiency , ethnography , featuritis , gemba , genchi genbutsu , general , heijunka , ishikawa , it at toyota , kanban , leadership , lean , lean consumption maps , metrics , muda , obeya , operations , pareto principle , poka-yoke , process measures , productivity , quality , root cause analysis , six sigma , statistical process control , strategy , supply chain , takt time , the beer distribution game , theory of constraints , the profit tree , the visual factory , toyota , variation , visual management , waste , wing chun , zero defects (Comments)

Peter Abilla
no nic
shmula

» Fast Food Congestion

Every system has constraints — sometimes several — minor bottlenecks and major bottlenecks. What makes managing constraints even more challenging is that bottlenecks move: up-and-down the process paths.

I saw this phenomenon recently during a visit to a fast food restaurant, which I discuss in this post — but, my application of the Theory of Constraints, Lean Manufacturing, and Six Sigma as applied to a Restaurant can be applied to any Dynamic System.

One of the key lessons in The Theory of Constraints is that the contraint or the bottleneck determines the throughput for the entire system. This means, then, that if we optimize and improve a non-bottleneck, then those efforts have almost zero impact on the overall throughput of the system. It is only when we improve and optimize the contraint that we will see improvement in the throughput of the entire system.

Every system has a constraint — that is neither good nor bad — but just a fact of dynamic systems. Once you’ve identified the constraints in your system, then the next step is to manage it.

I was able to obtain some empirical volume data for a Burger King. The data below is taken from one Burger King restaurant. I imagine the numbers would be significantly different if we were to average the volume by geography, restaurant size, or by other factors. Now, consider the following process map for a typical Burger King:

Click on the image for a larger view.

For this restaurant, over the course of an average month, Burger King produces 34227 sandwiches. This means, then, that for an average hour, Burger King produces 198 sandwiches per hour during normal hours.

But, on Friday and at 12:00PM, Burger King experiences higher-than-normal volume and so we add a “Peak Multiplier” of 18% and 17.9% to arrive at 256 sandwiches during Peak Hours. The “Peak Multiplier” is not completely arbitrary, but a quasi-educated guess at the volume increase during those hours. In both cases of Fridays and Lunch Hours, we add a ~20% multiplier.

Now, let’s take a look at the process map above. We see the Assembly Step producing 200 sandwiches an hour. We consider the Assembly to be the constraint in the system. The upstream processes produces more than 200, but when we arrive at the Assembly, the capacity of that step is lower than its upstream processes. So, the maximum throughput of the entire system above is 200 sandwiches per hour.

Under normal hours, the constraint functions reasonably well. Since normal hour demand is 198 sandwiches per normal hour, the Assembly Step can produce at least at that amount — but, it’s cutting it close. Under peak volume, the constraint is not able to fulfill demand.

How To Manage a Constraint

Under normal hours, it appears that the Assembly Step can produce at expected demand. But, there are several things that could put burden on the constraint and cause it to producing less than capacity. Here are some of those items:

Rework: Having to Re-Assemble sandwiches adds undue burden on the system and exaggerates the effects of the constraint, leading to a potentially higher-than normal work-in-process, or build-up.
Set-up & Changeover: If all the parts aren’t immediately available in the Assembly step, then it could lead the operator to slow down which could lead to build-up and higher-than-normal work-in-process.

It’s easy enough to see that the Assembly Step needs some help. Here are several things Burger King — or any system with constraints — can do to better manage the natural constraints that are in every system:

Eliminate Defects at the Constraint: This means that all waste is eliminated or reduced at the constraint.
Have the Quality Steps in Front of Constraint: In support of the first bullet, make sure that the parts entering the Assembly step are free of defects.
Support the Constraint: Add labor to the constraint or more lines, if that is prudent.
Appropriately use Buffers: Systems with Constraints exhibit a feast/famine phenomena. To avoid having too much coming into the constraint or too little coming into the constraint, have a buffer of parts large enough that the constraint stays appropriately busy. Put another way, reduce the variation in front of the constraint as much as is possible. A Drum-Buffer-Rope system might be appropriate for some systems.
Evaluate the overall system: How much of the steps in the system are really value-add to the customer? What is the process-cycle effeciency of the process?

Conclusion

All systems have constraints. Identify what they are, quantify the effects, then manage it. The above Burger King example shows how this can — with some effort — be done. What are the constraints in your systems? What can you do to better manage those constraints?

+++++

Articles on Ethnography and Design:

Articles on Leadership:

Please articles on Queueing Theory below:

Articles on Operations, lean and six sigma, please visit the links below:

Advertisement: compnay formation by Jordans

by psabilla at 5:40 PM under 5s , a3 report , bottlenecks , bullwhip effect , business , complexity , drum-buffer-rope , dynamic systems , efficiency , gemba , genchi genbutsu , heijunka , ishikawa , it at toyota , kanban , lean , lean consumption maps , lean manufacturing , metrics , muda , obeya , operations , pareto principle , process measures , productivity , quality , root cause analysis , six sigma , supply chain , takt time , theory of constraints , the visual factory , toyota , variation , waste (Comments)

Peter Abilla
no nic
shmula

» Attitude and the Pyschology of Queueing

I took the kids to see a movie at a nearby dollar theater many weeks ago. We saw Mr. Magorium’s Wonder Emporium and some parts of that movie has stayed with me. I thought that the movie was actually very good: it was an overall very good feel-good movie, with a very good message. One key take-away for me was the role of a good attitude and how that can make a big, big difference in life.

Pyschology of Queueing - Psychology of Waiting Lines

Mr. Magorium puts a twist on the Psychology of Queueing. Below are the the non-exhaustive, but general principles of the Psychology of Queueing:

Unoccupied time feels longer than occupied time.
Process-waits feel longer than in-process waits.
Anxiety makes waits seem longer.
Uncertain waits seem longer than known, finite waits.
Unfair waits are longer than equitable waits.
The more valuable the service, the longer the customer is willing to wait.
Solo waits feel longer than group waits.

In one scene, Mahoney (Natalie Portman) takes Magorium (Dustin Hoffman) to a clock store so they can listen to all the clocks strike 12:00. Mahoney (Natalie Portman) whispers they only have 37 seconds until the clocks strike 12:00 and all they have to do is wait. Mr. Magorium (Dustin Hoffman) corrects her, saying that it’s 37 seconds to breathe, reflect, enjoy, regenerate, dream.

"Thirty-seven seconds well used is a lifetime," he says.

I think that’s a great lesson for all of us. Granted, in our life, we will have cumulatively waited for 2-3 years by the time we die. We can complain and be cranky for all that time, or we can have an attitude of hope and joy. Those in the background of these innefficient systems can continue to work at making the system more efficient, simpler, elegant, and customer-friendly. But, in the mean time, we can choose to use our waiting time well.

+++++

For articles on queueing theory, time-traps, operations, lean and six sigma, please visit the links below:

The Gemba is the Dojo

Managing Constraints Under Peak Volumes

Order Pipeline of Events

Variation for Dummies

On Game Theory

Series on Queueing Theory

Applied Regression Analysis

5S

Click-to-Ship Processes

Kanban Sizing and "Pull"

Lean at Krispy Kreme

Theory of Constraints and Camping

Lean for Software Development

Don’t Waste the Customer’s Time

Featuritis and the Focus on the Customer

Share This

by psabilla at 10:16 PM under business , call center and queueing , complexity , drum-buffer-rope , dynamic systems , gemba , genchi genbutsu , heijunka , ishikawa , it at toyota , kanban , lean , lean consumption maps , muda , obeya , operations , pareto principle , quality , queueing theory , root cause analysis , six sigma , statistical process control , the visual factory , toyota , variation , visual management , waste (Comments)

Peter Abilla
no nic
shmula

» Takt Time and Dumber-by-the-Minute

I remember a very humbling experience of thinking that I knew how to solve problems and being shown just the opposite by an hourly associate. That was during my internship while I was in graduate school; I was haughty, boasting that I came from a top university and demonstrating in my thoughts and body language other prideful nonsense. I’ve learned that you can learn something from anybody. I’d like to think that I’ve become wiser since then and have changed my behavior to reflect that experience.

That particular experience involved a scheduling activity of auto parts being received, followed by a "stowe" process, where these auto parts would then be placed in storage bins. I sat back and observed from some time and even participated in the actual stowing of the material in the warehouse. My aim was to improve that particular process and regulate the stowing activity with the drumbeat of the receive activity.

Since I was a prideful graduate student, I decided to pull out my discrete event simulation and operations research toolbag — you know, stuff that is clinically interesting, but sometimes not useful — only to be taught by a few hourly associates a simple and elegant way to level the work of receive-to-stow: Takt Time.

Takt Time

Takt Time is the maximum allowable time in order to meet demand; Takt Time is the pace by which product is produced and must fall within the Takt Time or set equal to the Takt time; if not, then there will be customer demand that might go unfulfilled.

Takt Time is defined as the following:

Takt Time = (Net Available Production Time / Required Output Rate)

The Process

I do not have a picture for you, so please bear with the verbal explanation. For this process, we are dealing with a supply parts distribution center that stores material for cars. There are several receive-runs from tier-2+ suppliers to this warehouse where the parts are consolidated and stored.

This warehouse is divided into zones. The parts arrive in a bin on the receive dock, and the bins are then placed on a manual conveyor belt to a staging area. We have labor (people) that take these bins, place them on carts, and walk to the respective zone to offload the bin. Then the associate team member returns to pick up another bin.

Here is the question: how frequently should we tell the tier-2 suppliers to make a part drop-off? And, how much material should they plan on delivering for each run? Other questions: If you are a tier-2 supplier, at what point does it make economic sense to ship a less-than-truckload (LTL)? What about quantity-discount discussion?

All good questions, but I won’t consider most of them for this post. I want to localize our discussion on "How frequent should the tier-2 suppliers make a run to this center?"

Pull

Assume that the end-to-end system is a clean Pull from the customer all the way down the supply chain using a series of simple but elegant Kanban cards. Also further assume that the information flow downstream and material flow upstream has no defects or rework. We are only dealing with the question of regulating the pace between Stowe-and-Receive.

Takt Time can answer this question: Assume we have 1 person that works 6 productive hours. Let’s also assume that in order to meet upstream demand (parts-to-manufacturing plant) is known and stable and is 150 bins per 6 hour day. Given this, we have arrived at a Takt Time — how much maximum time can be alloted per Stowe.

Takt Time = [(6 hours * 60 minutes) / (150 Bins)]
Takt Time Per Run = 2.4 Minutes

This means that for each operator, she has at most 2.4 minutes to receive-walk-stowe and then return for the next run. Each run would represent a Cycle — hence, the term Cycle Time.

Improving Takt Time

We don’t really improve Takt Time, per se. We can reduce the Cycle Time and the content of the work involved in that Cycle, such as reducing or eliminating waste and non-value added steps, thereby influencing the Takt Time, or overall beat of the line. Specifically, we can do the following:

Reduce Variation
Reduce Idle Time
Reduce set-up time
Reduce or eliminate waste
Better manage constraints

To have a shorter Takt Time, improvements must be made on Cycle Time — that is, each cycle has to become shorter, which in turn would result in an improved Takt Time. It’s important to note that, in proper nomenclature, you cannot improve Takt Time — Takt Time is-what-it-is; a fact. It is Cycle Time that can be improved, which is a component of Takt Time.

Back to the Beginning

Back to the question of how to regulate Receive-to-Stowe: the aggregate Takt Time of all [(stowers * productive hours * 60 minutes) / Customer Demand]. The Customer in this case is the nearby manufacturing plant that meets the upstream demand of the customer, manifested in orders from auto dealers.

So, we see Pull all the way from the customer downstream to the atomic component parts.

Dumber-by-the-Minute = Wisdom

The hourly associate that showed this to me and explained, in a very down-to-earth and human way, helped me to "see" the world in a different way. She helped me to better understand my local concern and how that is truly an important part of the overall story for this business; that experience helped me to gain some wisdom, withhold judgment, helped me to understand that my education from a fancy school really doesn’t mean much, and that experience was the catalyst of my Lean Journey, which I’ve been on now for 8 years. I’m still quite young in both age and in experience, but am so thankful for humbling and growing experiences.

Share This

by psabilla at 9:59 PM under 5s , business , drum-buffer-rope , gemba , genchi genbutsu , heijunka , ishikawa , it at toyota , kanban , lean , lean consumption maps , muda , obeya , operations , pareto principle , six sigma , takt time , theory of constraints , toyota , variation , waste (Comments)

Peter Abilla
no nic
shmula

» The Hidden Factory: Would the Customer Pay for That?

The Hidden Factory is a term that refers to activities in an operation or standard operating procedure (SOP). A few examples of Hidden Factories are workarounds, rework, or any of the 7 wastes, which I will describe below. Most organizations have some form of a Hidden Factory and being able to "see" these hidden factories in an organization requires learning to see what waste is and understanding that waste in any operation — service or manufacturing — can be a substantial drain on the bottom line, top line, on employee morale, shareholders and, most importantly, the customer.

In fact, one very important litmus test for an activity is this: "If the customer knew the details of process x, would she be willing to pay for it?" In other words, suppose substantial rework was required to manufacture a widget and that rework cost was baked-into the cost of 1 unit of a widget, would the customer be willing to pay for the firm’s defects? Would the customer be willing to pay for the firm’s internal inefficiencies?

What is a Process?

A process is an systematic activity comprising of smaller activities that culminate in an outcome — service or product. A process can take up time, space, and resources. All processes can be categorized into the following categories: Value-added, Non-value added but necessary, and Non-value added.

From the Customer’s Perspective:

Value-added: This step in the process adds form, function, and value to the end product and for the customer.
Non-Value-Added: This step does not add form, function, or assist in the finished goods manufacturing of the product.
Non-Value-Added-But-Necessary: This step does not add value, but is a necessary step in the final value-added product.

(2) & (3) naturally create waste, of which there are 7 types:

Over-Production: Producing more than is needed, faster than needed or before needed.
Wait-time: Idle time that occurs when co-dependent events are not synchronized.
Transportation: Any material movement that does not directly support immediate production.
Processing: Redundant effort (production or communication) which adds no value to a product or service.
Inventory: Any supply in excess of process or demand requirements.
Motion: Any movement of people which does not contribute added value to the product or service.
Defect: Repair or rework of a product or service to fulfill customer requirements.

It’s important to understand “Value” in terms of the customer. From the customer’s perspective, “Value” could be defined in the form of a question:

Which process steps (and associated costs) do our customers not have to bear?

It’s a revealing question — most companies are glad that they do not have to reveal how their product or service is created, for fear of their inefficient processes and wasteful operations revealed to the customer. This stance is sometimes aptly called "not revealing how the hot dog is made", amicably referring to the unknown contents of the hot dog.

Process Cycle Efficiency

There is a metric that helps to identify how much of a process is actually value-added. It requires a few things:

Map the process.
Identify the Value-added steps, non-value added steps, and the non-value added but necessary steps.
Stratify your map according to the items in #2
Add a time dimension to the process steps.

Once you have completed steps (1) - (4), then you can simply calculate how much is actually value-added, as a percentage. The time for the entire process — end-to-end — is called a cycle time. To identify the Process Cycle Efficiency, you just divide the value-added time by the cycle time for the process.

Process Cycle Efficiency = (Value-added Time / Cycle Time)

For example, take the hypothetical process below:

process cycle efficiency, lean consumption maps

The process above has a cycle time of 860 seconds. So, the Process Cycle Efficiency could then be calculated by doing the following:

Process Cycle Efficiency = 182 / 860 = .21, or 21%

In other words, only 21% of the process above is considered value-added to the customer. Put another way, the customer might be bearing more than 75% of the cost associated with the waste above. Knowing this, the firm should aim to increase the Process Cycle Efficiency of the process by eliminating or reducing the waste.

Data like this can help the firm increase their value-added percent to the customer by eliminating or reducing the waste in their process. Doing this would put the customer first and allow the firm to "get their house in order." I consider the above excercise to be simple, yet incredibly helpful for the firm to make sure that they provide maximum value to the customer; it’s a fudiciary duty to the customer.

Think about your processes? How much is really value-added to the customer?

+++++

Please find originally-written articles on Queueing Theory below:

For a few articles on Operations, lean and six sigma, please visit the links below:

The Gemba is the Dojo

Managing Constraints Under Peak Volumes

Order Pipeline of Events

On Game Theory

Series on Queueing Theory

Applied Regression Analysis

5S

Click-to-Ship Processes

Kanban Sizing and "Pull"

Lean at Krispy Kreme

Theory of Constraints and Camping

Lean for Software Development

Don’t Waste the Customer’s Time

Featuritis and the Focus on the Customer

Share This

by psabilla at 4:26 AM under 5s , business , customer obsession , drum-buffer-rope , dynamic systems , gemba , genchi genbutsu , heijunka , ishikawa , it at toyota , kanban , lean , lean consumption maps , muda , obeya , root cause analysis , six sigma , statistical process control , theory of constraints , toyota , variation , waste (Comments)

Peter Abilla
no nic
shmula

» Featuritis and the Customer Experience

The more I learn and practice ethnography and design-thinking, the more I notice subtle but incredibly frustrating experiences. For example, I had a frustrating experience with a faucet that was in the hospital room where our adopted baby girl, Mylie, was born. This faucet is an automated one — with a sensor. So, whenever an object passes the sensor, the faucet would turn on even if the intention of the human was not to use the faucet.

A few facts about this faucet: this faucet was in the corner of the room, against the wall. It is a faucet that has a sensor, whereby an object would cross the sensor and then a signal would be sent for the faucet to expel water. I imagine the designers of this faucet designed this hospital faucet this way to encourage bacteria-free habits — that is, the sensor eliminated the need for a knob that both turns-on and turns-off the water. That is a good and charitable thought — but totally wrong. Here is a picture of the hospital faucet:

shmula.com, faucet, design thinking, ethnography, featuritis

And another picture of the faucet:

Notice the faucet head with the sensor at the base. To the right of the base, notice the knob? What does the knob do, you ask. Answer: nothing. Whenever the faucet turned on, my first reaction was to turn the only-available knob, only to find out that the knob does nothing. Very frustrating.

Root Cause Analysis on "Why did the Faucet Turn on Unintentionally?"

Following Taiichi Ohno’s 5-Why’s, it is important to understand why the faucet turned-on when that was not the intention:

Why did the faucet turn on unintentionally?
Because whenever an arm or hand passed across the sensor photo-eye, the faucet would turn on.
Why would an arm or hand pass the sensor photo-eye?
Because we need to put or get our camera, jackets, or other belongings.
Why did we need to put or get our camera, jackets, or other belongings?
Because the only available counter in the room to place anything was beside the faucet.

So, we see from this quick and effective excercise that the root cause of unintentionally-turning-on-of-the faucet was that the only available counter-space was next to the faucet. Hence, whenever we needed to put or get our stuff, our hand or arm would cross the sensor and then the faucet would turn-on.

Practical Solutions

There are several practical solutions to the verified root cause. One simple and very practical one is to create more counter space, preferably away from the faucet and simultaneously eliminating the available counter-space to the right and left the faucet. Another practical solution is to revert back to the good ‘ol faucet with a knob that actually works. One variant of this "knob" is that it could be a foot pedal, thereby encouraging sanitized hands.

There are several that, I’m sure, you can think of. These are just a few that I came up with.

The True Tragedy of Featuritis

The real tragedy of poor usability of devices and products is that the user feels stupid. For a discussion, below is Kathy Sierra’s Featuritis Curve

As one walks the curve to the right, the user hits an inflection point where there is an equilibrium between the number of features and the user’s happiness. As the user continues that walk to the right, the user eventually gets to the point of what I call "user resignation" — where the user gives up, calls it quits, and blames self.

To some degree, I felt this way about the hospital faucet. Although the faucet didn’t have the complexity of features, it still behaved that way and I felt dumb that the "knob" wasn’t working like I expected it to work. Moreover, I felt dumb everytime the faucet turned on when I didn’t mean for it to turn on. The real tragedy of featuritis is that the user is burdened with feelings of self-loathing and self-blame. From a businesses perspective, this means that users are unhappy and will abandon the product or service.

Who’s Fault is it Really and The Customer Experience

Here’s what my good friend and fellow University of Chicago Alum, Aza Raskin, son of Jef Raskin (inventor of the Macintosh) says regarding Humane Design:

The main thing you have to remember—and please remember this, because it could be vital to your sanity—is that any problems you have with an interface are not your fault. If you have trouble using your microwave, it’s not because you’re "not good with technology", it’s because the people in charge of designing the interface for that microwave didn’t do their job right. User interface design is incredibly hard, and carries with it a great deal of responsibility; this is something that’s taken quite seriously when it comes life-critical systems such as flight control software. But in today’s consumer culture, what should be blamed on bad interface design is instead blamed on the "incompetence" of users. Just remember that it’s not your fault.

A Crappy Faucet and A Cute Baby

The hospital is still there, probably with the same crappy faucet. But, I take with me a few things:

Mylie is healthy and is home. Mylie’s birth parents are also home now. I am thankful to them for choosing us to be Mylie’s parents.
The way interfaces, products, and services are designed have a profound impact on all of our lives.
Simple is best — Keep It Simple Stupid (KISS) — this is a true principle.
There is still a lot of opportunity to do good in the world of products and services.
There is still a lot of opportunity to do good in the world.

+++++

Articles on Ethnography and Design:

Please find originally-written articles on Queueing Theory below:

For a few articles on Operations, lean and six sigma, please visit the links below:

The Gemba is the Dojo

Order Pipeline of Events

On Game Theory

Series on Queueing Theory

Applied Regression Analysis

5S

Click-to-Ship Processes

Kanban Sizing and "Pull"

Lean at Krispy Kreme

Theory of Constraints and Camping

Lean for Software Development

Don’t Waste the Customer’s Time

Featuritis and the Focus on the Customer

Share This

by psabilla at 6:54 AM under aza raskin , business , complexity , drum-buffer-rope , dynamic systems , ethnography , featuritis , gemba , genchi genbutsu , heijunka , it at toyota , kanban , leadership , lean , lean consumption maps , muda , obeya , operations , pareto principle , product development , quality , root cause analysis , simplicity principle , six sigma , statistical process control , strategy , variation , waste (Comments)

Peter Abilla
no nic
shmula

» Bottlenecks and Fast Food

One of the key lessons in The Theory of Constraints is that the contraint or the bottleneck determines the throughput for the entire system. This means, then, that if we optimize and improve a non-bottleneck, then those efforts have almost zero impact on the overall throughput of the system. It is only when we improve and optimize the contraint that we will see improvement in the throughput of the entire system. Every system has a constraint — that is neither good nor bad — but just a fact of dynamic systems. Once you’ve identified the constraints in your system, then the next step is to manage it.

I was able to obtain some empirical volume data for a Burger King. The data below is taken from one Burger King restaurant. I imagine the numbers would be significantly different if we were to average the volume by geography, restaurant size, or by other factors. Now, consider the following process map for a typical Burger King:

Over the course of an average month, Burger King produces 34227 sandwiches. This means, then, that for an average hour, Burger King produces 198 sandwiches per hour during normal hours. But, on Friday and at 12:00PM, Burger King experiences higher-than-normal volume and so we add a "Peak Multiplier" of 18% and 17.9% to arrive at 256 sandwiches during Peak Hours. The "Peak Multiplier" is not completely arbitrary, but a quasi-educated guess at the volume increase during those hours. In both cases of Fridays and Lunch Hours, we add a ~20% multiplier.

Now, let’s take a look at the process map. We see the Assembly Step producing 200 sandwiches an hour. We consider the Assembly to be the constraint in the system. The upstream processes produces more than 200, but when we arrive at the Assembly, the capacity of that step is lower than its upstream processes. So, the maximum throughput of the entire system above is 200 sandwiches per hour.

Under normal hours, the constraint functions reasonably well. Since normal hour demand is 198 sandwiches per normal hour, the Assembly Step can produce at least at that amount — but, it’s cutting it close. Under peak volume, the constraint is not able to fulfill demand.

How To Manage a Constraint

Under normal hours, it appears that the Assembly Step can produce at expected demand. But, there are several things that could put burden on the constraint and cause it to producing less than capacity. Here are some of those items:

Rework: Having to Re-Assemble sandwiches adds undue burden on the system and exaggerates the effects of the constraint, leading to a potentially higher-than normal work-in-process, or build-up.
Set-up & Changeover: If all the parts aren’t immediately available in the Assembly step, then it could lead the operator to slow down which could lead to build-up and higher-than-normal work-in-process.

It’s easy enough to see that the Assembly Step needs some help. Here are several things Burger King — or any system with constraints — can do to better manage the natural constraints that are in every system:

Eliminate Defects at the Constraint: This means that all waste is eliminated or reduced at the constraint.
Have the Quality Steps in Front of Constraint: In support of the first bullet, make sure that the parts entering the Assembly step are free of defects.
Support the Constraint: Add labor to the constraint or more lines, if that is prudent.
Appropriately use Buffers: Systems with Constraints exhibit a feast/famine phenomena. To avoid having too much coming into the constraint or too little coming into the constraint, have a buffer of parts large enough that the constraint stays appropriately busy. Put another way, reduce the variation in front of the constraint as much as is possible. A Drum-Buffer-Rope system might be appropriate for some systems.
Evaluate the overall system: How much of the steps in the system are really value-add to the customer? What is the process-cycle effeciency of the process?

Conclusion

All systems have constraints. Identify what they are, quantify the effects, then manage it. The above Burger King example shows how this can easily be done. What are the constraints in your systems? What can you do to better manage those constraints?

+++++

Please find originally-written articles on Queueing Theory below:

For a few articles on Operations, lean and six sigma, please visit the links below:

The Gemba is the Dojo

Order Pipeline of Events

On Game Theory

Series on Queueing Theory

Applied Regression Analysis

5S

Click-to-Ship Processes

Kanban Sizing and "Pull"

Lean at Krispy Kreme

Theory of Constraints and Camping

Lean for Software Development

Don’t Waste the Customer’s Time

Featuritis and the Focus on the Customer

Share This

by psabilla at 6:14 AM under 5s , business , complexity , drum-buffer-rope , dynamic systems , gemba , genchi genbutsu , heijunka , ishikawa , it at toyota , kanban , lean , lean consumption maps , metrics , obeya , operations , pareto principle , queueing theory , root cause analysis , six sigma , statistical process control , theory of constraints , toyota , variation , waste (Comments)

Peter Abilla
no nic
shmula

» Ask Mary Poppendieck Anything!

In August 2006, Mary Poppendieck was nice enough to entertain questions from my readers on the topic of Lean for Software. Some great questions were submitted and Mary answered them.

Well, she’s willing to do that again, so please submit your questions for Mary and she will answer some of those questions. I will then post her responses on future posts. Here’s the process:

Submit your questions on Lean for Software or Agile in the comments below.
I will close comments on November 25.
I will begin posting Mary’s answers after November 25, 2007.

Here is Mary’s Biography:

Mary Poppendieck has been in the Information Technology industry for thirty years. She has managed solutions in software development, supply chain management, manufacturing operations, and new product development.

A popular writer and speaker, Mary’s classes apply lean principles to Software Development problems and offer a fresh perspective on software development processes. She is the author of Lean Software Development: An Agile Toolkit for Software Development Managers (Paperback) and Implementing Lean Software Development: From Concept to Cash (Paperback).

Please ask your tough questions — Mary will most likely have something to teach us all.

+++++

Please find originally-written articles on Queueing Theory below:

Utah Open Source Planet

A Rejoinder

A Conclusion

Articles on Ethnography and Design:

Articles on Leadership:

Articles on Queueing Theory:

Articles on Operations, lean and six sigma:

How To Manage a Constraint

Conclusion

+++++

Pyschology of Queueing - Psychology of Waiting Lines

Other Queueing Articles

+++++

Takt Time

The Process

Pull

Improving Takt Time

Back to the Beginning

Dumber-by-the-Minute = Wisdom

What is a Process?

Process Cycle Efficiency

+++++

Root Cause Analysis on "Why did the Faucet Turn on Unintentionally?"

Practical Solutions

The True Tragedy of Featuritis

Who’s Fault is it Really and The Customer Experience

A Crappy Faucet and A Cute Baby

+++++

How To Manage a Constraint

Conclusion

+++++

+++++