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.

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 the end of an otherwise successful (a bit of a rarity) meeting the other day, I was talking with the leaders of a couple parts of the quality assurance organization. They 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.”

Hello? 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.

On the goal of being lean…

It is to some degree a strange coincidence of events that I am writing this post:

1. I was reading EvolvingExcellence blog post regarding the author, Bill Waddell, who has committed to stop complaining and actually do something about the loss of manufacturing in the USA.  As his first salvo, Bill writes a well thought out article about the fallacies being spread by the BLS and both sides of the aisle in congress.
2. I recently read “What Happy People Know” by Dan Baker.

It’s times like these that solidify my position as Democrat more than a Republican.  Coincident events like above that make me understand why I don’t agree with the capitalist position. 

Bill’s post focuses on the loss of manufacturing jobs in the United States as being a warning sign to the US failing.  He argues against the use of cheap labor elsewhere as being valid globalization, noting ridiculously low productivity and the oppression of foreign people as not good ways to build wealth.  He believes that wealth building manufacturing jobs in the US are being lost in exchange for a false value.  And he argues that sending more people to college to become more skilled isn’t going to fix it.

On most of these accounts I agree with Bill, except one.  “Wealth building.”  I’m not saying that manufacturing jobs aren’t wealth building.  I’m not qualified.  I’m arguing that the goal of building wealth is incorrect, regardless of how it is built.

See, I told you I was going to disagree with capitalism.  But why, you ask?  Because of the book “What Happy People Know.”  Dr. Baker’s book is very well written, and I’d recommend reading it (I get no kickback for saying so), but it is simple to summarize.  Money DOES NOT equal happiness.  It isn’t a Dr. Baker idea.  It’s a saying that’s been around forever.  It’s true.  It’s been studied.  Rich people are not, on the whole, happier than the less fortunate.  Having more stuff doesn’t take your worries away, it adds to it.

There are even joking retorts such as “money may not buy happiness, but give me the opportunity to prove them wrong.” or something like that.

It takes some introspection, but consider your life for an hour or two.  I’d say a minute, but let’s be honest.  Go for a walk, think about what truly makes you happy or what would make you happy.  Most people will tell you that they’d be happy if they made twice what they make now.  And yet, when people achieve that, they’re still not happy, and again believe that twice what they are now making is the magic number.

I have a good job, I make a decent living.  I can afford our house, our cars, food and health insurance.  And yet, if I made twice what I made today, how different would my life be?  I’d have a bigger house and take up more space.  I’d eat more expensive food.  I’d still be able to afford everything, and yet it really isn’t a different thing.  It’d just be more of the same.  The thing is, even if I had billions of dollars, though I could buy pretty much anything I wanted, I still only physically occupy so much space.  I still only need so much to eat.  What would I be getting for all that money?  I sleep well at night, my health is good, I love my family.  More money isn’t going to change the basic factors that make me happy.

Wealth building as a goal is misguided in my mind.  Being LEAN has a very important value aside from making people rich (and creating disparity).  Being LEAN means being able to provide everything I need to survive PLUS something that can improve the value of society as a whole.  If I can become twice as efficient and make 2 chairs in the time it took me to make one, then I can have a seat and so can someone else.  If I can figure out how to eat less food, or use less resources to get something done, then it is freed up for someone else to improve their lives with.

Being leaner doesn’t mean doing it to improve my standing.  No matter how much money I earn, I will never grow to be taller than trees, bigger than mountains or able to spontaneously fly.  My change in stature from being richer is quite insignificant in the big picture.  Being happy, however, has immense value to me.  And, freeing up the resources that I once consumed means being able to provide them to the less fortunate.  While giving my money (or resources) away, won’t make a rich person happier, it does have value to those living in poverty.  Some amount of wealth building helps those less fortunate meet basic needs.  And being lean means helping bring up the standard of life for all to a level that more people can be happy.

Happier people, not wealthier people, is the goal I want to accomplish.  Vibrant health, a comfortable place to live, enough (not an excess) to eat, and the freedom to enjoy a beautiful day is what LEAN could accomplish.

While I appreciate where Bill is coming from, if the USA weren’t the world leader, the world still wouldn’t end.  If I can continue to be happy, I’m pretty sure that’s what matters, not how much the US dominates the world’s wealth.  After all, you can’t take it with you…

Thoroughly considered or just the way it is?

I can never tell if my educational trips actually change mindsets of the people I bring along with me.  Sometimes I think that although people intuitively get the ideas being presented that it never affects behavior.  It’s like emotional intelligence (EQ).  Sure, you can know what the right answer is, but will you actually behave that way when push comes to shove? 

At any rate, though I wonder about the value I’m providing to people I often learn interesting things about my students.  In some ways, the teacher becoming the student is my favorite part of teaching.  Accepting that I know nothing (or at least very little) is what inspires this blog.  If I thought I knew all the answers, I wouldn’t be mulling them over in my head and writing my ruminations in this blog.

So I return to the scene of a recent trip to 5 Guys Burgers to discuss a student who came along.  This student, is an interesting sort of person.  I find that in some cases he’s really thoughtful and in others he doesn’t want to make the leap from “hey, if it works in a burger joint, could it work in a big company?”  It’s the power to extend a learning to a bigger thing, and I don’t think the inability is unique to him.

The interaction went something like this:

“Bob, see what they’re doing with the fries?  First they take a Styrofoam cup and load it with fries and then they put that in the bag and throw MORE fries on top.  What a waste.  Why do they need the cup?  Or why isn’t the cup the right size?”

And Bob’s response was “well, it’s part of their value proposition.  You get a lot of fries for your money.” 

Now, I’ll grant you that there were a lot of fries in the bottom of my bag, but I’m not sure that’s the issue.  The question in my mind is, did they get this way (of throwing excess fries into the bag) because they thoroughly thought it out or did it get that way by chance.  In effect, they bought cups that were too small and always intended to provide a larger order of fries than the cups could hold.  If they had bigger cups they’d just use them without the tossing of fries in on top.

It reminds me of a commonly told story about a woman who is preparing a roast for her family.  She takes the roast out, cuts off the end of it and discards it.  Her son, who is watching her, asks “mom, why do you cut the end of the roast?”

“Well, that’s what my mother did.”

“Why did your mom do it, ” asks the boy.

“Because that’s what her mother did.”  But it turns out that the only reason the boy’s great-grandmother did that was because her pan was too small to fit the roast.  The rest of tradition handed down is nonsense.  It doesn’t make the food taste better.  It wastes a part of the roast which could be eaten.  It’s not  a deliberately thought out thing, it’s just a thing she does.

And so it goes with french fries.  We find reasons in the things we see every day to believe we’re doing them for a valid reason.  And that we must continue doing those things hereafter because clearly they were well thought out.

It’s a form of superstition.  Just like wearing your team jersey on game day because you believe your team can’t win without it, continuing to do something without questioning why we do it at all is foolish. 

But it is also troubling.  LEAN thinking is a mindset to challenge the way things are done, and yet we find that it is our evolutionary misfortune to see cause where there is none.  To be leaner, you are going to have to fight against your urges.  While superstition may have saved us from being eaten by lions, it no longer serves the same purpose.  We have the luxury to be able to step back, think about the issue and make intelligent change.

The next time you look at something that needs fixing, you should be able to ask yourself “is this a thoroughly considered way of doing things, or just the way it evolved?”

You know it isn’t training if…

Two days ago, while I sat through the first horrid day of “training” I came up with a bunch of thoughts about LEAN that will eventually turn into entries.  I also thought about something else, which was how terrible the training class I was sitting in was.

Not that this is a new idea, but it’s an important example of “Know Your Audience.”  Whenever presenting any material, there must be some consideration made to who you are talking to.  A deeply technical presentation to non-technical folks won’t work.  A high-level gloss over to deeply technical people probably won’t work either.  And last but not least, a rehash of what your audience already knows, whether it is at the right depth or not, won’t work!

So why in god’s name, would this team of 3 people invite 50+ black belts and master black belts into a room and try and talk to them about single piece flow, TAKT time, value stream maps and the 5s’ like we’d never seen them before?  Every person in that room had gotten almost 5 months, maybe more, of training on all this stuff.  Why did they walk us through a 2 hour process simulation that we’ve all already seen?  OK, if they had walked us through the simulation so we could see their proposal on teaching these ideas that’d be one thing, but having us sit through the simulation like we have no clue was insane!

In my mind, training means learning something new.  It isn’t training if the audience already knows the material.  It’s insulting to our intelligence.  It’s certainly a waste of time.

If you are going to “train” someone, you must:

1. Offer new information.  Now, if one attendee already knows the material, that’s not your fault, but the majority of your audience should be getting something new.
2. Offer it at the right level of detail.

If you’re not doing at least that, don’t invite me.  I wouldn’t mind a well put together training, but I’d settle for the two criteria above.

Agile not acting LEAN

This is a continuation of my manifesto against big-A Agile software development.  It stems from a training class I was in today regarding LEAN. 

First off, LEAN… Six Sigma, they’re not that different from each other.  Philosophies for continuous process improvement.  LEAN has a bent towards removing NVA work while Six Sigma has a bent towards quality.  But Six Sigma, at least the Six Sigma I was taught, is capable of addressing both problems of product quality and problems of product performance.  Again, it’s not that I’m saying one is better than the other, they’re similar.

Anyway, I digress.  While I see LEAN and Six Sigma as two sides of the same coin, a lot of people in the class were comparing LEAN and Agile software development in the same manner.

I do take exception with this comparison.  In fact, many of the things that some variant of Agile software development proposes are decidely un-lean.  I figured I’d run down a few I thought of while sitting through that dreadful training.  I guess I owe them a thanks because the training effectively freed up 8 hours for me to think about things and may inspire the next few posts.

1. Teams choose process.  This is a people-empowerment thing.  Potentially there’s nothing wrong with it from a LEAN perspective if you have just one team.  Otherwise, it’s counter to standardizing so that you have a basis from which to improve.  You can’t just change the process each iteration because the team would feel better about it.  If the deviation isn’t better, don’t do it, and if it is better, then every other team must also do it until something better yet is found.  But I don’t get the impression that Agile’s “teams choose the process” attitude came from what would be the most lean thing to do, but instead from what would make the team happiest.  Those two things might have the same end result, but you can’t be sure.
2. Fail Fast.  Decidedly better than “fail slow” which is the argument against Waterfall.  But let’s be honest.  Failing is bad!  Failing results in defects which is which of the 7 wastes people?  Rework.  If you know of a low cost way to avoid failing, say peer review, then do that instead.
3. Refactoring.  Um, duh, this is decidedly rework.  Agile considers this an entirely valid way to design and develop software.  Again, it’s better than band-aids when your design doesn’t pan out, but if a little forethought would have avoided refactoring later, then rework is avoided.
4. Daily Scrum.  Waiting, Over-processing, Motion.  Yuk.  If you have an issue, don’t wait 24 hours to deal with it.  Daily Scrums are too infrequent of a way to raise and solve a blockage.  Projects miss deadlines by losing one day at a time.  Over-processing.  It’s clearly NVA.  Meetings DO NOT tranform the product towards the customer specification.  Especially meetings where you say what you did yesterday, what you are doing today, and the possibly one useful piece of information – what’s blocking you.  And Motion… unless you’re having the meeting where you sit, you are wasting processing time by having everyone gather in some location.
5. Pair Programming.  Duplication of effort, thus overprocessing.  If one person can do it, why would you have two people do it?  I know, there’s some claim that pair programming is a form of inspection on the fly so in some way it might be aligned to fail fast, but again, the assumption that failure is going to happen is a problem in my mind.  Code is a very terse language and doesn’t do a great job at expressing ideas, which is why a lean natural-language specification would, in my mind, be better to write and be reviewed.  The cost of changes on paper is cheaper than the cost of changes in code.  Restructuring poor logic flow - painful.  Restructuring a little logic on paper - easy.
6. Test Driven Development.  Rework, but I already covered that in “We’ve Decided to do it the Wasteful Way.”
7. A Product backlog.  Inventory!  Sorry people, but this is unserved customer demand.  It’s inventory of requests that are not being processed.
8. Iterations.  Waiting.  This is a conversion from single-piece flow to batch flow.  One story in your backlog is waiting for a bunch of other stories so that they can be packaged into a release.  How do we get from here to a constant flow of new features making it to production when they are ready to go?

Look, I know what you’re thinking… “bugs are inevitable so we might as well accept that and figure out how to deal with it.”  I, for one, am unwilling to accept that we should allow failures.  Yes, they happen in my world, but we look for ways to pokayoke the development process so people don’t keep making the same mistakes.  So that people don’t have to appraise the system looking for the same stupid error that people always make.  Patterns of behaviors can be changed at the source.

A simple example.  Most IDEs today, when you start typing a built-in function, and sometimes even one of your own defined functions, immediately provide you with the arguments necessary for that function.  Other IDEs, such as Microsoft’s VBA, check syntax validity as you type each line and warn you right then and there.  Other’s automatically beautify.  When I started programming, they didn’t do diddly.  They weren’t any better than a notepad.

This is errorproofing.  This is dealing with the kinds of things that people do every day that are just dumb, avoidable errors that nobody should wait until a compiler has to run to find out.  And if they can think of these things, then I imagine I can think of enhancements which would errorproof other kinds of errors in the development process.

Will we ever get away from appraisal and rework totally?  I don’t foresee that day anytime soon, but we can be further down the line if we wanted to.  So, yes, while many of the things that big-A Agile has done are leaner than the strictest waterfall, they are still an acceptance, nay, an endorsement, of not lean behaviors.  I object.

Why bother iterating if you don’t have to?

Iterative development make sense because it allows you to deploy functionality more often.  It’s that deployment which represents a switch from a continuous stream of work to a batch process.  Once you deploy the new software, gets downloaded en masse.  For that reason, it makes sense to iterate.  Yes, you get more downloads or updates to your software but it also delivers small chunks of functionality quickly.

But should you always iterate?  This isn’t a post in favor of large batch-style development.  This is actually a post in favor of not iterating at all.  One of the things we are working on is a series of improvements to our Quality Assurance process.  There are several teams and each team is responsible for a set of features within an iteration.

For some insane reason, the manager of the project wants to treat this improvement work like an Agile project.  Not only do they have iterations and sprints but they have iteration planning and releases!  This is dumb.  Any remotely frequent reader knows how I feel about the hippie aspects of Agile anyway.  The reason iterative development is better than batch development is that it allows you to deliver small amounts of functionality quickly but feeds nicely into a distribution/update model which are almost always done in batches.

When we upgrade the software of our customers, we don’t want to serve it like McDonalds where each person gets their order in turn.  We want to blast it out there.  With software we can launch it like tossing a million burgers at the crowd all at once.  That’s certainly true for anything we deploy internally, since you don’t want one customer service rep to have the old software while another has the new software.  Installation is always big-bang.

But process work doesn’t have to be that way.  It doesn’t even make sense to do it that way.  Each process improvement, assuming no dependencies, can be rolled out when it is ready.  Creating iterations and releases artificially adds waiting to the process.  If it is ready to go, then just go.

And I’m sure this applies to any centralized system as well.  Why have monthly installs?  If something is ready, roll it.  Why batch it up to install it at the end of the month?  Those features could be waiting 30 days to get out there.  And don’t tell me that ITIL or ISO demands it.  It’s just plain not LEAN to convert from single piece flow to batch processing when you don’t have to.

It’s true for software development and it’s true for process work.  When it is ready, go!

You’re a 5 out of 10

No, sorry, it isn’t a comment on your physical attractiveness.  It’s actually a comment about an assessment that was recently done at my company.  It was a “LEAN assessment” and apparently it was conducted as follows:

1.  Select about 100 people to talk to.
2. Interview them using a series of questions that have open-ended answers.
3. Review the interview with a couple of your peers and decide how their answers rate compared to benchmark answers.
4. Reduce their detailed resposne into a 1 to 5 score.
5. Average all the scores and spit out a number.
6. Call this your LEAN maturity rating.

Where to begin?  Well, we can start with the methodology.  I have nothing against interviewing.  I have nothing against talking to a lot of people.  I do have an issue with an arbitrary translation of a free form answer into a score.

It’s a relatively unscientific process.  It is being conducted by an individual who may have biases.  In fact, we can be certain they have biases.  After all, if our organization was a 5 (on a scale of 1-5) already, then what job would the interviewer have?  They’re somewhat inclined to downplay any positive aspects.  After all, they want to improve our scores on a LEAN assessment.

Two, where’d the benchmark answers come from?  How do you know if the answer your interviewee gave is equal to, better or worse than the benchmark.  How come you didn’t just ask the interviewee for a rating of 1-5 on the various aspects?  I don’t fault anyone for wanting to get additional information for the score, but interpreting someone’s language to arrive at a score?  I don’t think I’d do that.

And finally, even if you can arrive at a score, who cares?  You’re a 6, he’s a 4, that guy is a 9.  Scores, regardless of how high or how low they are don’t make our customers happy or sad.  A good score, in theory, has some relation to something that our customer cares about.  So where’s that data?

Well, I asked for all the data that the team used to “score” the group and they didn’t have it.  Look, I don’t care if you score a one bajillion out of 10 on the rating system.  If the rating system doesn’t relate to an actual goal, who cares!?!?  Score me any way you like, because unless it holds some predictive value, it doesn’t matter.

• The questions may be irrelevant.  Even if you answer the question correctly there’s no evidence that it results in greater profits, customer satisfaction etc.
• The questions may be relevant but don’t represent real behaviors.  This is the oft stated problem with tests of emotional intelligence.  You might know what the right answer is, but you don’t necessarily behave that way in real life.

So instead of this nonsense of scoring people’s answers, how about you go to the gemba, watch people work, and draw your own conclusion about where we stand on the LEAN maturity scale you made up.  I’d like to offer, in return, a grade on this assessment – 0 of 10.  Inherently flawed.

More information required

How long does it take to fix a defect?  No, this isn’t a “how many software developers take the screw in a light bulb” joke. 

Let’s say it’s about a month and a half from the time it is reported until closure.  That’s not so bad, right?  Anyway, a coworker was tasked with analyzing that very thing.  When Robert (just using Bob’s formal name for a change) was given the assignment he went right to work collecting data about the open and close times for defect tracking requests.

We actually keep quite a bit of data on defect resolution because we have decent work-flow management.  We can see the entire history of each request as it makes its way from submission to closure.  We can even tell how many times a request is sent back to the originator for more information.

So, Robert put together a deck he called ‘A day in the life of a bug.’  Catchy name, no?  I hate catchy names.  I view good analysis as serious business and thus deserving of a title which is serious.   When did solid analysis require a fun name?  Oh, I remember, when the analysis is inadequate.

Let’s disassemble it!

Page 1 of ‘a day in the life of a bug’:  The average duration of a request is 62 days.  Average?  Average!?!?  Not that I’m opposed to an average when it’s the appropriate measure of central tendency but this is time data we’re talking about.  Things that take time tend to be non-normal.  The reason is that you are bound on the left by zero (you can’t have things take a negative amount of time) but something can in theory go on forever.

It’s an easy test, we simply take the data and run an Anderson Darling Normality test on it.  Or, if you want to do it more graphically, we toss the data into a histogram or box plot and take a peek at it.  Well what do you know, it’s NOT normally distributed.

So, we take the median instead.  That’s about 45 days.  Wow, we’re already17 days faster than Robert claims we are.  ooops…

Page 2:  Robert provides an analysis of defect resolution by number of times a ticket is sent back to the requester for more information.  In a simple little table we get the number of times a request was sent back and the average duration of that population.  Zero times – 62 days.  One time, 65 days.  Two times, 80 days.  Three or more times, 96 days. 

Oh lord, it’s the average again… OK, the medians are:  Zero times – 42 days, One time – 45 days, Two times, 70 days, Three or more times 80 days.  Hmm, zero time or one time seems kind of close to me.  Perhaps a hypothesis test is in order.

We have non normal, but fortunately homoscedastic data.  A Kruskall-Wallis test between the two samples shows indeed that there’s no statistically significant difference between having the request never returned and having it returned once.  Beyond that, we do see statistically significant evidence that 2, 3 or more times does affect how long from request to resolution.  By the way, we call these returns to the requester “more info required”

But there’s another flaw.  See, Robert is making a case for having more controls up front for entry of the data into the system.  In theory, if the requester put in better information we’d never have to send it back for “more info required.”  It’s probably true, but on the other hand, probably not necessary.  See, logically, tickets which are sent back for “more info required” don’t take longer for a developer to resolve in terms of touch time.  The request is open longer because when it is sent back to the requester for more information they are simply lazy about getting the request updated and back into the system.

Now sure, it might improve the TAKT time for defect resolution, but it doesn’t do anything at all for the actual leanness of the resolution process.  Basically all that extra time is waiting for the request to come back around.  In the meantime the developer just works on something else.  There’s lots of issues to resolve.

So it’s fortunate that Robert produced such an analysis since it gives me something to write about and a few lessons (not that I haven’t given these before).  One: select the right measure of central tendency.  Two: check to see if there’s a statistically significant difference in the samples you are comparing.

As for Robert, we can most certainly say one thing about his analysis — “More Info Required.”  Much more info indeed.