No more RACIs

I’ve decided that I hate RACIs. There’s just too much wrong with them to make them worth doing. A RACI, in case you are unfamiliar (or RASCI sometimes) is a table which lists tasks along one axis, people (or job roles) along another axis and at the intersection marks someone one or more of R,A,S,C,I (responsible, accountable, supporting, consulted, informed).

Now, depending on the school of thought you subscribe to, the S option may or may not exist. A simple RACI might look something like:

	Mommy	Daddy	Daughter
Wake up	R	R, A	R
Get dressed	R, A	R	R
Go to school	A	I	R
Ask about school day	I	R	C
Make dinner (at least in my house)	C	R, A	I
Have dessert	C, A	I	R

One can thus determine what my day is like. In the morning, we are all responsible for waking up, while if someone doesn’t get up on time it’s Daddy’s head who is going to roll. Then, we’re all responsible for getting dressed, but since Daddy has no fashion sense, it’s Mommy who is accountable for this task. I’m simply informed about our daughter going to school since I’m going to work. Technically, though my daughter is too young to drive herself, she’s the one responsible for going to school while Mommy is the one who gets in trouble if my 3 year old doesn’t show up. I’m responsible for asking about her school day, Mommy is simply informed. She overhears my daughter say (who is only 3 but clearly has the kid role figure out) in response to “what’d you do at school today?” almost always replies “nothing.” Obviously, my daughter being the expert on her school day is consulted on this task. One might also choose Supportive I suppose since I can’t complete the task without her. Dinner is strictly a Daddy job with Mommy having some say about what I make for dinner and the little one just eating what is presented. If we consulted her every night would be chicken nuggets, pizza or noodles. And finally for dessert, the little one is responsible for the eating while Daddy is simply informed. Mommy has the go/no-go decision on this one.

Phew. Now that is one heck of a lot of data all from that little table, and this is a joke of a RACI. No real job that I do is so basic as to have just 3 players and 6 tasks to it. You can easily see that many more tasks might be appropriate even in my daily plan – including showers, dishes, bedtime for my daughter, etc. We actually follow a pretty predictable pattern each day – a process you might say – and yet there’s enormous detail that could go into it. The fact of the matter is that any realistic RACI would get unmanageable and quick.

The second issue I have with RACIs is that they’re a punt for figuring out a good process. If you have to go to all this trouble to figure out who does what in the process, isn’t it a reasonable question to ask if you might have a really un-lean process that simply needs fewer actors or individuals who actually have the authority to both be responsible and accountable for the task to get done? The mere fact that R (the responsible person who does the work) can be separated from the A (the accountable person who gets in trouble if the work doesn’t get done) is crazy! The idea that we’d consult all kinds of people suggests that we don’t have enough knowledge (or the wherewithal to gather it) about the job we’re tasked with doing. And informing? Look, if the person isn’t going to act on the data you are provided (ie, give feedback, which makes the consulted not informed) then why are you giving them the information!?!?

Third, nobody gets these things right anyway. Can more than one person be accountable? Responsible? I think not. And yet, they’re always a mishmash of several people being responsible for the same task. Someone has to be running the show and the moment you allow everyone to be accountable then nobody is accountable and the same goes for responsibility. It just becomes a giant circle of finger-pointing when the task doesn’t get done.

Finally, these things are usually more of a suggestion than a reality. Putting that much effort into something that isn’t going to be followed is insane. Even in my own house, with the six silly tasks that I have, if I’m working late then Mommy becomes responsible for all the tasks that I would normally be. Life marches on, regardless of what my RACI says ought to happen.

Don’t do RACIs. Do a nice swimlane process flow and leave it at that.

The consumer is always right

I was sitting through a meeting the other day and we were talking about the new test case management system that we were installing. It’s nothing special, but one of the features it offers is the ability to track defects along with the test cases. The thing is, as a company we already have 3 other defect tracking systems from different vendors, none of which are integrated with our test case management system. True, it is an annoyance and certainly adds some cost to quality assurance to record the defect when you have to go into a different system.

However, the issue I have is that quality assurance designed the workflow and fields that would go into the defect tracking system. Quality assurance is a (sort-of) user of the tool. They have to enter data into it, so making it convenient for them to enter data is a good thing. However, they aren’t the primary consumer of the data – development is. The reason we enter bugs into the defect tracking system is (besides metrics) so that development gets a detailed account of what went wrong so they can fix it. Although we supply defects into the process, it is development that has to consume our input and use it.

So why then would you have QA define the input for the team who needs the data? It is illogical that QA should determine what information and in what format they’ll be giving it to development. Development, who needs adequate input to fix the bug, should be defining what inputs they need. QA could input more data than development needs if they felt they needed some data recorded too, provided it isn’t interfering with what development needs to get their job done.

Now, maybe development requests something that is ridiculous and QA ought to negotiate for a more acceptable request, but generally I believe that it is the consumer who gets to define what they need from their supplier. In our case, we didn’t ask development at all what they needed, we just built something. We didn’t ask development if they’d be willing to use our new defect tracking system.

I think, if it hasn’t been set out as a universal truth somewhere else before, that it ought to be done so now – the consumer defines the required input, not the supplier.

Is it an enhancement or a bug?

Did I write this before? I can’t recall, but it came to mind today at work in a conversation I was having. 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. This isn’t a hard concept to grasp, yet we seem to struggle with it all the time.

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.

Uneventful change

As I was sitting here doing nothing, or effectively nothing (I was playing mini-games on my computer), for some reason a bunch of failed change events came into my head. As my prior post would indicate, I fail to make change a lot of the time, though not for a lack of trying.

To be fair, if I make a change and it isn’t better, then I hardly count it as making a change. Sure, something is different but not in a way that is meaningful to our customer.

Anyway, I digress. I was thinking about change events and why they always seem to be such a big event. It brought to mind a story about trying to build a new requirements process. Years ago, I worked for a team who was doing a process redesign for their requirements process. It was going to be this big multi-day event where we brought everyone offsite to hash out a new way to do requirements.

Never mind the fact that I believe this type of work really needs to be done scientifically as opposed to just throwing people into a room and saying “design something.” Anyway, I was tasked to go off and get a resource from this one team to attend. I approached the vice president of the team and said something along the lines of “I’d like to have a representative from your team attend this 3 day offsite to redesign the requirements process.”

“No,” he replied. I sat there and stared at him. I really didn’t know what to say. It wasn’t an angry stare on my part, it was more like a mouth agape bewildered stare. Kind of like the way my dog cocks his head to the side when something makes a funny noise. I’m pretty sure that’s what I looked like. Fortunately, he went on.

“We already redesigned this process once with Bob [a
coworker of mine]. Why should I send resources to do it again?”

Fair enough. It was true; Bob had tried to do this process redesign before. It had failed not because they were unable to come to an agreement over the change but because the team who was supposed to adopt the change refused. Foolishly, Bob had neglected a major stakeholder in the process. But, darn it all, we weren’t going to make that mistake again.

And yet we did. The mistake wasn’t trying to get all the people in the room, or doing it via an offsite, or doing it without understanding the existing process fully. The mistake was making change an event. An event is easy to resist. And event has a clear beginning and thus a clear line in the sand you can take a stand against.

What if change just snuck up on you? It happens all the time in our regular lives and we handle them in stride pretty well. Tools like twitter, Facebook, even the internet and email just creep into our lives without making a big scene. It’s hard to resist something that shows up quietly, that doesn’t really come knocking or announcing itself. It just shows up because it is better and more useful. Now that we have these things, we can’t imagine life without them.

Why can’t we approach process change this way? What if instead of a big-bang event to redesign the requirements process we just made some small quiet change to the way we did things? What if we just started inviting teams to JAR sessions. No training, no announcements that this was the new way to do things. Just invite them on some projects and see how they feel about it. If they like it, maybe we do it on some more projects. Eventually we’re doing it all the time and it becomes an accepted way of doing things.

There’s no real need, except potentially for speed purposes, to announce a process change. And given the enormous resistance that can be placed against an event, perhaps it is just better to sneak a little change for the better here or there. Do it often and eventually the process will be changed for the better, and significantly so.

Perhaps a better title for this posting would be “eventless change,” but the idea is the same. Change doesn’t have to be eventful for it to be impactful.

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.

Beware the anecdote

“This one company used our software and they realized a $10 million savings in one year!”

Good for them. Frankly, I don’t (and you shouldn’t) care. The anecdote may be the most disastrous (from the consumer’s perspective, not the sellers) marketing device ever employed – short of outright lying I suppose. The anecdote takes a great story and uses it as the basis for why you should take your hard earned money and buy product X, or Y or Z.

Anecdotes abound. We are a culture of story tellers. The media exploits it all the time. The government exploits it all the time. Just think about the current health care debate. On one side you have the story of the Canadian woman who would have died had she relied on Canada’s healthcare. On the other side, you have a very happy Canadian health care recipient. How can it be that two totally different anecdotes are coming out of the very same system?

It’s a logical fault that we make. We assume that the related experience is the representative experience, which it clearly isn’t. Well, at least not all the time. Consider the “bad” Canadian health care experience. Let’s assume, first of all, that she really would have died if she hadn’t come to the US. We don’t actually know that because we can’t explore alternate realities. She believes she would have died, so let’s take it at face value. Has anyone in the US health care system ever died due to a bad diagnosis? If you answered “no”, I’d like to have some of whatever drug you are on, because that stuff is creating the kind of delusions not seen since the Emperor went out without his clothes on.

Of course there have been bad US experiences! People die here too! But the anecdote is powerful. It’s scary that someone might slip through the cracks. And statistics are oh so dreadfully boring! If Wikipedia is to be believed, the US pays twice as much and yet lags other wealthy nations in life expectancy and infant mortality rates. That doesn’t mean people don’t die in these other countries of horrific, potentially preventable deaths in these other countries – they do. But the odds are better. And even with improved odds of you surviving infancy and living longer, there are scary stories to tell.

People relate an anecdote when it supports their view of the world, whatever that may be. However, they’re doing that because the general patterns of the product, process or service aren’t necessarily an experience which causes you to take action.

I mean, would you be all that excited if I said “if the US adopted a health care system like Canada’s it’d probably be about the same care as you get today, but maybe a little cheaper.” Wow! I mean, wow! If that isn’t a call to action, I don’t know what is!?! People are selling things all the time – whether it is software, a change in the healthcare system, or NOT changing the health care system. If you take that anecdote and relate it to another person, who passes it along to another, and so on then it has served its powerful but potentially destructive purpose. Nobody can remember the statistics, but we all remember a good story.

The next time someone tells you a story about why you should take action, instead of listening intently, ask for the data. Then go verify the data. But most of all, beware the anecdote!

Hold me, I’m scared!

Fear is a terrible thing. And while some fears are justified, they are mostly overblown. Putting your fears into perspective is difficult. My first job out of college was a contact job working on the software for a blood banking system (I’m sure I’ve written about it before). Knowing you could kill someone if you screwed up the code… that’s fear! I can see how that might paralyze you from changing the code. On the other hand, if you knew something was wrong with the project, it is the same fear that would drive you to action.

In my case, the company was developing a new test for some sort of antibody screening. As I understand it, there are several types of blood products you can give the machine that it recognizes – centrifuged whole blood, plasma, or serum. For all intents and purposes, plasma and serum are interchangeable in the types of blood tests that the system could perform. However, this new test being developed for the system only worked with plasma (or serum, I can’t remember which, but it doesn’t matter except that it only worked with one of the two blood products). However, since in the entire history of tests they were interchangeable we listed the available option as “plasma OR serum.” Now, the people using the machine were supposed to know that they should only use the right product, but the machine didn’t have any warning about it.

While I knew there was something wrong with our system, I feared telling them that they needed to delay the release of their new test was going to raise their anger. Who was I to tell them? I’m not a scientist, I’m a programmer. But I swallowed deeply and expressed my concern. Their reaction was miraculous! They listened! They stopped, looked at me, thought about it for a minute, and said “you’re right. What can we do about this?” Then they invited me (a just out-of-college programmer) to meet with their scientists and discuss a solution! The collective desire to produce the best product outweighed the fear of management’s ire that we were delaying the product while we solved this problem.

So it was with some disappointment that just this other day I encountered fear at the office again. In the business I work in, no matter what we do wrong, nobody will ever die. The risks are not nearly as great, but it is still a business and there must still be a drive to do what is best – and to be ready to hear it if we are not doing the best we can.

We were in the process of reviewing a random sample of defects which we had gone back and looked for root cause. The data was pretty detailed – people seem to remember their bugs very vividly for some reason, especially high severity bugs that cause us to back out of pilots. We took all this data and we grouped it up and looked for patterns of mistakes where we could improve the process. Lo and behold, one big thing that came out was basic coding errors – the kind that could be caught by a static analysis tool like JTest. Stupid stuff. So I said to the manager we were working with “we need to go back to development and tell them they’ve got some basic coding issues.”

At first his reaction was “isn’t that kind of cliché?” I said “why? If they have basic coding issues, they’re really there and easy to work on.”

“Isn’t it quality assurance’s fault too?” the manager said.

“When’s the last time that QA ever injected a defect into the code?” I replied. “This is a development problem and it needs to be solved by development.”

“We can’t go back to development and tell them they have sloppy programmers! They have some good programmers too!” he retorted.

Alas, fear won out over doing the right thing here. The manager I was working with feared that we couldn’t go back to development and tell them they had a basic problem. It was ok if we went to them and said “you’ve got requirements issues” or “you’ve got a knowledge gap” but for some reason, if the blame fell directly on their shoulders they were unwilling to hear “you’ve got a coding problem.” We’ll never know if they would be willing to hear it, because apparently we won’t be telling them the truth of the matter on that one. We’re afraid they might react badly.

Fear of doing the right thing: 1, Us: 0.

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.

So as I sat today through a long, long meeting trying to define a process, 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.