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?…

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

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.

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

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.

Since Channel 4 in the UK started supporting the Mac for their online replays, I got hooked on Gordon Ramsey’s Kitchen Nightmares series¹. 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 reason². 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.

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.

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.

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.

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.

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

For those who don’t have a subscription, it turns out that willpower is a limited resource, like exercising a muscle. Different people have different limits, but when they’ve used it up they need time to recover. Worse, the relevant part of the brain may also be worn out by making difficult decisions and coping with stress. This is why it’s a bad idea to try to reform all your habits at the same time, there isn’t enough mental strength to go round.

The implications for us Agilistas are interesting. It explains the value of ceremony and automation that we emphasise so much, they relieve us from wasting willpower on known practices. It also suggests a validation for pair programming in that it allows one member of the pair to recharge their motivational batteries whilst the other pushes on. Another interesting result, from Peter Gollwitzer at NYU, is that doing task breakdown for an activity helps to get it done,

Planning can turn a difficult conscious decision into an unconscious habit, which makes the whole process faster and more efficient without depleting energy levels.

which sound like a good reason to crack open another pack of index cards.

Two more relevant points. First, willpower takes physical energy. Spending long hours slumped in front of the keyboard means that much of that work will be done when the brain is too tired to think things through. Second, willpower can be strengthened by practice. Exercising self-control in one area can boost it in others, which suggests to me that the benefits of building a high-quality culture will be better than linear.

The research also reinforces Roy Osherove’s point on the difficulties of getting TDD adopted, even if we differ on the solution.

Perhaps this means that there could be a measure for the hidden costs of organisational drag, what Ivan Moore and Rachel Davies referred to as Gumption Traps. If just making it to your cubicle burns up a significant fraction of your store of willpower, then there’s less left for writing great systems; that’s why I think the regime at DEC SRC was so remarkable.

Perhaps it might also explain why so many geeks who write perfectly clean code live in such a mess.

P.S. The New Scientist web site currently includes this infinitely depressing story about how, in a world that can find nearly a $1G to save the banks, we can’t save the cod.

Fishing vessels on the Grand Banks of Newfoundland are this week destroying the best hope for years that the region’s cod fishery, once the world’s most abundant, might yet recover.

And at a meeting in Vigo, Spain, governments have rejected a simple measure that might have given the cod a fighting chance.

That’s why I can’t read it all the time.

One of my (multiple) rants is about my brief experience at Digital Corp’s late Systems Research Center. Their technical recruiting was pretty tough but so, I guess, was their recruitment for all the other staff. They had the best administration staff I’ve ever seen. They would perpetrate unprovoked acts of forethought and helpfulness when you weren’t looking, same with the system administrators.

This works on all sorts of levels. First, if you’ve just spent a great deal of effort recruiting top-class researchers, it doesn’t make sense to have them spend time battling the corporate bureaucracy. Second, and deeper, the ethos in the building was that stuff would just work, so the technical staff would not be diverted from their real jobs—and, by implication, there would be no excuses for not doing good work. In contrast, at another international research lab, it took me months to get my expenses paid because the relevant administrator could not figure out which way exchange rates worked (more Dollars than Pounds at the time).

Like many such systems, it’s hard to understand or believe how much of a difference getting things right makes until you’ve experienced it; I expect this is how it feels at a first-rate Toyota plant. The rest of us have to learn to cope with the Gumption Traps waiting for us in the “real” world. In the distance, we hear the Siren call of the Pragmatic Fix.

Anyway, it’s all still true and those of us who are “young men in a hurry” ¹ trying to change things need to keep in mind the facts of organisational life. Here’s a sample:

Since the stone-axe fell into disuse at the close of the neolithic age, two other arguments of universal application have been added to the rhetorical armoury by the ingenuity of mankind. They are closely akin; and, like the stone-axe, they are addressed to the Political Motive. They are called the Wedge and the Dangerous Precedent. Though they are very familiar, the principles, or rules of inaction, involved in them are seldom stated in full. They are as follows.

The Principle of the Wedge is that you should not act justly now for fear of raising expectations that you may act still more justly in the future — expectations which you are afraid you will not have the courage to satisfy. A little reflection will make it evident that the Wedge argument implies the admission that the persons who use it cannot prove that the action is not just. If they could, that would be the sole and sufficient reason for not doing it, and this argument would be superfluous.

The Principle of the Dangerous Precedent is that you should not now do an admittedly right action for fear you, or your equally timid successors, should not have the courage to do right in some future case, which, ex hypothesi, is essentially different, but superficially resembles the present one. Every public action which is not customary, either is wrong, or, if it is right, is a dangerous precedent. It follows that nothing should ever be done for the first time.

Conford was one of the generations of academics who somehow managed to convert Cambridge from a combined training school for Anglican clerics and finishing school for the Gentry into something like a modern Victorian university. It might be that the university’s Byzantine organisation is what gives it the flexibility to survive. Most of rest of us, however, don’t belong to organisations that can wait 100 years to catch up with the opposition, so we’d better get a move on.

1) “Young men in a hurry” come in all ages and genders.

I’ve started a Yahoo Group for people who are interested.

What is going on out there?

A proposal for a Narrative Inquiry project within the Agile Narratives Program

Introduction

How does the Agile Alliance find out what’s important to its members, and highlight interesting new ideas amongst all the noise? The activity of finding out is called Sense Making. This proposal is for an experiment to understand how well one approach to Sense Making works and can be applied to the Agile community.

The Agile world is changing as adoption by individuals and organisations grows rapidly. It used to be possible for individuals more or less to know what was going on, but the community has long been too large for that kind of personal network. How do Agile practitioners, novice and experienced, make sense of current practice in the discipline?

One technique is to use personal stories from the community, managed as semi-structured data, to support quantative analysis and to help understand individuals’ concrete experiences. The Agile Narratives Program has been investigating one approach to this technique. This proposal is to start a complementary project in collaboration with Cognitive Edge using their Cynefin methods and SenseMaker tools.

Proposal

We will set up a programme to gather and index brief stories from members of the community about their experiences of adopting and working with Agile software development practices.

Bootstrap. We will start with a session, run at the London eXtreme Tuesday Club, to gather “indexing” topics, questions that the storytellers themselves will use to categorise the stories that they contribute. Cognitive Edge will then set up an initial data-gathering site based on those questions. We can prompt for contributions within the XtC and various Agile groups on the internet to seed the contents of the database. We might also be able to use some of the content from the existing Agile Narratives database.

Pilot. We will run a pilot event at XP2008, based on this data, to trial techniques for gathering and analysing further stories, in the context of a public event. Dave Snowden (founder of Cognitive Edge) will be a keynote at that conference, which will help to attract participation. This pilot will test our approach and should provide enough initial data to experiment with quantative analysis.

First run. We will run activities at with Agile2008 to raise awareness of the program and to gather stories from the much larger group, based on the experiences from the Pilot. We might have enough data by then to attract attention with some early findings, or be able to show how the results change over the week.

Ongoing. Once the project is established, we intend to keep it active as a place to contribute and find stories about Agile practice “in the field”, about practitioners’ real experiences. From time to time, we can re-analyse the data to report trends and surprises.

She’d been consulting for a while with a small business that provides quite a successful online service. The company had been bought out and, for a while, she improved their naive development practices while coping with complexities such as a new CTO who lived abroad and regularly dropped out of contact. In the end, she moved on to a new contract.

Sometime later, the CEO got in touch. He’d backed off some of his worst ideas, dropped some of the management and, eventually, hired her back as CTO. Good news.

On her first day, the lead developer threatened to quit unless he was allowed to start a proposed rewrite that day, another developer joined the mutiny. The CEO phoned after lunch and, with deepest regret, her tenure was over. The thing to remember about this situation is that the development team were mainly hired fresh out of college and only know this one company, whereas my colleague has lots of experience and is a name in the field. In her view, the codebase is bad, but not beyond rescue. My guess is that the company will burn a lot of cash on version 2 while its customers get fed up waiting for new features or patches to a neglected version 1. It’s a very high risk strategy for a small company.

How could the CEO fall for this? Presumably he knows a lot about the business the company services, but he has no background in the mechanics of what makes his product work. He has no instinct for when the developers, with the best of intentions, are getting carried away. So he’s taken what looks like the lower risk strategy, keep the people who got them this far, when in practice it’s the opposite. He’s also shown that he’s hostage to his developers which, much as I want to stand up for the underdog, is not a safe policy for either side. If he has any survival instincts at all, he’ll be looking for alternatives. Version 2 had better be a winner.

Update: Thinking further, I think it might even be worse, since the CEO didn’t see this coming, he hired a CTO without knowing how various core people would react and he didn’t have enough of their respect to make them listen. This is in a O(30) person company, not a mega-corp.