Don’t unecessarily break cultural norms

Today I was in an all-day meeting which was the wrap-up for an Agile iteration. It’s a, what’s it called, reflection session (silly hippie name), aka post-mortem for the rest of us. Anyway, 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.

For Agile projects, where the team decides the process, it’s part of being involved. I don’t have any issue with the doers being part of the solution. Quite to the opposite, LEAN philosophies insist upon it because it is the workers who know what isn’t working. But that’s where the similarity ends. In LEAN, once a best method is discovered, everyone does it until a better way is found. It becomes a form of local sub-optimization with continuous improvement being the goal for making changes. Agile, so far as I can tell from my reading, is more arbitrary. It’s whatever the team likes as opposed to whatever is currently known to work best. Maybe those two things are the same thing, but maybe not.

Anyway, that was a huge digression. So, we’re 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.

They can’t make it work, so it’s exactly why it’ll work for us…

I happen to be a Democrat, but I enjoy reading commentary from both sides of the aisle.  Today I was reading this particularly ridiculous piece written by a Republican commentator.  Mr. Feehery feels that the splintered nature of the Democratic party is an opportunity for Republicans.  His argument goes something like:  our party’s values are small government, social conservatism, rigid enforcement of immigration law.  The Democrats are large governement, socially liberal, loose on immigration.  Therefore, since the Southern Democrats, Hispanics and African Americans aren’t as socially liberal as those
liberal nutjobs in Washington, they could be part of our party.  We could win them over! 

Of course, for each of the reasons the Republicans might win them over, it’s their current platform that also drives them away.  The Hispanic population isn’t generally a fan of tough immigration laws, African Americans have been ignored by Republicans, and while socially conservative, the Southern Democrats presumably still believe in a strong central government.

Even were I totally off on why each demographic will and won’t shift between parties, if the Republicans managed to attract these demographics, they’d be in the same position that Mr. Feehery claims the Democrats are now in.  They’d suddenly have people in their party who didn’t match the current party platform: socially conservative, fiscally conservative, pro-gun, anti-abortion, anti-immigration.  Mr. Feehrey is a victim of survivorship bias.  He looks at his party and says “hey, we’re all aligned” but that’s because largely the people left in his party are those that shared the very narrow party platform.  Everyone else, the “non-survivors”, have been driven out.

So, sure, Democrats have a splintered party and they must sometimes compromise to maintain their voting bloc.  This somehow makes the alternative that the Republicans (who he superbly understates as “having their fair share of problems”) are offering workable?  Hey, these people didn’t vote for you for some reason… presumably because the things that the party ideals were against outweighed the elements of the party that people were for.

Which is the case with me, I’d probably be a Republican (I LOVE fiscal conservatism) except that Republicans are a disaster (in my opinion) on personal liberties.  I have chosen larger government, and more taxes, as an acceptable evil in exchange for a party that is willing to provide more social freedoms.  Anyway, I digress…

If you’ve got a situation which you deride someone else for failing at (or setting themselves up for failure at), and think that it’d work for you… take another looksie.  If it is failing, it is failing for a reason.  Just cause you could be running the show instead of them doesn’t get rid of the underlying problem.  This commentator’s entire argument appears to be “the pendulum will swing back” and from that one can reasonably conclude that it’d swing back yet again after that, and again, and again, and again, because nobody is actually solving the problem of why the splintered party doesn’t work.

Maybe it’d be better to be a minority, but at least a unified minority.  Maybe it’d be better to serve some customers really well than to serve many customers marginally…

Mini panic attacks

To some degree, I’m sure it is just my OCD, but I get these little panic attacks when I’m doing research. Just as I wrap up a piece I’m working on I’ll start to worry… did I check that this correlation wasn’t caused by this trivial event? Did I check that this relationship holds if I remove this new bit of noise I found in the measurement system?

I worry, mostly because I’m obsessed with not being wrong. But I also worry because statistics can give you a false sense of confidence. Maybe it’s something, but then again maybe it isn’t. What if it’s just statistical noise? What if this relationship I’ve found isn’t really there? What if we make a business decision based upon my research and I’m wrong!?!?!?

For one, I don’t want people’s faith in serious analysis to be shaken by my mistake. Even if I am wrong, the underlying capability of statistical analysis is still there. And two, I don’t want to have being wrong destroy the respect that I’ve built. So I panic, just a little bit, until I run that experiment or gather that extra data and things turn out to be ok. I worry about edge cases – funny, unlikely situations where my analysis wouldn’t be just a little off, it’d be dead wrong.

And worrying, it slows me down. It forces me to keep open analysis projects that any other person would have just completed. It doesn’t paralyze me, mind you, but it slows me down a bit. In exchange, on the occasion that one of my edge cases has proved me wrong, at least it’s easier to delete my 5-10 pages of analysis and restate the conclusion. The alternative would be to submit bad information because I wanted so desperately to prove my hypothesis. And on the flip side, I often have answers to those odd questions that come up when you are presenting your findings, because I worried about just the thing someone asked, and I already know the answer.

That’s one thing that statistics has done for me, and you should do for yourself, which is not to make you more certain of what you see, but to make you LESS certain, and to drive you to explore the darkened corners. It is a truly wise man who knows just how little he really knows.

10 Signs that your X is good/bad/etc.

Note:  My apologies.  I wrote this post from a Mac, and it seems to have lost lots of content in the middle plus screwed up the title.  I have no idea why, but I guess that’s the last time I’ll do that.  I’ve done my best to fix it.

My father in law is a psychologist.  I find it fascinating, since he has so many great stories about treating couples.  I love a good medical story.  So it was a strange coincidence that we (my wife, daughter and I) were visiting them for the weekend AND at the same time I was helping my brother develop a new website.

As I was showing off the website design to my father in law, he said “I’ve got this great site which I think is a great example of good design.”  And with that he sent me off to relational-coaching.com where I stumbled upon this article. 10 signs of a great relationship, huh?

I’m not qualified to decide whether she’s right or wrong, or whether 10 things is the right number of things, but it did get me thinking.  All the time we run into top N lists.  They appear to come in certain flavors:

1. Top Ten lists
2. Top Five lists
3. Top Seven lists (thanks very much Steven Covey).  Though I think the association with lucky 7 might have something to do with it
4. Top 50
5. Top 100
6. Plus 1 lists (ie 101 top things instead of 100)

Sometimes a list of 3, but it’s odd to see a list of 27, for example.  Whatever has caused us to gravitate to lists of N items, and why 3, 5, 7, 10, 50 and 100 have become those lengths, I don’t understand.

I know, I know, so what?  Well, in our efforts to make nice “round” number lists, are we missing something important?

I see it all the time at work.  For example, the other day I was given a list of the Top 5 projects.  But why not the top 6 or top 7?  Someone chose 5, but was it a logical break point?  No, as a matter of fact, it wasn’t.  There can be 300 or more projects at any moment active, but a scant few of them are really large (say greater than 1 million in spend).  And 1M in spend would be arbitrary too, but there is a break point.  Generally, we see little projects, those under $.5 M, almost nothing in the $.5M to $1M space, and then projects $>1M.  So the >$1M break point makes some sense.  Anyway, there were, oh I don’t remember, 32 projects >$1M.  

But still we do top 5.  The convenience of having settled on these numbers (3, 5, 10…) should not outweigh a look at your data to see if there’s a logical place to say “this group looks different from that group.”  If you want to talk about “the big stuff” then figure out what it really means to be “big” and set the criteria that way.

Had the situation been different and we had a continuous range of projects costs from 0 through >$1M, you’d need to do some hard thinking about where to segregate the populations, if you should even segregate at all.

Don’t pick the top N because it feels familiar.  Pick the top N only if it makes sense.  And don’t assume that N has to be one of 3, 5, 10 and so on.  If it’s 27 items, so be it.

Leaner today

My wife and I are attending a wedding in the next few weeks. That’s a generally unremarkable occurrence. We’re about the age where our friends are getting married and starting to think about kids. In fact, I generally dread the events since we’ve been to so many and each one costing us a gift, a hotel room for a night or two, a sitter for our daughter, yet another new dress for my wife, and the list goes on…

Going to weddings is expensive. At any rate, we had not actually been to a wedding in quite a while. I have recently lost some weight, so I decided to try on my suit and make sure it still fit. Alas, it did not, so adding to this wedding’s tab will be a tailoring of my suit.

At my lunch break I popped down to the local tailor (who is just the stereotype I imagined sitting in his little shop with his thick eastern European accent). He has me put on my suit and stand up on the little, what do you call it, soapbox, I guess, to have a look see. I mention in passing that I’ve lost some weight recently.

He’s kind of tugging here and there, getting a sense for it, mumbles something under his breath about it being a nice suit (which I appreciate). Eventually he looks up at me and says “you’ve lost 30 or 40 pounds, no?” I smile. Hey, just because I’m a guy doesn’t mean I can’t appreciate this compliment.

“No, ” I reply, “I don’t think that much.”

“Ah, it must have been a little too large to begin with.”

“Hmph,” I think. Some nerve. First he compliments my weight loss (which I admit I had not lost 30 or 40 pounds – or at least I don’t think so)  and then suddenly it’s a suit that was always too large…

Too large to begin with, eh?  That reminds me of something. Measurements! Recently at work, someone asked me how we compared to our competitors in regards to development efficiency. Setting aside the fact that nobody can agree on exactly how we should measure efficiency, I reply “what does it matter?”

“Well don’t you want to know how we’re doing?”

“Is our customer happy with our performance, “ I ask.

“No.”

“Then it doesn’t matter how our competitors are doing.  We are not doing well enough.”

It’s like my suit. Sure, I’m too small for my suit to begin with. Compared to my suit, I am leaner than the suit would hold, but am I happy with my weight? I guess I’m ok with it, but I could stand to lose a few more pounds.

By comparison, we may be better than our competitors when it comes to development efficiency. The suit sized for our competitors is too big for us, so to speak. Alas, it doesn’t matter, because the customer (or in the case of my suit, my wife) doesn’t really care that you are good in comparison. Sure, I guess maybe my wife is glad that I’m not the thousand pound or five hundred pound or even two hundred pound man coming down the street, but I still could be a bit leaner than I am. And so can your company. It’s not success just because you beat everyone else. If it isn’t good enough for your customer, it isn’t good enough.

Another survey mess

I feel like I’ve written this before, but it just keeps coming up, so if I have, I’m sorry. Surveys are not for collecting data. I know what you’re thinking. What do I mean? Survey’s are all about data, aren’t they?

I’m going to make a generalization, that whether it is entirely true or not, I think is pretty fair. Surveys are not for collecting data. They are for collecting opinions or impressions. Why? Because surveys are notoriously bad for getting hard facts.

So why bring it up again if I’ve already written about bad surveys? Because I just had another one at work. The question at hand was: “how are teams compliance to the process we’ve defined?” And the team tasked with figuring this out had a relatively short window of time to figure out the answer.

The right approach is to go audit projects at random and see what evidence of following the process exists. The wrong approach is to survey people. They chose to survey because they thought it’d be a fast way to get some data together. Fast it was. Good/useful it wasn’t.

Why? The list of reasons is long:

1. When asked questions about their own behavior, people are disinclined to present honest answers. This effect happens all the time in surveying. For example, asking teens about illicit drug use is not going to get you a valid answer. Admittedly, to get a true picture, you’d have to randomly select kids and drug test them (which they probably wouldn’t submit to), but you certainly can’t walk up to them and expect everyone to be honest. “Sure, I use drugs all the time. Have you met my Mom, she’s standing right here next to me.” The funny thing was, the team didn’t think it’d happen to them. And I quote “if we can’t trust our teams to give us honest answers, who can we trust?” Well, not your teams anyway as the results showed.
2. As a corollary to #1, if you take away anonymity from the survey (by asking for someone’s name, for example) you can be sure that #1 will be more skewed than ever.
3. You can’t ask questions about other people, generally. When surveying, you should be asking about their own behavior/beliefs/whatever. Asking someone about how someone else behaves/thinks/etc. is adding conjecture to your results. In our case “how often does your team follow the process” is invalid. If you want to know how often people who are supposed to be following the process do follow the process, and you are going to insist on surveying, don’t ask the manager of the team, ask the members of the team.
4. You can’t ask data questions. Well, you can, but see #1. If you want facts, there are lots of better ways to research a topic. If you want to know how someone feels about something, a survey is a good choice. In good surveying, you see questions like “I am satisfied with the process we use to develop software” with answer choices of “strongly disagree, disagree, neutral, agree, strongly agree.” But a survey isn’t a good choice for “I follow the prescribed process” because of #1.

What was really sad about this, was even though the team had already violated the principles of a good survey, they took it a step further. Once they got results, for anyone who answered (likely honestly) that they weren’t following the process, the team wanted to know who they were so they could go talk to them. Uh, hello? If you crucify people for being honest, you can bet next time they won’t be honest.

If your first reaction to getting data is to survey, follow these easy steps to determine if it is the right choice:

1. Go home (optional, depending on your workplace)
2. Pour yourself a stiff drink (this is to prepare you for step 3)
3. Beat your self into unconsciousness with a baseball bat (or the empty liquor bottle)
4. When you come to, think of another way to get the data you need.

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.

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 you 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.

The testers will take care of it

Just this week I was attending a webinar regarding making test organizations more efficient. I’ve been doing a lot of work with test organizations lately so I figured spending some of my time to learn something new would be worthwhile. The presentation was pretty good, and the presenter had, I think, one exceptional statement about front-loading quality. It went something to the effect of “developers should believe that the system is ready for the users when they deliver it to system test.”

Simply stated. Brilliant! The point of front loading quality is to make testing unnecessary. So, he continues to tell us this story about how he gives presentations to teams that he is consulting with and makes the above statement and then waits out the silence. A long pause, he says, before some brave soul says “we can’t do that!” (or something to the effect). At which point, having taken the bait, he then asks them “well why not?”

And the answers come pouring forth:

1. We don’t have the skills
2. We don’t have the environments
3. We don’t have the tools
4. We don’t have the time

And so on, and so on, and so on. What!?!? How is it that your developers are allowed to give these excuses for why they deliver poor quality code into the environment? And more importantly than all that, what makes a developer think that if they have these barriers to delivering quality code why testers will have any capability to do solve the problems that developers cannot.

These are false barriers. These are excuses. The testers, who find all your bugs, have test environments. The testers, who find all your bugs, have some set of tools. And testers, mind you, don’t go to college to learn how to test. By in large, testers are developers who couldn’t. Sorry to say it, but it is true. Testing is an organization usually comprised of the weakest developers and analysts. Not that it necessarily should be, but every experience I’ve had says it is.

If your developers can’t find their way past their reasons, what secret to testers have that would make what were intractable problems into tractable ones? There is no valid excuse for being incapable of delivering quality code.