While I was away in China, a friend kindly lent me Malcolm Gladwell’s “Blink” (great book).
In “Blink”, Gladwell touches briefly on the subject of improvisational theatre. “The important thing,” he says (my paraphrasing) “is never to say ‘no’ to anything that anyone on the stage does. Work with it, and reply with anything which comes into your head, even if it’s silly.” So if someone says, “Regina! Everyone, this is Regina, that penguin that I was telling you about!” then your reply should not be “Um… I’m not a penguin.” Instead, it should be something like, “Why, it’s little Stanley! My, how you’ve grown! You were still a fish when I last saw you.”
The luckiest amongst us were given the opportunity to try our hand at this during our UK Away Day, with hilarious results.
I was very impressed by the ability of my peers to generate weird and wonderful ideas. With the certainty that no one would say ‘no’ to their suggestions, people played to their strengths. They were imaginative or supportive, dramatic or comedic, brave and wildly entertaining. “Wow!” I thought. “Wouldn’t it be great to have that kind of spontaneity in our projects? But how do I help anyone improve if I can’t tell them when they go wrong? What do I do if I see a better way, without making suggestions? How do I encourage them to try things out, and make them gravitate towards the right kind of things?”
The equivalent of this in a software project is to take other people’s solutions and build on them, instead of rewriting them; to never tell them that they’re violating a rule; to never say, “No! Don’t do it that way!” It’s pretty hard work – sometimes, people who aren’t familiar with the project’s single and elegant metaphor make a hideous mess, and others have never even heard of Dependency Injection – but with a little patience, I think it’s possible to get anyone moving in the right direction. Here’s a few things I found out / reminders to myself.
- It’s no use telling anyone they’re wrong anyway. Bright sparks hardly ever take advice on board unless it makes sense to them. The easiest way for someone to learn is to find out for themselves that there’s a better way. Sometimes, left to their own devices, people will naturally gravitate towards the simplest, most elegant solution – and it might just be simpler than yours. For instance, I played a Lego XP game with some newcomers from India who’d never seen Lego before. Instead of making their animals’ legs by stacking up small bricks, they simply turned the Lego sideways on and used the long pieces for legs – very clever!
- Encourage good things by using them – eg: read the names of tests to work out what a class does; trust that a method does what its name suggests; believe that the projects’ tests will tell you if you break anything. If no one thinks that an aspect of their work is actually being used, they won’t bother doing it properly – but when everyone in a project starts believing that the tests are reliable, that the design is maintainable, that the wiki is up to date, and everyone is using them appropriately, then everyone will work to keep things that way.
- Trust and respect people. Also trust and respect the work that they produce. Always believe that the thing you’re about to look at is perfect, or can be made so very easily. Remember that other people’s idea of perfection may differ from yours, and that there’s always more than one way to skin a cat.
- In a spontaneous environment, people are happier to remove restrictions they’ve placed on themselves. I was helping some newcomers to Agile work through a coding kata (little exercise) in TDD. Their design wasn’t optimal, but I congratulated them on their successful solution, then presented them with some new stories which conflicted with the design they chose. They optimised their design spontaneously, and I don’t think they even realised that their first one was over-engineered.
- Give people tools, and let them work out how and when to use them. Show them a couple of IDE shortcuts, and where to find the rest. Tell them where the Wiki is, but let them explore it and decide which bits are useful.
- Lose the bad by doing the good. Your customer can’t prioritise his stories? Prioritise and release them for him until he wants something different. He keeps changing his mind mid-iteration? Ask him which of the cards on the wall he wants you to swap out. Your new recruit doesn’t understand extensible design? Pick up a story which touches his code and ask him to pair with you; help him to drive. Your pair keeps coming in hung-over? Call out, “Good morning!” in a very cheerful voice. Etc.
- Do things that you’ve never done before, and encourage others to take on new roles too. Everyone learns! A lack of confidence is one of the biggest barriers to spontaneity. When people find out that it’s all right not to know the answer, they’re more likely to explore solutions than just guess. They’ll ask other people for help. Encourage people to help each other, and swap pairs if you’re needed somewhere else.
- Never wait to do the Right Thing. Right Things should happen spontaneously. Love the Right Things that other people do, and celebrate them. With chocolate. Let others see that you’re happy to do the Right Thing as and when it’s needed. Quick fixes and pragmatism are acceptable if they’re required for other Right Things, eg: to check in regularly, or to deliver that story within this iteration – but value those goals, not the Wrong Things which led to achieving them.
- Many best practices happen in a spontaneous environment without people realising that they’ve started doing them.
- There is a speed beyond which a rocket will inevitably escape the grip of the Earth, without any further thrust. Similarly, there is a level of spontaneity beyond which spontaneous things will happen without encouragement.
- It helps to have other spontaneous people around (thank you, Simon.)
- Spontaneous people surprise themselves, and the people around them.
- Surprise is a good thing.
Liz Keogh, lunivore 