appreciating your way to xp
three rivers institute
appreciating what is going well is a powerful alternative to the common engineering problem/solution mindset. this paper describes how appreciative inquiry can be applied to xp.
—extreme programming explained, 1st edition
this advice from the first edition of xp explained is a pretty good summary of the engineer’s approach to change: find a problem, solve it. unfortunately, this approach ignores many of the prerequisites for lasting change.
change is a complex process, requiring intellectual, emotional, and social effort. part of the complexity of change in the breadth of the foundation it requires. the person changing needs to be aware of the current situation. he needs to clear out any unhelpful emotional baggage about the past. “i’m such an idiot for getting into this situation,” isn’t a helpful feeling or thought. it may be true, but despair prevents change. change requires energy and ideas. bringing all of these factors together can be difficult.
the “pick your worst problem” strategy only provides the first of these prerequisites to change, an awareness of the current situation, and that only partially. by listing all of the problems and sorting them, you get a view of the situation but it’s biased negatively and it ignores whatever is going well. by the time you have decided exactly which problem is worst, you are likely to be depressed by the enormity of your list of problems (after all, all the rest of the problems on the list will still be there after you solve the very worst one). you don’t have the emotional energy to start changing. plus, you only have examined your problems, not potential solutions. you’re clear about what you’re going to ignore, little more.
change is not aided by the dominant engineering problem/solution metaphor, where the world is seen in terms of problems to be solved. a programmer who consistently underestmates tasks doesn’t have a “problem” which be “solved” by multiplying by a factoring or reviewing estimates with peers or some other simplistic fix. the roots of chronic underestimation generally lie deeper and improving estimation will likely require intellectual and emotional growth, the intellectual maturity to look honestly at previous estimates and actuals and the emotional maturity to be honest even when afraid of the consequences. problems are not solved, they are outgrown.
an alternative to seeing the world as problems to be solved is to see the world appreciatively, by focusing first on things that are going well or have gone well in the past. this assumes that something is going well, an assumption i had tested in a recent workshop. “i was in a meeting last week that was a total waste of time. we argued for hours and when we finally came to a decision it was overruled the next day by someone who didn’t bother to attend.” i asked if there was anything good about the meeting. “absolutely nothing. i mean, nobody lied during the meeting…” time out! honesty is a powerful beginning for improvement. our problem focus, enhanced by training and practice, blinds us to positives.
there is a style of
change called appreciative inquiry that takes advantage of appreciating
going well. focus first on positives, current or past, and find in them
and ideas to apply to what is happening now. reduced to a set of steps,
here’s how it goes:
these steps aren’t a rigid recipe, they are an example of applying appreciation. so, for example, i was talking with a team about their release process. they started complaining about how awful their last couple of releases had been. i remembered about appreciation, though, and started applying it.
“have releases always been this bad?”
“oh no. two years ago we rolled releases all the time with no problems.”
“really? what was different?”
“for one thing we released much more often. now that it’s so painful we’re taking longer and longer between releases.”
“the team was smaller then, so we all fit in one big room. now the testers are in another building and we have a terrible time communicating with them. it was great to just be able to answer their questions or show them a demo of a change.”
“well, what would you do if you wanted to get back to smoother releases?”
“first, we’d make the releases shorter. defering them because they are hard just makes them harder. then we’d have the developers and testers sit together. even if we can’t find a room big enough, it’d be better to split the team so half the testers and half the developers were in one building and the other halves were in the other building.”
this dialog is firmly in the spirit of appreciative inquiry:
using appreciative inquiry helps satisfy the prerequisites for change:
the brazilian playwright augusto boal says that catharsis has been used for millenia to maintain the status quo. if a peasant sees a movie of an oppressed serf seizing power, he experiences an emotional release but then those emotions aren’t available to fuel change. he doesn’t care as much any more. that’s what’s wrong with the typical bitch session (like the one about ugly releases)—everyone feels outraged at the situation but the emotions dissapate without anything changing. appreciative inquiry, by framing the conversation in positive terms, offers a way to transmute negative feelings into action.
the positive experiences you recall don’t have to relate obviously to the current situation. if your team is having trouble working together, having everyone remember the best team they’ve ever been on and what made those teams so good can be a good start to change even if those teams were sports teams or volunteer organizations. it might take some digging to get to the ideas, “okay, you respected each other but how did that happen?” “well, for one thing we drank beer after every game and talked about what happened.” “we’re all busy after work, but maybe we could have lunch together on fridays.”
sometimes you can apply the lessons of a positive experience directly, as in having the programmers and testers sit together. sometimes the positive experience sparks ideas that aren’t obviously connected at all. i once thought of sending a fruit basket to remote members of a team while telling the story of a team that all sat together. the goal in ai is not to duplicate the past but to gather ideas and energy for today’s changes.
one way i’ve had a lot of success applying ai is to pair up. for a half an hour, one member of the pair tells his story while the other person, the scribe, draws a mind map of the story. the scribe listens actively, reflecting statements, asking for clarification, and summarizing interesting points. after the half hour is up the roles switch and the former scribe tells his story while the former storyteller listens and draws. afterwards the pair can discuss the stories or present them to a larger group.
pairing is a chance for the scribe to practice good listening skills, encouraging the story teller, helping make sense of the whole story, and reminding the storyteller about the process. the scribe should resist the temptation to jump in with his own story—his turn will come soon. the best scribes leave you feeling that you have told your own story and that it has been thoroughly heard and understood.
you can also apply ai in larger groups, perhaps by having the partners summarize the story they just heard to the whole group (this works better than having them re-tell their own story). alternatively, you could go around the room collecting stories while a single scribe collects and summarizes the stories.
in groups is
a good way to find common ground where none seems to exist. the first
use of ai
i heard about was to settle labor problems at the
ai works well with extreme programming. pick a practice or a principle and tell a positive story you are reminded of. for example, think about pair programming and then encourage your partner to tell a story about close technical collaboration. everyone has a story about how they worked collaboratively really well. the lessons they extract may or may not look like textbook pair programming, but they are likely to encourage improvement. i once did this exercise in a large group and i got a wide variety of ideas for improvement—a weekly meeting with customers, joint design sessions at a whiteboard, coding together occasionally.
applying xp this way repsects the fact that people are responsible for their own process and that they change at their own pace. if you are an xp coach, you may be wondering what your role is in this process. you’re not there to tell people exactly how to pair and then enforce pairing. at the same time you aren’t a passive observer, encouraging people to do whatever has worked in the past. instead, you are there as part of the conversation. by telling your stories and applying them creatively you take an active role in change. by encouraging others to tell their stories and apply the lessons they find you promote positive growth and responsibility.
i encourage you to give appreciative inquiry a try, either the formal process or just a change in your own attitude. the next time you’re tempted to complain, find a good listener and tell them a story about when things like this went better or about the parts of the situation that are going well. finding lessons in your experiences and apply them.
i wish you appreciation and growth. the world isn’t a problem to be solved—that’s just one way of looking at it and there are alternatives.