Is it an enhancement or a bug?

From a user’s perspective, whether you intended the code that way or not, whether it is a “bug” (I didn’t intend it to do that and you don’t like it) or an “enhancement” (I did intend that, but you don’t like it), doesn’t matter.

The distinction we make on this topic is one of vanity. We want to somehow feel better for having done as we were told and yet not satisfied our customer. How is it ok to just be the order taker, to claim that we have done as asked, and that the change requested is an “enhancement”? In effect, “this is not my fault.”

It is your fault. It is OUR fault. We are one company, one organization, with a single customer (or group of customers, it doesn’t really matter) to serve. If we fail to serve that market, whether it is through coding incompetence (bugs) or failure to recognize the need (enhancements) doesn’t matter.

What matters is that we aren’t meeting their need, and beyond that, the distinction we make between bug and enhancement is only a small piece of information in the search for a preventable root cause.  If the customer doesn’t like it, it doesn’t matter the goodness of our intention. It must be remedied. The customer does not care how the undesirable behavior was introduced, just that it exists at all.

I fail… A LOT

Failure may well be the hallmark of Six Sigma work everywhere. I know what you’re thinking… “that’s exactly why people shouldn’t use Six Sigma! It doesn’t work!” But, in fact, I am here to argue that how often you fail may be a measure of how well Six Sigma is working.

If you’re in software development you know that there are no silver bullets for the problems that appear to plague us. (If you believe otherwise, well, I’m really not sure what to tell you) Every technology trend to date has yet to generate any major change in productivity or quality for a disproportionately low investment. Third generation languages, fourth generation languages, APIs, automation, static code analysis, code reuse, Agile… none of them have been the miracle they claim to be. They in essence, failed to live up to their expectations.

But a few proven good things have come out. They’re not silver bullets, but they’re very powerful when used properly… use cases and Fagan-style inspections come to mind. Most of what has come out though… failures. CASE… bleh. Code generators… bleh. Requirements management solutions… ho hum. Simply put, in a free market anything that would give such a disproportionate advantage to your competition would be quickly adopted by your own team. That hasn’t universally happened for almost anything I can think of.

And as I looked back on all the times I’ve tried to make process change and how many times it hasn’t worked, I can see how someone would say “Six Sigma = failure”. It’s a bad overgeneralization. Six Sigma often has failures, but it also has wins. And if you look at the wins, they’re often disproportionate wins – little effort, major breakthrough. Not always does this happen. Rarely, in fact. But when it does, Six Sigma earns its keep.

The nature of my work is such that I often will find almost no benefit, or very little, from the process change I tried. It seems like a good idea but it just doesn’t work out or it is hard to maintain or it actually makes things worse. But every now and again I hit one out of the park.

The reality of process improvement is that most of the times at bat (to continue the metaphor) you strike out. Accept that you will fail a lot when trying to make something better. And then, once in a rare while, you’ll have a huge success – a grand slam, as it were.

Failures and Six Sigma do go hand in hand. But failures are a measurement of how many times you tried. You can’t fail if you don’t try, but you can’t succeed either. Fail often because that means trying often.

Making someone else do it isn’t lean

Being lean is about the elimination of non-value added work, but this consideration should not be made in a vacuum. At one time I was working with a team of testers who were telling me how they were getting leaner and not doing testing when it wasn’t necessary.

I asked them how that was possible. They said “we’ve asked the developer to decide whether or not testing is appropriate” and went on to explain the various elements of the decision tree the developer would have to go through. I said, “why don’t you just make that decision? You’re just as capable of determining it.”

“But then we’d have to do that work, and that wouldn’t be lean.”

Forcing work out of your team and on to someone else’s team is not leaning out the process. It is just pushing it around. Consider the auto industry; many of them claim to be leaner for having forced their suppliers to do most of the assembly work for them. Yes, it is true that the maker of your car didn’t do the work anymore, so they didn’t have to pay the labor or spend the time doing the assembly, but that didn’t mean the work went away. It just went somewhere else.

It’s a reminder that we have to look at a process holistically to truly lean it out. It isn’t a question of “do I have to do this thing?” but of “do any of us have to do this thing?” A waste is a waste no matter who is responsible for creating it. If you ask the first question, you do what the QA team did and just pushed the waste around. If you ask the second question instead, maybe you just decide you don’t need to do the thing at all.

I’ll leave you with a good counter-example from a software textbook I was reading about designing for the users instead of just solving the problem you could with the computer (sorry, I can’t remember the name of the text at the moment). Essentially what was happening was that the post office was delivering renewals, new memberships and cancellations all to this company. The company wanted to solve the labor problem with software, but ended up making it worse. One of the things that was problematic was that each type of request (renewal, new member, cancel) needed a different process flow, but that meant all incoming mail had to be opened and then sorted by the request type before it could be processed. That’s just pure waste (motion, transportation, or over-processing depending on how exactly it was done). The solution to this un-lean thing was to push the problem to the postal service. No, the postal service didn’t start opening and sorting the mail by the contents. Instead, they assigned each type of correspondence a different PO box, so when you stuffed your request into the pre-labeled envelope the post office did what it does best and automatically sorted it into the right bin.

Sure, the occasional piece was in the wrong place, but by leveraging the post office’s existing capability to examine and sort the mail (which they were going to do anyway) you eliminated the NVA step of having the re-sort it at the destination. A simple change, no more work for anyone involved. That’s leaner!

Making someone else do your work for you, that’s just a way to make them mad.

Just silly

I love cheese.  Mostly soft cheeses like brie, but pretty much anything with character.  So when we venture away from home to my in-laws, we take the opportunity to frequent one of the several cheese shops in town.  Better than buying a delicious cheese, we get to try a vast array of cheeses and then pick out three or four small samples to take home and enjoy with a glass of wine and some crackers.

As I was standing at one of these cheese counters the other day, I noted a gentleman to my right was ordering something from the prepared foods counter.  It wasn’t a cheesemonger that I usually go to, but variety is the spice of life, right?  Anyway, as this person is talking to the woman behind the counter he says “I’ll have some of this, and some of that” and so on.  Then, at last, he says “and a pound of sliced turkey.”

“Oh, I can’t help you with that, ” says the woman. “You’ll have to go over to the deli counter for that.”

“Ok, ” he replies, and takes two steps to his immediate left and turns ninety degrees counterclockwise.

Behind the same continuous counter, the SAME woman pops round the corner of the counter and says “ok, how can I help you?”

WHAT!?!  In the words of the villain in Zoolander “I feel like I’m taking crazy pills!”

Look… if you are capable of serving the person two steps to the left, then you are capable of serving them right where you are standing.  Regardless of what your established process might be, having to restart the transaction because someone isn’t in quite the right place is just silly.  Build processes that meet your customers needs.  This can’t be the first person who has ordered both prepared foods and stuff from a deli counter at the same time.

Not one of the critical few

Ingrained in the Six Sigma school of thought is the critical few – the 80/20 rule. It is an important rule. In practice, there are a handful of things which often allow you to make big leaps from an incapable process to a capable one. There are more subtle characteristics of the process which can be refined to continually improve the performance, but this isn’t step change, it is refinement. And then there’s a class of things that just don’t matter.

Recently, while attempting to facilitate a process design effort, I spent a lot of time thinking about the things that don’t matter. That may have been because that’s all anyone spent their time talking about. And as facilitators, we were enablers of this dragging on. Having been instructed to drive to a single standard process and toolset, we discussed every little one-off thing that people wanted to allow for in the process to see if we could squeeze them out. A day’s worth of 25 people’s time to design a process spent talking about the equivalent of the carpet color.

We wanted perfect compliance to the standard, and that meant a standard which was not necessarily all-inclusive (because some of these one-off requests were truly ridiculous by any standard). This is where I believe we got off track with process work. Process design is about controlling the critical few things which will make the difference in process performance.

But that is not what we were discussing. We were discussing nuances, oddball cases, odd uses of the process, and data elements that some teams wanted and others didn’t. We talked about the 1% and largely ignored the 99%. We talked about things that weren’t going to make the difference, whether they were one way or another.

To begin with, we didn’t know what was going to make the difference. We hadn’t studied the existing processes to understand what made them work – what really mattered and what didn’t. This created unnecessary room for debate because we were unable to bring adequate materials to the table to help the team work through their differences. We had little to no information on what mattered and what didn’t.

Instead of define-measure-analyze-improve-control we just went right into improve. And there we got bogged down discussing every little quirk, because we didn’t know what else we ought to be talking about. Or more importantly, what we shouldn’t be talking about.

Instead of a conversation that was “do we really need that? How many of our teams use that process step?” we could have instead said “sure, it doesn’t matter to me if you allow for that.” And we’d be saying that not because we didn’t care but because we actually knew what did matter. Everything else, the little things that we debated with the teams could have instead been bargaining chips that we could dole out in heaps and have given up basically nothing that really mattered. We could have had a strong position, not because we won all the arguments but because we knew which battles were worth fighting and which were worth conceding.

Had we known what things were not one of the critical few things, we could have appeared very agreeable and allowed the teams as much “leeway” in the process as they claimed they needed. All along we’d be giving up nothing. Nothing that really mattered anyway.

It’s a reminder why a thorough measurement and analysis of a process is important. It isn’t just discovering what the current state is (measurement), but it also understanding why it works (analysis). And from there, narrowing down the bits of process that really do matter, and just letting the rest go. Some things just don’t matter.

It’s a net, people

Ah nets, the greatest safety device possibly ever invented. And also very handy for catching fish. Or is it? In software development, we always talk about nets. Testing is a net to catch all the bugs that developers write. Peer review is a net to catch all the design flaws that analysts create (and possibly a net to catch code bugs as well). But a net it truly is, and nets, by design, have holes in them.

Nets catch big things, like big fish, and let the little ones through. That’s fine if you don’t mind the little fish escaping, but what if instead of being fish the little things getting by are defects? Sure, the really enormous fish, er defect, gets caught, but the little ones, the hundreds of thousands of little ones slip right through.

Nets serve a purpose, but they are imperfect and will always allow some things that are small enough to fit between the spaces to slip through. There are finer nets than others. General purpose nets, like peer review, tend to catch more than special purpose nets like regression testing. After all, peer review (in theory) looks for a broad range of things while regression testing only looks for what it already knows about.

But the purpose of my post is not to talk about the fineness of any net but instead to remind you that no matter how fine your net is, it is still a NET. And you really don’t want nets when it comes to software development, you want walls – barriers that allow NOTHING undesirable by. The barrier that we most often overlook in software development is error proofing the process.

Sure, for new code that’s hard to do, but many systems are configuration driven, and require changes to be made to many parts of the system to enable new functionality. We often need entries in the tables to create the foreign keys, entries in tables to join values together. Multiple rows of configuration working in concert make the right behavior. But what do we do? We write instructions on how to configure the system. Rather than do that, if there’s a limited number of possible results you want to support (say a bunch of client features), then either write the system with a single item of configuration (so you don’t have to worry about updating the right thing in every place) to make it work OR write a tool that makes sure you can configure all those settings with a single click. Error proof. Make it easy to do the right thing.

Walls, not nets, is where the answer lies.

Don’t unecessarily break cultural norms

I’d recently been involved with a post mortem of a project we’d been working on.  One part of that session was to perform plus-deltas. Plus-deltas are essentially a coarse way of getting feedback from the team about what they liked, what they didn’t like, what they want more of, etc.

We were doing plus-deltas by writing up sticky notes and posting them on whiteboards inside key themes. Themes might be “the process”, “the tools we have”, “the people on the team”, and so on. As a little twist, the facilitator chooses 3 color sticky-notes and gives each sticky color a role. There are plusses (things we want to continue to do), deltas (things we want to stop doing or do differently) and he adds a third thing (which he calls “wannas”) which are things that we think we should start doing.

So if you were going to choose a color for each type of sticky-note based on what type of thing was going to be written on the sticky-note, what would you choose?

I’ll wait while you think about it…

[ insert Jeopardy music here ]

… ok. Let me guess, you chose the following:

Good things (plusses) go on green sticky-notes.

Bad things (deltas) go on red sticky-notes.

“Wanna” things go on some neutral color (maybe blue) or yellow.

Was I close? Did you ever consider putting good things on the red sticky-notes or bad things on the green sticky notes? No? Why not?

Because we have cultural norms about these colors. Green in the US means good while red means bad. That’s not true in China and Japan, where red is a good color. I’m not sure how they feel about green, but red isn’t a bad thing. Alas, for some reason this is what the facilitator chose:

Plusses are to be put on yellow sticky-notes.

Deltas are to be put on green sticky-notes.

“Wannas” are to be put on red sticky-notes.

Watching the teams work, you can imagine the confusion. The facilitator had to put up a cheat sheet about what color meant what. When the overhead projector went to sleep and our cheat sheet wasn’t visible, people were lost as to which color to use. Work stopped while people tried to remember which sticky color meant what. It was ridiculous, and completely avoidable.

In designing a process, there are things that you want to change, like the way teams work or even the corporate culture about reporting errors. And then there are things you should never change, like things that are cultural norms that would be extremely hard for people to not do the way they’ve always done. Regardless of how you feel about it, it probably isn’t sound advice to start making everyone walk on the left side of the hallway as a process improvement because it’s just going to screw people up unnecessarily. We have a norm about that that extends beyond the company, so don’t mess with it.

Why you can’t win by offshoring

In one of the early scenes in LA Story, Harris (Steve Martin) sits down to coffee with a group of “friends.” They go around the table ordering, each one having some drink.

Tom: I’ll have a decaf coffee.

Trudi: I’ll have a decaf espresso.

Morris Frost: I’ll have a double decaf cappuccino.

Ted: Give me decaffeinated coffee ice cream.

Harris: I’ll have a half double decaffeinated half-caf, with a twist of lemon.

And then…

Trudi: I’ll have a twist of lemon.

Tom: I’ll have a twist of lemon.

Morris Frost: I’ll have a twist of lemon.

Cynthia: I’ll have a twist of lemon.

For a brief moment, Harris had something that differentiated himself from his peers. But it isn’t long lived. Suddenly everyone has a twist of lemon. And so it is with off shoring.

For a while, getting your labor off shore means your product costs less to produce because you pay less to have it produced. For a short time you can sell your product under what your competition costs. But your competition gets wise to you pretty quickly, and unless you hire all of the labor in India or China or the Philippines, you don’t have something that is a protectable difference between you and your competitors. Anyone can have their twist of lemon.

But process excellence isn’t so easily duplicated.  As an outsider it is hard to see under the covers and understand how you’ve improved your processing, reduced your waste materials, etc.  It’s a secret, that if you get right, you should guard.  Yes, your competition can see that less trash is going into the waste bins, but they don’t necessarily understand why that’s the case.

But who you are off shoring to… well, that’s easy to figure out. Not that I’m suggesting you shouldn’t offshore work. In fact, you probably should if your competition is going to do it. You might as well get the easy savings. But you just can’t stop there. You’re going to still have to figure out how to get more for less out of your process or else the brief difference you once had will be gone in a flash.

Excited about nothing

Recently I’ve been working on measuring organizational efficiency and I was comparing test case execution patterns of a quality assurance team to that of a known sample from a whitepaper I had gotten from IBM. IBM had recognized that there is an S-shaped curve to the cumulative execution of cases. That is, you start off slow, ramp up, and then as you reach the end, the last few cases take a longer time to get done. I don’t know why this is particularly, but I wondered if the same applied in this situation.

And that reminded me of a story about a college professor. Professor Reid was a geology professor at my college, and the way my college curriculum worked, even if you weren’t majoring in the natural sciences you still had to either take a certain number of courses or do a project in the natural sciences. I opted to do a project, though I had no idea what that project was going to be. Fortunately, someone lined me up with Professor Reid.

Professor Reid told me that he had taken a bunch of high school students (on some sort of outreach program) to Shapiro Brook, a generally unremarkable brook which ran down the side of a nearby mountain. At the top of the mountain where the brook sprang from the ground was a quarry.

Now, I’m probably going to get this wrong, so if you are a science buff, I apologize. If you are a science student looking for information on conductivity or pH, this is NOT the place you want to look. You’ve been warned.

Anyway, apparently, the behavior of “normal” brooks is that when the water springs from the ground it has relatively high pH and low conductivity. This is due to there being lots of free H+ ions in the water. As the brook travels over the surface, the free H+ ions are bound by Potassium (K) and Sodium (Na). As a result, this causes the water to become more neutral in pH (pH drops) and more conductive (conductivity rises). As I said, that’s the “normal” behavior.

What Dr. Reid and his students found was the exact opposite. For some reason, pH rose and conductivity dropped. He found this fascinating and wanted me to repeat the experiment, bring back results and finally even put some of that stuff through a Plasma Mass Spectrometer. The Plasma Mass Spectrometer is the kind of equipment that GRAD students wait in line to use, so I was super excited to have the opportunity. Dr. Reid thought, by the way, that the active quarry at the mountaintop was somehow impacting the pH and conductivity of the brook, though he wasn’t sure what the mechanism was exactly.

Anyway, early that fall, I walked up the mountain with a conductivity meter and about 40 little plastic vials which I had properly cleaned with DI Water… blah, blah, blah I won’t bore you with the details of my proper experiment preparations. Every 50 yards or so I took a vial of water and a conductivity reading. When I got back to the bottom of the mountain, I pulled out my map that I had been given. I don’t know why I did this AFTER, but I did. And that’s when I realized I had walked the WRONG brook. Now, I was a college student who was just trying to complete a coursework requirement. I could’ve just used the data I had, forgetting whether the results were honest or not. But, no, I felt guilty doing such a thing, though it crossed my mind, so I went back to the lab, cleaned 40 more vials and trudged back up the mountain this time with my map out in the first place.

Again, I went down the mountain collecting samples every 50 yards or so. Once winter fell, I returned to the same brook to repeat the experiment. We did this to make sure that little feeder streams weren’t influencing the main brook. Of course, this time instead of walking down some of the mountainside, I fell and tore up my hand and wrist pretty good. Determined to not have to go back and make yet another trip, I ripped off some of my shirt, wrapped my hand and wrist (that was probably melodramatic of me), and proceeded to complete my measurements.

When I got back to the lab, I carefully tested the pH of every vial and recorded the data. Then, I brought all my results and readings back to Dr. Reid. I couldn’t really make heads or tails of it, but he could. He literally started bouncing up and down in his chair with excitement. Not in some sort of ridiculous way, but just a little more spring as he talked to me, and his eyes lit up, and a big smile came to his face.

“NOTHING! Shapiro Brook behaves just as it should!” he exclaimed.

I was heartbroken. How was I supposed to write a college paper on nothing? Dr. Reid was undeterred. He proceeded to tell me how great this is, to disprove that there was anything special about Shapiro Brook at all. To in fact find that the world worked exactly as we would expect it to work was, to him, joyful. “You could be a science guy,” he said to me, “have you ever considered switching concentrations?”

And that stuck with me through all these years. When Dr. Reid passed away in the early 2000s, it was this story that first came to mind, and the story that came to mind when I pulled together my data for Quality Assurance.

Sure enough, the QA teams experience the same patterns of progress that IBM had observed. The S-shaped curve wasn’t just some IBM myth. I’m not a QA person, just as I wasn’t a “science guy” back in college, so maybe all QA people know this, but I didn’t. There was excitement discovering that they were just like everyone else, so I sent an email titled “so cool!!!” with the details of my findings to a good friend who I knew would appreciate it. There is satisfaction in finding out that we are not special or different, that despite what people believe, things that the outside world experiences can be applied to us. It gives us hope that what we learn elsewhere is transferrable knowledge.

Simpler can be better

We over complicate.  Almost everything.  We have advanced strategies even when we haven’t been particularly good at the basics.  But I didn’t learn an important lesson about simpler being better from work today.  After all, it’s Sunday and I’m not at work.  But more importantly, I learned simpler is better from playing a video game.

Our friends have a Nintendo Wii.  We also have one, though we don’t own many games for it.  Our daughter never plays the Wii at home.  And furthermore, she’s just under 3 years old.  Her skill with a Wii controller is, from what we can tell, fairly limited.  But when she sees it being played at our friends’ house, she really wants to try it.

And she asks very politely to play.  In this case our friends’ son was playing Wii Playground.  It’s a series of mini-games like dodgeball, tetherball, paper airplanes, and slot cars.  My daughter has no capabilities to do anything advanced with a Wii Remote.  She can wave it about and press a button and hold it.  She has no idea about pressing a button several times, or pressing the B button.  All she can do is press the A button, and wave it about.

So our friends’ son set our daughter up with slot cars.  There are all kinds of cool things you can do with slot cars.  You can press “A” twice to make the car turbo boost, you can move the remote left and right to switch lanes, you can press “B” to activate special powers.  And doing all this, you can hop between lanes, catching speed boosts on the track and blasting in front of your opponents.

Now my little one doesn’t know about winning or losing, she just likes to try.  I’m happy for her to do that.  After all, she’s not even 3.  Anyway, once she had the remote in hand, the race started and she held down the “A” button to make the car go.

Sure enough, the car took off down the track.  Our little one didn’t move the car between lanes, she didn’t use the turbo boost, she didn’t activate any special powers.  She didn’t ram her opponents off the track.  Despite all the capabilities that this game had, she used none of them.  She just put the pedal to the metal (so to speak) by holding onto the “A” button.

She won!  She won 3 races in a row… against computer opponents, who have no idea that it’s a 2 year old playing against them!  Computer opponents don’t take it easy on you.  I’ve played the slot cars game – I have LOST at the game.  I tried the advanced strategies.  I tried to jockey for the best slot to be in, use the speed boosts, knock my opponents off the track.

Simpler was better.  My daughter, doing nothing but holding “A” beat the computer consistently.  We tend to over think, to try and use advanced techniques to get a huge edge.  We don’t need those things!  Sure, my daughter didn’t beat the opponents by a hundred car lengths, or even ten.  She just beat them.

Think simple.  Try basic.  Try boring.  Try consistent, but unexciting.  The results might surprise you.  They sure surprised the heck out of me.