Stephen Freeman Rotating Header Image


What are we being primed for?

The excellent BBC popular science programme Bang Goes the Theory, recently reproduced this experiment on priming. In the original experiment, the subjects were primed by being asked to write sentences based on sets of words: one set was neutral and the other contained words related to an elderly sterotype. The result was that

participants for whom an elderly stereotype was primed walked more slowly down the hallway when leaving the experiment than did control participants, consistent with the content of that stereotype.

In the “Bang” experiment, they took two queues of people entering the Science Museum and placed pictures of the elderly and infirm around one queue, and the young and active around the other. The result was the same, people in the queue with the elderly images took significantly longer to walk into the building.

It’s striking that such a small thing can affect how we behave.

Now, look around your work environment and consider what it’s priming you for. Are you seeing artefacts of purpose and effectiveness? Or does it speak of regimentation and decay? Now look at your computer screen. Are you seeing an environment that emphasises productivity and quality? Or does it speak of control and ugliness?

It’s amazing that some of us get anything done at all.

This isn’t about spending lots of money to look nice (although that espresso machine is appreciated). I suspect that the sort of “funky, creative” offices that get commissioned from designers dressed in black are usually an upmarket version of motivational posters.

My guess is that a truly productive environment must have some “authenticity” for the people who spend most of their days in it. Most geeks I know would be happy with a trestle-table provided they get to spend the difference on a good chair and powerful kit, and other disciplines might have other priorities.

But then, perhaps every environment is authentic since the organisation is making clear what it really values most. And what might that imply?…

Not a charter for hackers

Just had to turn off comments since this post has become a spam target. Sorry.

Update: Kent since tweeted this nice one-liner:

a complete engineer can code for latency or throughput and knows when and how to switch

Kent Beck’s excellent keynote at the Startup Lessons Learned Conference has been attracting some attention on The Interweb. In particular, it seems like he’s now saying that careful engineering is wasteful—just copy and tweak those files to get a result now. I can already hear how this will be cited by frustrated proprietors and managers around the world (more on this in a moment).

What I think he actually said is that we should make engineering trade-offs. When we’re concerned with learning, then we want the fastest turnaround possible. It’s like a physics apparatus, it’s over-engineered if it lasts beyond the experiment. But, if we’re delivering stuff that people will actually use, that we want them to rely on, then the trade-off is different and we should do all that testing, refactoring, and so on that he’s been talking about for the last ten years. Kent brushes over that engineering stuff in his talk, but it’s easy to forget how rare timely, quality delivery is in the field.

My favourite part is Kent’s answer to the last question. A stressed manager or owner asks how to get his developers to stop being so careful and just ship something. Kent’s reply is to present the developers with the real problem, not the manager’s solution, and let them find a way. What the manager really wants is cheap feedback on some different options. The developers, given a chance, might find a better solution altogether, without being forced into arbitrarily dropping quality.

Good developers insist on maintaining quality, partly to maintain pride in their work (as Deming proposed), but also because we’ve all learned that it’s the best route to sustained delivery.

As Brian Marick pointed out recently, it’s about achieving more (much more) through relationships, not one side or another achieving dominance.

Mark Twain again

We should be careful to get out of an experience only the wisdom that is in it—and stop there—lest we be like the cat that sits down on a hot stove-lid. She will never sit down on a hot stove-lid again, and that is well; but also she will never sit down on a cold one any more.

via Gemba Panta Rei

Twain also wrote of opera, “that sort of intense but incoherent noise which always so reminds me of the time the orphan asylum burned down.”

Software Nightmares (2)

About a month ago, Michael Feathers wrote another post that cited Gordon Ramsey. That reminded me to follow up my earlier post with observations from a couple of episodes from UK series 4 that make the point (thanks Channel 4).

First up is a curry restaurant in Nottingham (which has no shortage of competition) opened by an ex-sales manager and glossed up to look like an ’80s night club. Being from sales, his view is that the customers gets what they ask for, so he’s offering design-your-own curries—whatever combination you want. The result is that the kitchen brigade (who are good) can’t cope with the variety and turn everything to mush. When Ramsey has them cook all hundred-odd dishes on the menu, the waiting staff can’t tell which is which.

The owner sees the process as simple order-taking. Offer the customers whatever they ask for, regardless of the effects on the demoralised staff and low quality. It turns out that the customers aren’t curry experts and don’t like what they’re getting, so the restaurant is losing money. Ramsey’s solution is to cut the menu back to something the brigade can do well, and to offer what the customers what they actually want.

Second up is a carvery outside London that’s been bought by Scott, an ex-IT consultant. It’s losing money so, in an attempt to fill the place, he’s offering two-for-ones at below cost price; the only people who put up with the dreadful food are pensioners. He’s hired a cheap brigade who can’t even cope with the grill idea that Ramsey proposes, and the kitchen is so decrepit that Ramsey has it condemned. Scott is discovering that reducing costs isn’t working and risks poisoning the clientele.

Scott seems most comfortable in the office behind a computer, presumably planning the work that everyone will do. He appears to be the only owner in any of the series that has no interest in food or customers—the value part of the equation. He has no idea if his people are competent or what constitutes good service.

Back-to-back, the episodes make a nice pair. To belabour the point, we can’t do good, valuable work when the process is one-sided: when requirements are forced through an organisation without thought for the consequences, or when work is driven from behind the scenes without enough attention to a paying customer.

It should be obvious, but we need reminding. Hands up if you work in one of these places.

Software Nightmares

This post has been stewing for a little while, and now I’ve been kicked into writing it up by Naresh Jain’s post on Lessons Learnt from Restaurant Business.

Since Channel 4 in the UK started supporting the Mac for their online replays, I got hooked on Gordon Ramsey’s Kitchen Nightmares series1. I’ve never worked in a restaurant and I know that TV programmes are a manufactured narrative, but (inbetween all the swearing) there are some interesting themes that come through every week:

  • cook stuff your customers actually want. Some owners get carried away with bigger ideas than they can handle;
  • reduce the menu to something your staff can cope with. Bloated menus and fancy presentations cripple the kitchen staff. Cut it all back to something they can do well;
  • help the staff take pride in their work. Producing stuff badly for unhappy customers is wasting people’s lives, and probably not sustainable. One of Ramsey’s triggers for cussing out the brigade is when they’re not trying—and watch their reactions when they turn it around and he praises them;
  • cook your own stuff. Don’t rely on outside prepared stuff unless there’s a very good reason2. Bring in good ingredients and, um, cook them;
  • take responsibility. You’re the chef/owner/manager/waiter, so do your f***ing job;
  • communicate. Head chefs should be talking all the time so their brigade knows what’s going on, waiters and chefs should discuss the tickets so they know what’s ordered, waiters and managers should talk so they know what’s going on with their customers; and,
  • see it as it is. The building looks run down, the kitchen is filthy, the food is disgusting. Stop fooling yourselves.

I know it’s relatively easy to come in and see how to rescue a business that’s months away from failing, after all an outsider has the advantage of not having been sucked into the mess. But, even through the box of mirrors that is TV, Ramsey shows two strong drives: total focus on providing the best service to the customer, no excuses; and, total respect for the craft of cooking. He just lights up when he finds a junior with ability and enthusiasm.

Somehow, I feel this ties in with a post from another coach given to immoderate use of language, Mike Hill wrote about how raising your internal quality makes you go faster. I think there’s a commonality of purpose there that we should take note of.

1) I mean the UK version of this series. The US series is like a boil-in-a-bag version: manufactured, over-spiced, unsatisfying. In fact, the opposite of everything Ramsey is promoting. But that’s another story.

2) Yes, I know there have been some “scandals” with Ramsey’s London restaurants, but that doesn’t invalidate the point.

Another interview technique…

From Guy Kawasaki interviewing designer Hartmut Esslinger,

If a young person wants to be a great designer, what should he or she do?

Finally, a young person with the right talents needs to have infinite desire and never give up. I apply a simple test with young students: smash a teapot into pieces and then hand out the glue. Those who rebuild the teapot won’t make it, those who create phantasy animals and spaceships will.

Kanban for beginners

Karl Scotland has a post on whether Kanban is only suitable for mature teams. (in case you haven’t guessed, he thinks not).

The magic of Kanban is that it all it really does is make the current situation explicit. If the team is in a position to respond then they will figure it out and do something; if they can’t then they have a much bigger problem than their methodology. Kanban does require that the people involved care about what they do (scepticism is disappointed caring) and periodically reflect, and patience (not my strongest suit).

On the whole, I’d say that Kanban-inspired improvement is most likely to stick, if the organisation can afford to wait. Sometimes the commercial situation is so dire that there’s not enough time for the team to discover its own way to more productivity.

Experienced Agilista's proved wrong (again)

So, Jurgen Appelo is unhappy that some of the more experienced Agile names have been telling him what to do. In particular, apparently they’ve been doing so without understanding complexity theory; he’s not reacting well.

In between the ranting, much of what Jurgen says is obviously true. For disorganised teams, adopting Scrum and nothing else will help them get more organised and productive, as seems to be his case. But he then goes on to say that anyone who tries to clip his wings and tell him how to develop software cannot be agile because they’re not adaptive enough—and by the way, he knows lots of stuff about complex adaptive systems that other people don’t.

My first reaction is to suggest that he not underestimate some of the people he’s reacting to. Ron Jeffries can certainly be provocative, but I don’t think he does it to try to convince people he’s smart. And some of us have been investigating complex adaptive systems for years.

What I think Jurgen is missing (or at least not making explicit) is that there isn’t a single axis between chaos and ordered, some aspects of an organisation do need to be ordered (in the end, we’re dealing with physical machines here) and some things complex (the people bits, usually). I may use complex adaptive techniques to understand what to build and how to communicate that, but I also want the thing to work reliably and not to be dragged down by a fear of making changes.

Sure, people in the community say dumb things, but we have actually learned some things over the last ten years. One is that we see team after team that has hit the wall because they didn’t work cleanly. Some have the luxury of a financial buffer which allows them to continue working sub-optimally. Just a few teams have understood the real trade-offs and can undercut the opposition by delivering faster and more reliably—and no-one promised that it would be easy or quick to achieve.

"How do you judge if your firm is ready"

From one of the Lean mailing lists. It was posted in the context of Lean adoption, but seems to apply to just about anything…

I believe there is only one pre-condition. The leadership of the company must believe “The status quo is no longer an acceptable way of doing business”. […] One of our associates gave me that quote. She was asked what lean meant, and that was the reply.[…]The rest is just technical details.

As if software mattered…

From a history of the development of SIMULA

In the spring of 1967 a new employee at the NCC in a very shocked voice told the switchboard operator: “Two men are fighting violently in front of the blackboard in the upstairs corridor. What shall we do?” The operator came out of her office, listened for a few seconds and then said: “Relax, it’s only Dahl and Nygaard discussing SIMULA”.

via Lambda the Ultimate