A Commonplace

What is a commonplace?



Agreed Activity

I got this idea from improvisational theatre. It's one of the great things about living in London that you can sign up for a class in all manner of activities and improvisational theatre is one that's really popular. And it's a very thought-provoking experience.

In improvisational theatre, there is no script. Two actors are on a stage trying to improvise a scene, they are in a very stressful situation. Everybody is watching them, they are supposed to be entertaining. But of course, in the attempt to be entertaining, there is always the possiblity that you'll fail and look ridiculous. The intriguing thing that happens on stage is that improvising actors , especially inexperienced ones, tend to sabotage their chances in a number of ways. All of these ways of sabotaging the performance involved lowering the risk to the performers, but at the same time result in raising the risk for the performance.


Blocking is just diagreeing with another improviser. But there is disagreeing and disagreeing. For example, let's say someone knocks at my (imaginary) door and says "I brought you a cabbage." In terms of the interest in the scene, it's fine for me to "disagree" and say something like "You're not going to convince me to be a vegetarian Kevin. I want meat, raw meat, the flesh of humans." But if I react to the line "I brought you a cabbage" by saying "That's not a cabbage." I'm disagreeing with the idea. In improvsational terms, I'm "lowering the stakes."

Agreed Activity

Let's say that a scene is introduced (an idea from the audience) "you are crew members on the pirate ship" and there are several people on the stage. The crew members start to look out to sea (so far so good) and one of the crew notices something on the horizon. Another crew looks through an imaginary telescope and realises that it's galleon laden with gold. At this point, someone else might say "Well, before we attack that ship, we should probably clean the decks." This is a terrible move from the point of the story (what does the audience want? it wants the pirates to be in that battle attacking the galleon loaded with gold). But it's a trap that scenes often fall into. Here's the reason: while all the crew members are scrubbing the deck, they feel "safe".

But while the actors are feeling safe, the story is in danger of becoming extrememly boring.

In improvisational performances, one cure for this is to have a director at the side of the stage who can notice when improvisers are blocking or falling into agreed activity and chivvy them along. Perhaps by shouting "no, it's a cabbage!" when an actor tries to block the suggestion. Perhaps by shouting "The deck's clean - the galleon is sailing straight toward you!" If the crew are tempted to clean the deck.

OK here's a question. What if that team of improvisers on stage is ten strong? What if each of them is on "stage" five days a week, for a year. What if that team is being paid IT contractor rates? What if they're doing the software development equivalent of mopping the deck? What if you've got a program of ten teams like this? That's a very expensive "improvisation." But with just a few choice words and phrases in the right place, also, possibly combined with ignoring important information when it's offered, it's very possible to convert a whole floor of IT professionals into rhythmically cleaning deck hands.

OK, enough of the allegories and the metaphors. What the fuck am I talking about?

I'm talking about this. A team will naturally tend towards safety. That will be some kind of agreed activity that will avoid danger and difficulty. The job of anyone who's leading a team is to continually encourage them to expose themselves to some danger, in improv terms this would be to make the story interesting, in software development terms, this is to make the project useful and valuable. The story needs to be interesting, but not catastrophic. In fact, improv also has a term for when a story becomes boring because too many things happen one after another "Trouble Salad." No, the job of the manager of a team is to keep the team exposing itself to enough "danger" that the life of the project is interesting.

And here's something really important: the job of the customer is to reward the team for exposing themselves to some danger. If the team highlight a potential danger to the project, this absolutely must be welcomed and encouraged - not the danger, but it's reporting. If any messengers are shot, there will be no more messengers.

What are these ways that the team can continue to be exposed to danger?

Here's what a successful project that I worked on did.

  1. A fortnightly "risks and issues" meeting where all the risks and issues that we thought the project was facing were discussed with the senior management, and scored according to some spurious scoring system - notionally taking into account how likely a risk was and multiplying it by how much the risk would take to put right if it came to fruition. This was a totally bogus scale, it might as well have been called the WFS (the whoa fuck! scale). But it meant that regularly the team and the customers were talking sensibly, if sometimes in a white knuckled, tight-lipped fashion, about the risks that the we knew about.

  2. Show and tells of working software every fortnight. From as soon as we had working software to show, we showed working software to the people who were paying for the software and the people who were using it and we captured the feed back.

  3. Research with users on what the users need, research with users on how our working software met the users needs.

This is the biggie. We had a reality check piped right into the team.