The N Dysfunctions of a Team

A friend of mine passed along “5 Dysfunctions of a Team”, which I haven’t yet opened. In fact, before I opened it, I treated it much like a book that I was considering buying. I went to Amazon.com and I read the reviews to see if it was even worth me opening the book in the first place.

At a glance from the reviews, the book seemed very much like the school of management which believes teamwork will solve everything. It’s the same school of management which believes that hanging ‘Successories’ (you know exactly what I’m talking about if you’ve ever seen one) on office walls. So, I’m pretty skeptical about the book.

But it did get me to thinking. We (that’s the Royal we) believe that having great processes and not so great people is the secret to success. We have accepted that people are fallible and therefore that there must be an alternative solution which addresses the issue. We believe that solution is process.

But as I sat there and thought about it, I realized that making better processes to compensate for not-so-great people is avoiding the root cause of the issue. If you could just get really good people, who really cared about what they were doing, then they’d be great all on their own. They wouldn’t need great processes. Processes, in some respect, are an avoidance of the true root cause – people who don’t do the right thing.

And so I wonder, is learning to select, educate/train/mentor/whatever, and retain the right people the only secret there really is. If you could do that, why would you bother doing anything with process? Sure, if you can’t do the above, then maybe process is the second best solution.

Or is this a case of testing with software? Sure, we all know that it isn’t value added, but we know of no way to avoid it. Maybe that’s the case with process; that we do it because we know of no other way to successfully get the right people in the right jobs doing the right thing all the time. We can’t solve the first problem, so we solve the second one. It’s easier, presumably, to find one bright process designer than it is to find a large (or even a small) team of really good people.

It doesn’t change the fact that, in theory anyway, that good process is in itself a treatment of the symptom and not the root cause.

Cyclomatic complexi-what?

It’s been a while since I’ve had the opportunity for a good rant.  Today provided it.

Not that long ago I wrote about the new measurement system QA was proposing - defects per test case – as a proxy for code quality.  Anyway, as part of that effort I had to then go out to all the middle managers and explain our approach and how we arrived at that conclusion.

I’m delighted to be asked to give a talk about statistical analysis whenever I can.  And it’s always a fun challenge when someone else enters the room who believes they’ve got similar or better ability.  I genuinely like having my stats knowledge tested.  But there’s another type who comes to meetings who I don’t like.  People who don’t bother to challenge the analysis but just dismiss the idea as wrong.  Take for example today.

“I have some concerns about using defects to measure quality.”

You what!?!?  That’s like saying, at least in my mind, I have some issues using rulers to measure length.  The best minds in the IT field recognize that defects, typically in the form of defect containment is one measure you cannot live without.  He goes on…

“Quality doesn’t necessarily mean defects.  It could mean cyclomatic complexity or what value the business derives from the functionality.  If we don’t build it well and it is unusable then it isn’t high quality.”

I can feel my face turning red as he pontificates on the subject.  It’s good I maintain my cool.  For one, what the heck is “cyclomatic complexity.”  I can ascertain from the context that it is some measure of the code complexity.  What to even say.  I think two words sum it up.  WHO CARES!  I know, I know, how dare I say that.  Everyone knows that having maintainable code is good for the customer down the road when they request changes.

Let’s be honest.  Option one is the Agile approach where you build only what you need and no more.  If you end up having to add a feature that breaks the design you “refactor.”  If you are doing waterfall, you try and anticipate some future need to reduce the risk of having to redesign, but eventually, your model will be broken and you’ll have to refactor or band-aid it forever.  You’re not going to get away without rewriting parts of the system.  Ever.  The complexity of your system will rise and fall over time.

Anyway, more importantly, and here’s the secret.  In the immediate need, YOUR CUSTOMER DOESN’T CARE ABOUT CYCLOMATIC COMPLEXITY!!!  You can write the crummiest spaghetti code that has ever been authored and if it meets your customer’s need, and they don’t modify it, they’ll never know.  They’ll never care.  Having high cyclomatic complexity might (and I stress MIGHT) be a leading indicator of future cost, but I can’t think of a single customer I ever encountered who said “I won’t be happy unless this product has low cyclomatic complexity.”  Don’t confuse your idea of what quality means with what your customer says.

On the other front, business value is a ridiculous way to look at the quality of what you deliver.  Now don’t get me wrong, you must be unswervingly focused on what your customer wants.  That said, as an organization we have people whose job it is up front to analyze the market need, determine the potential value, gather cost information to assure an adequate CBA and finally specify the product that will solve that need. 

I know you are going to be morally offended, but once it hits systems, you pretty much should be thinking of yourself as an order taker.  Yes, an order taker who can make some suggestions, but essentially an order taker.  You have no control over the value side of the equation.  You didn’t specify the product needed.  The business did.  If the business had some ill-conceived idea of how the solution ought to work that the customers won’t find valuable, it isn’t the responsibility of systems to second guess it.  The entire process of building something isn’t a forum for intellectual discourse.  Eventually someone has to do something and build it!  Creating waiting or rework by debating the request is not lean and if nothing else it’s presumptuous that systems understands the needs of the business better than the business.

Could you imagine on the floor of the Toyota plant some guy down there saying “you know, if we built go-carts instead of cars, I think people would be happier.”  And then proceeded to build a go-cart instead of a Camry?  I sure as heck wouldn’t be excited when they tried to deliver THAT product to me!  There’s always room for innovation on the factory floor, but it’s about ways to better and faster put together the car, not making the car more “usable.”

So sure, ultimately a quality product is something that people want to use.  That’s the “do the right thing” part of the equation.  That’s the strategy of selecting the right product to build.  In terms of the factory floor – analysis, design, code and test – it’s all about tactics “doing the thing right.”

Which brings us back around to our customer, who specifically said (yes, we were smart enough TO GO ASK OUR CUSTOMER!) that defects was their key measurement of the quality of the product.  Funny that cyclomatic complexity didn’t come up…

The problem with not being obsessive about mistakes

I didn’t think my family would ever become a case study for how not to be process oriented.  But everyday life provides examples that translate well into stories about how not to run a process.  This morning I was feeling like I was on candid camera.  Honestly, nothing could go wrong at the same time as it has for me in the last three days.

On Tuesday it was finally cold enough for us to want to turn our heat on.  As you may or may not have read in a prior post we own a very old home, so a good week of chilly weather will make our house less than comfortable – 64 degrees inside, in this case.  Alas, there was no heat!!!  I called the company who had installed a new Tekmar Thermal Temperature Reset on my furnace.  On a side note, this is a cool device.  Basically, a forced hot water furnace is dumb to the temperature outside, so in the middle of the summer it will heat itself in preparation for the off chance that you’ll need heat.  The temperature reset will force the furnace to stay off if the temperature is above 64 degrees outside and circulate cooler than maximum temperature water unless it gets cold enough outside.  The idea is that the furnace doesn’t work as hard and you save money.  I’ll probably have a report out on the data sometime in the future, but I digress.

The company who attempted to do the repair (and who shall remain nameless) came on Tuesday to look at the problem.  The technician tells me “I think the Tekmar controller is broken, but I’m not sure.  We don’t keep the part on the truck though, so we’ll have to come back tomorrow to replace it.”  I’m thinking “OK, but you knew what work you just did to install it, so wouldn’t you come prepared?”  Anyway, a different technician came back Wednesday.  After a couple hours fiddling around in the basement he comes up and tells me he’s confirmed the problem is the controller, but he too doesn’t have the part on the truck.  This is just getting silly!

I call the company to complain about the service quality.  They tell me that they’ll have someone out there Thursday afternoon.  I reject their offer, since I won’t be home Thursday afternoon and tell them this is getting ridiculous and that they need to be there Thursday morning.  They tell me that they’re fully booked on Thursday morning, to which I reply (essentially) “that’s not my problem, you’ve been here two days already and not solved it, and I’ve been more than accommodating to hang around the house while you fail to fix the problem with the work you did.”  The very nice office worker (yes, she truly was understanding and nice) says she’ll call me back.  When she calls me back, she tells me someone will be there at 10:30am.  I remind her to send the parts they’ll need for the repair.  I was half joking, half serious.

Thursday morning comes and I’m sitting in my office when the furnace guy shows up.  It’s a new technician, who introduces himself as Joe.  He tells me he’s the company’s ‘troubleshooter.’  I ponder who they sent before for a moment.  If it wasn’t the guy who could troubleshoot the problem, who exactly was it that they were sending?  Joe is down there for approximately 10 minutes when he comes up from the basement and tells me that it’s a simple wiring problem.  He doesn’t fix the problems though, so the technician from day two shows back up to actually redo the wiring they did incorrectly in the first place.

While the wiring is being redone, I get a frantic call from my wife.  She’s locked herself out of the house she nanny’s at.  Fortunately, the kids were outside with her.  This would be an honest mistake had she not done it before.  She says she’s tried to call the mother, but can’t reach her and was wondering if I could look up the phone number of the father.  Fortunately, the father runs his own business so his number is well advertised and reaching him is easy.

This, yes I know you were waiting for it, is where my two stories collide.  The furnace company and my wife had both made the mistake they made before.  The company shows up unprepared to deal with the issue they have; my wife locks herself out even though she knows that it’s a possibility it could happen.

Most people don’t obsess about their mistakes.  This is unlike me who will unmercifully flog myself over anything stupid I do.  Sure, I come off as a having a bit of an obsessive-compulsive disorder, but one thing is for sure about me, I NEVER make a mistake twice.  I’m obsessed with my own measurement of “personal quality” – not making mistakes I think are dumb.  That includes being obsessed about using Quicken to track my finances (on the more normal side of the spectrum) and having to check my alarm clock setting at least 3 times before going to sleep (on the more crazy side).

And that may be what makes me a good process person.  I’m obsessed with quality - my quality, everyone’s quality.  Obsessed I tell you, and I mean it.  When I do an analysis of a process I’ll hack away at it trying to prove myself wrong.  It’s not that I want to be wrong, but I’ve been wrong before, so I have to remove all self doubt that I might be wrong so that nobody ever catches me being wrong.  It’s also where I consider my OCD to be at a healthy level.  I still get lots done, but I reach a defensible level of confidence and can let it go.  If I couldn’t let it go I’d never deliver anything.

The furnace company and my wife are at the other end of the spectrum.  Make a mistake, that’s OK.  Make it again, that’s OK too.  For my wife, it was pure frustration that she had to suffer through.  For the furnace company, it cost them two days of labor by being unprepared.  Two unbillable days of labor – they couldn’t charge me a penny because they were under their warranty of their work.

So it’s your choice: don’t sweat the mistakes ever OR become a little obsessive about your personal quality.  I’m thinking if everyone was obsessed with getting it right, and embarrassed to be caught being wrong, a lot of the quality issue would take care of itself.  I’m encouraging you to be a little obsessive.