A Quick Question About Practice

April 30, 2011

When you practice something in a disciplined way on occasion you may experience interruptions in your practice. I’m talking about the usual stuff that happens to everybody: you go on vacation for a week, you get a bad case of the flu and spend a week recovering, you are injured, life happens. So what happens when you return to your practice?

I know that in my case there is a very noticeable degradation in my performance. I lose ground and I have to spend time re-attaining the level of performance I once had prior to the interruption. Does that same phenomenon happen for scrum teams? Do we go away for Christmas break and come back into the office and…suck? Do we need some time to get ourselves back up to our prior competence levels? How does that work for you?

Dueling Silos

April 29, 2011

In Forming Silos, I reviewed the Robbers Cave Experiment and how they tried to create silos as part of their research on in-group and out-group conflict. In this post, I want to review stage two of the experiment, where the intent is to create conflict between the two newly created silos.

On the face of it, creating tension between two groups is so easy it’s almost embarrassing. All the researchers did was create a series of winner take all challenges for the two groups to compete in. Then, to aggravate the situation, they subtly manipulated the scoring so that each side would cheated out of a win. Of course, back in the 1950’s this was a relatively novel idea. Now we have reality TV and we call it ‘Survivor’. The difference the Robbers Cave experiment and ‘Survivor’ was that in the case of Robbers Cave, nobody is voted off the island.

The challenges were the sorts of games and other activities that you would commonly find in summer camp: baseball games, football games, tent pitching competitions, tug o’ War, cabin inspections, skits and songs, treasure hunts, and so forth. The emphasis was on keeping the competition as realistic as possible. I think the importance of keeping the setting as natural as possible was critical to the success of the experiment. They did not want the boys to feel like they were being manipulated or observed by the camp counselors/researchers (even though that is exactly what was happening). So rather than setting up artificial challenges, the researchers went to great lengths to make sure that the challenges were appropriate to the setting. In fact, the researchers were so concerned about this that they repeated the study on at least two different previous occasions before getting it right on the third try. That sort of persistence is particularly impressive, given the enormous investment in time and resources required to put together a large experiment like this.

So we have the two groups competing against one another for scarce resources (various and sundry trophies, flags and other rewards). In very short order the two groups not only hate each other, but they are getting into name calling and fist fights and refusing to go anywhere near each other. They go so far as to raid each other’s cabins, wreaking havoc, and stealing things from ‘the enemy’ team. By the end of this phase, we have two groups that well and truly hate each other. They exhibit all of the territoriality and biases that characterize a pair of badly dysfunctional silos. Furthermore, they manage to accomplish this in less than a week. Apparently, it does not take very long to create a dysfunctional group.

As in the previous stage of the experiment, the researchers had a few hypothesis about what might happen in stage two when the competition was introduced. Their first theory was that competition would increase the in-group solidarity of the two teams. This makes sense, when we are competing against some outside enemy, you would expect it to tighten the interpersonal bonds within your own group. In fact that’s exactly what happened in this case. The teams became more tightly knit in the face of competition from another group. To use a cliché, each group closed ranks in the face of danger.

Another hypothesis was that the functional relationships between the two groups would affect the relationships within each individual group. This is a little hard to sort out, but as I understand it, what this means is that if things are going poorly for your group in the competition between your two teams, it is very likely that there may be a change in leadership for your group. I’ve seen this happen before in competing teams. The tension and the friction that builds up between the two groups eventually leads to one group looking, at least temporarily, like the “winner” and the losing group may reorganize itself in the face of their own perceived leadership failure. I do not think this necessarily alleviates the problem in any manifest way, but it does follow that the intergroup relations reflect on the relations of people within each group.

The final hypothesis is the one that I find the most worrisome of the bunch. Basically, in a group conflict, the theory is that low status members of either group will be more likely to act out violently in deed and word than higher status members of the group in order to to improve their own status within the group. Therefore, not only do you have the inter-group conflict going on, but you also have people within each group who are trying to take advantage of that conflict in order to advance their own status within each group. How do they try to change their status? By being the loudest voices to demonize the other group. They do accomplish their ends by actively provoking conflict between the two groups. This of course just serves to further aggravate the tensions already present between the two groups. At this point, the conflict has becomes self-perpetuating.

If we stopped the experiment here, I think that there are many people who might just say, “You see? I told you so. People are just nasty and brutish.” There certainly were those who only seemed capable of reading to this point in the study and deciding that it confirmed all of their worst stereotypes of human behavior. However, the experiment doesn’t not stop here. This is still the setup for what is perhaps the most interesting phase of the experiment – the stage where they introduce the strategies they used to reconcile the two groups. The story of how they managed to re-integrate the two groups and achieve real collaboration is truly remarkable.

The Great Screaming Treadmill of Doom

April 28, 2011

I have a few pet phrases for that exhausted feeling you get when facing yet another project: The Mighty Exercycle of the Apocalypse, or The Great Screaming Treadmill of Doom, and my personal favorite: The Harrowing Habitrail of Hopelessness. It’s that “Oh no, not again!” staring-down-a-gun-barrel feeling you get when confronted with yet another mediocre project.

I’m pretty sure I’m not alone in feeling this emotion. No matter what process you use, whether it’s Waterfall, XP, or Scrum, sooner or later you run into this problem. Unfortunately in the corporate world, the reward for successfully finishing projects is even more projects (Whoopee!). Sooner or later that starts to get old. Especially when it’s the same old stuff. Sometimes I think management is just curious to see how long you can keep it up. Pretty soon you are asking yourself, “Why am I doing this?”

In the words of King Osric in Conan the Barbarian:

“There comes a time, thief, when the jewels cease to sparkle, when the gold loses its luster, when the throne room becomes a prison, and all that is left is a father’s love for his child.”

OK, maybe not that last bit about the kid, but you get the idea (I’ll have to follow up with another blog on how to use inappropriate quotes…). So back to my topic – what do you do when you realize you are riding The Great Screaming Treadmill of Doom? Put on your sneakers?

No. Here are a few of the things I do:

  1. Start with the customer: OK, I’m not passionate about this project, but how about the customer? If they are excited, then I tend to get excited too. In fact, one of the best ways for me to reinvigorate myself is to attend a customer conference – I get tremendous energy out of that kind of interaction
  2. Start with the team: What do they want to do? Are they energized or not? If I’m having a bad day, the team can often mellow me out in record time. Usually there is a beer involved…
  3. Start with the retrospective: When I’ve participated in the perfect project I plan to announce it on this blog. Until that day, I can usually go to the last retrospective and find a long list of things I can improve. If I focus on the improvement, everybody wins.

These things may or may not work for you. It just may be that it’s finally time to sit down and seriously ask yourself the big “Why” questions. If that’s the case, then I recommend that you do it sooner rather than later. Every time I wait to ask myself those questions I tend to regret it.

Who Is Your Coach?

April 27, 2011

If you are anything like me, finding a good coach or mentor is a challenge. Frankly, until recently I had a good excuse: I had no idea what a good coach looked like. After doing a little reading I’ve come to realize that there are a few things that I need to find in a coach:

  • They need to have model of the discipline or domain that is more detailed and robust than mine
  • They need to be able to make a connection with me on a personal level
  • They need to be able to provide a coherent vision of what the path to success looks like

You see, it’s all too often that I’ve been in seminars on Agile coaching and realized one of two things: either I really have no idea how to advance beyond my current skill level, or whatever the current state of affairs is – it provides me no guidance on where to go next. At these times I feel stuck in a rut. What I need is somebody who can paint a picture for me of what the discipline of coaching should look like. In the case of someone who is already fairly experienced, that picture needs to be very detailed.

Of course they need to be someone that I can relate to well. This is a tough piece of chemistry to get right. For some people this may mean that they relate best to someone who has a very spiritual bent. For me, it probably means somebody with all the scintillating personality of a marine drill sergeant (on LSD). It’s going to be different for everyone. Maybe it’s because I’m an introvert by nature, but I find it hard to make that kind of a connection. Fortunately, there are lots of other proxies for a coach that are available to me:

  • Teams: Being part of a well functioning team provides insanely good feedback and guidance.
  • Colleagues: Whether it’s in consultation over a beer or between sessions at a conference, I learn a lot from my peers.
  • Social media: There’s nothing quite like saying something stupid in front of a large audience to generate feedback!
  • Reflection: I write in a journal, reflecting on what happened in the day, how I felt about it, and what I plan to do about it.

I’m sure there are lots of other obvious or not-so-obvious ways that people obtain coaching for themselves. What are some examples that work for you?

Forming Silos

April 26, 2011

As part of my research for our Silo Busting tutorial at XP2010, I’m reading “The Robbers Cave Experiment: Intergroup conflict and cooperation” by Muzafer Sherif et. al. I first heard about this experiment from Linda Rising (one of my all time favorite speakers and writers) who used it as the topic for a great presentation that she gave at the Agile2008 conference. Her presentation made a big impression on me, so much so that I found myself ordering the book about the study. The Robbers Cave Experiment is a classic experiment in social psychology from the 1950s that has profound implications for the way that organizations work together today.

[One tiny little caveat here: this is a social psychology study from the fifties. At the time, psychology was, and some would say still is, struggling to be taken seriously as a science. As a result, in general the published papers are God-awful dry and boring. I mean make-a-grown-man-cry-for-mercy boring. That way they seem more scientific! You have been warned.]

The purpose of the experiment was to explore how social groups form, how they come into conflict, and to experiment with means of resolving inter-group conflict. The subjects of this experiment were two groups of 12-year-old boys who were going to a summer camp at the Robbers Cave State park in Oklahoma. This study took place in the late forties and early 1950s, back in the day when there was a lot more latitude with selecting and experimenting with human subjects.

[OK, another digression: researchers got to do the coolest stuff to people in the late forties and early fifties! They got away with all sorts of crazy experiments back then (see Zimbardo’s Prisoner experiment). Ah the good old days…we can’t torture people in experimental psychology the way we used to. Amateur hour is over. Now we leave torture to the professionals: the military.]

The boys (or subjects – see how scientific that sounds?) were carefully screened for selection for this summer camp. They had to pass a battery of psychological tests and meet specific criteria in order to take part in the experiment. The goal was to select from a population that didn’t have a background of disturbed family histories, large differences in social background or other dramatic differences that might cause confounds in the experimental design.

The first phase of the experiment was an exercise in-group formation. The researchers needed to create some silos in order to test their hypothesis about breaking them down. The boys were taken to campsites and proceeded to play games, go exploring, and generally go about the process of forming, storming, and norming that all teams go through – even teams of 12-year-old boys.

There are some interesting hypotheses that the researchers had about this first phase of the experiment:

  1. That hierarchies will form
  2. That your place in the hierarchy affects your own assessment of your own performance as well as that of others
  3. That members of groups will adopt the “norms” of the group and doggedly stick to those norms in the face of conflicting evidence.

I find these notions very intriguing to us as Agile practitioners. First, I think at its heart many of the Agile methods are rooted in egalitarian notions of communal leadership and are fairly antithetical to the idea of command and control. So, it seems to me that hierarchies, at least the way that I’m used to thinking of them, are generally considered a bad thing from an Agile perspective. This experiment theorizes that given our natural inclinations, the hierarchy is the default organizational structure for people (well, for 12 year old boys anyway). The results support this theory. My gut reaction: that is a major bummer.

Maybe not all is lost though. Perhaps the hierarchy is a default place to start absent any other influences, but evolution can take place. Perhaps it is evolution toward a more communal, collaborative style of group? I don’t know. I’m certainly not an expert in this field, but I find it fascinating and somewhat frustrating that hierarchy seems to be the default choice. Of course, when talking about silos, it’s hard not to refer to hierarchies. They seem to go hand in hand.

The next theory was that your place in the hierarchy would affect how you perceive your own performance and the performance of others. It turns out that we tend to overestimate the performance of those who are higher than us in the hierarchy and to underestimate the performance of people who are lower than us in the hierarchy. So does this imply that we tend to think that the boss is a genius and that the people who work for us are idiots? Ouch! Sherif and his researchers tested this and found that indeed, we do tend to overestimate the abilities of those higher up in the pecking order and underestimate the abilities of those beneath us. Keep that in mind the next time you are talking to the boss!

Finally, the members of the group came to “normalize” their assessments of conditions to match those of the group they were in. So independently, you might tell me that you prefer green, but if the group prefers blue, then guess what? You are going to start reporting that you prefer blue too. It’s all part of fitting into the group. One interesting observation was that members of a group frequently reported themselves as “working harder” than outside groups – even when there was no evidence to support this claim. I’ve certainly seen plenty of that when working with high tech groups and teams.

The rest of the study is equally, if not even more fascinating in its theories and its conclusions. This research, whether or not you agree with it, has some profound things to say about the way that human beings work in teams – and the dramatic effect teams have on our individual judgement. I found many parallels in the study with the teams that I have worked with (agile or not). It’s dry, academic stuff, but if you are at all interested in the way that teams form, fight and resolve, it is pure gold.

Lifeguard Hand-offs

April 25, 2011

So there we are on vacation at the water park. Life is good – the kids are playing and there are lifeguards are everywhere. The guards are pacing the sides of the pool, whistles at their lips and their heads are swiveling back and forth like deranged bobble head dolls. My wife pointed out that they had a curious ritual around the process of relieving the on-duty guard with the next lifeguard to go on. It went something like this:

  1. The new lifeguard approaches the one on-duty (currently pacing relentlessly back and forth) and greets him/her. They start a dialog and now they are both pacing the edge of the pool, side-by-side.
  2. The on-duty guard carries on the dialog while pointing with one arm at various locations around the pool. The second lifeguard mirrors the first, pointing everywhere that the first guard does without exception.
  3. They continue this action: pacing together in lock step, talking about what they are seeing, and pointing it out to each other for about 15-30 seconds. Then the original on-duty guard lowers his/her arm, says a polite farewell, and heads off for their break – or whatever it is that lifeguards do in their off time. The new lifeguard is now fully oriented and pacing about just like their predecessor.

It really is a remarkable passing of the baton. The routine is very disciplined. They do it the same way every single time – no exceptions. Now, I don’t know anything about how lifeguards work, I imagine this is a well known practice that has been around since the beginning of time. However, it did get my process geek aroused! Fortunately for the lifeguards, I was too busy making sure my own children didn’t drown to hassle them with idiotic questions about how they do their work. However, I was intrigued.

Here is what I was thinking: Where are the hand-offs in my work, and do I manage them as well as the lifeguards do? It seems there are a couple of places where there are some interesting opportunities for improving hand-offs:

  1. Pair programming – In general, the teams that I work with do pairing in limited sessions: anywhere from 1 hour to 3 hours is common. But as far as I know, the sessions are treated as fairly atomic. When we are done we are done, we don’t hand off the work. What if we did? What if there was a new developer who merged into the pairing session the same way that the lifeguards did and then one of the existing developers dropped out? Could we sustain the development pace better?
  2. Coaching – I’ve been in coaching engagements where we are facilitating a marathon brainstorming session with multiple coaches. What would it be like to use those lifeguard style hand-offs instead of the “everybody in the pool” approach that I have used so often in the past? Would coaching be more effective if there were a pairing with explicit hand-offs? I imagine there are people who do this already – I’d like to learn more.

Of course a change like this would have to have some sort of payoff. One would hope that the customers would get some sort of value from developers smoothing out the hand-off of work. If nothing else, I’m sure it would make some interesting experiments for an intrepid team.

Finally, we just might find that there really is no application for these kinds of hand-offs in our work at all. Perhaps the work is just too different. Watching for drowning children is dramatically different than software development – mostly. Perhaps the point of this little essay should be that we need to keep looking. I remember when Arlo Belshee gave his acceptance speech for the Gordon Pask award. He said that we always need to be restlessly seeking how other disciplines do their work. He maintained that there is a wealth of great things we can learn from what other jobs might cast off. So keep an eye on those lifeguards, there might be something really cool we can learn from them – in fact I’m quite sure of it.

How Others See Us Is Important Too

April 24, 2011

I was having a conversation once with an executive sponsor who was frustrated by friction between competing organizational silos. One silo adopted Agile, the other stuck with more traditional plan driven development. Each side mocked the other’s “head in the clouds” or “lost in the past” approach to projects.

When I was asked what I thought about the situation I found myself saying something along these lines,

“We (the Agile teams) have become very good at being open and collaborative with each other. We have created these marvelous cross-functional teams and have done a great job of breaking down the walls that used to exist between team members. From an insiders perspective on any given team we have made dramatic improvements to the way we work.”

“However, from the outside we don’t look that much different. In fact from the outside, we still react with hostility when provoked and we don’t offer much transparency into our work beyond using a handful of project tracking tools. It’s just not enough. I have high expectations of an Agile development team. I believe that an outsider who works with an Agile development team should come away from the experience feeling like they were welcomed, informed, and energized. I want a team using plan-driven methods to welcome an Agile team, because they will be that much more likely to succeed. The experience will be one of openness and a general willingness to work together.”

“But that’s not often what we get. Instead we get fear, hostility and resentment on both sides. Some of that is human nature. Some of that is silos. And some of that is because we focus too much on the process. I think we should leave the process out of it. Working on a project is a chance to make friends and meet new people.”

“What I need are people who are friendly, open and honest. People who smile when I walk into the room. People I can crack jokes with. If I lead with friendship, I can make more ground than if I lecture them on Agile practices. People should feel at ease when they work with my teams. They should know that they are safe.”

At this point in the conversation I was:

  1. out of my chair
  2. pacing the room
  3. and gesticulating wildly

The first two meant I was feeling emotional, the last one meant I was talking. I was surprised at the heat of my own passion on the topic. In writing it down, it even sounds naive. But here’s the thing: I’ve worked with enough Agile teams to know that they can be real jerks to outsiders…and that is a shame. I would have hoped that all of that vaunted openness and transparency would make that go away, but it doesn’t.

If Agile in whatever form is ultimately to be successful, then both people inside and outside the team need to feel safe and respected. If you are starting a new team, please realize that getting things working smoothly within the team is critical, but don’t forget to look at how your team interacts with others to – in many ways it’s just as important to the success of your team – perhaps even more so.

Doctor My Arm Hurts When I Do This…

April 23, 2011

So we all know how this story goes: a patient goes in so see the doctor and says, “Doctor my arm hurts when I do this… <insert pythonesque gesture here>” The good doctor prods and probes, hems and haws, raises a wise eyebrow and says, “It looks like you’ve got a strain. <Insert byzantine medical root cause here> The arm needs some rehabilitation in order to restore full, pain free function. I recommend some theraputic exercises in order to resolve the issue. Do this <insert another pythonesque gesture here> 3 times a day for two months and let’s schedule a follow up visit.”

So the patient comes back for the follow up visit a few months later and the doctor. asks, “So how is that arm doing?” and the patient answers, “It hurts worse than ever. It’s starting to affect my job.” So the Dr. inquires, “Have you practiced the therapy that I recommended?” and the patient says, “No, <insert lame excuse here>”

So, a team goes in to see the agile coach/consultant/guru/<insert trendy name> and says…

Leadership Practice #3 – Envisioning

April 22, 2011

If you are going to be a leader within an organization, then you need to be able to clearly communicate a compelling vision. The communication part is relatively easy to practice, but the vision part is worth practicing too.

There are two primary mechanisms for team communication that we can practice easily: Speech and Writing. We can practice speech by participating in groups like Toastmasters. We can practice our writing by using tools for text analysis and review.

Both mechanisms have the benefit of providing very rapid feedback and the feedback can contain lots of fine-grained detail. These are two critical attributes of practice. The feedback needs to be almost immediate(the sooner the better) and the feedback needs to be very detailed and specific so that we can fine tune our performance in a meaningful fashion.

When it comes to vision, one reliable place to start is with a clear statement of the problem you want to tackle. Coming up the problems is the easy part: ask the customer, ask the team, ask the project stakeholders. If you get that far you should have a list as long as your arm. Here’s a pro tip: keep those customer problems at the top of the list. Coming up with that list of problems is an important skill that can be honed and refined. There are places that you can go to look for problems that may be hiding in plain sight: recent communications from customers, defects, impediments. Keeping an updated list would be great way to practice.

Now unless you are very lucky, most of your problems will be vaguely stated and unclear. One of the best things to help you clarify the problem is to actually see it and experience it for yourself. Go to where the problem is. In the lean world this is often referred to as “Going to the Gemba.” The Gemba is the place where the work gets done.

Seeing for yourself will give you the rapid, high quality feedback you need to assess the nature of the problem. You can use techniques like The 5 Why’s to help get at the underlying causes of a problem. Often times the refined problem statement that you end up with looks nothing like the problem statement that you started with. Now these techniques are great for refining the problem statement, but what we are really after here is a vision – the possible solutions to the problem.

Fortunately there are a wealth of different brainstorming strategies that you can use to help discover a set of possible solutions. Here’s one technique that I use (taken with some minor modifications from the wonderful book Thinkertoys by Michael Michalko):

  1. State the challenge
  2. List your assumptions
  3. Challenge your fundamental assumptions
  4. Reverse each assumption
  5. Record differing viewpoints that might be useful to you
  6. Ask yourself how to accomplish each reversal

What you end up with at the end of this exercise is a list of potential solutions to your problem. Pick one. Now all you need to do is to communicate it!

The thing that I really want to convey is that many of these techniques can and should be practiced. With practice we will improve our communication techniques and our problem solving techniques. Put the two together and you have the recipe for someone who can communicate a compelling vision.

Getting Attention

April 21, 2011

I heard a story once from Jeff Sutherland about a team that didn’t have a backlog. Their product owner had checked out for one reason or another and the team was left at loose ends with nothing to do. Rather than tolerating this state of affairs, the scrum master decides to send the whole team home! That’s right, everybody go home until we have some work to do. Go surfing! Have a great time! I’ll call you when the company has work for you to do.

Of course, this was a brazen act that caught the attention of the company executives and they jumped right on the problem and fixed it right away. Nobody went surfing.

At the time, I didn’t fully appreciate what was happening in this little story. There is almost no way that I could see myself telling an entire team to go surfing! The absurdity of the idea was just too much for me to entertain it seriously. Now Sherman, let’s spin the dial forward on the wayback machine to a few years later…

I’m on a project that is going down in flames. It’s bad, really bad. Teams encounter impediments that bring development to a complete stop. We can’t resolve them ourselves, and dutifully escalate the impediments to executives for help. We meet with the executives, explain the problems and the proposed solutions…and get nothing. It’s like reliving the titanic disaster. Somebody shouts “iceberg!” and the executive team continues to drive the ship right into the berg. We’re all going down together and some asshat is playing a violin the whole time.

As a scrum master I screamed, I hollered, I made noise. I did everything I could to draw attention to the problem. However somehow I failed. I went over it time after time trying to work out what I could have done differently. I felt like Robin Hood Daffy, “Ho! Ha ha! Guard! Turn! Parry! Dodge! Spin! Ha! Thrust!” …and then there is that bit where Daffy Duck gets the quarterstaff right in the kisser. Every time.

Recently I was dealing with another project in trouble. The backlog was empty. Again, the team and the scrum master did a terrific job of identifying the problem and escalating the issue to management for help. Again, it was acknowledged and ignored. Yes, thank you very much, now go back to work. However, this time, after the first pass didn’t fly I had an inspiration: I announced that if the team didn’t have a backlog ready for them by Friday, then I’m sending the whole team home.

Now, did I actually have the authority to do that? No. It didn’t really matter – everybody completely freaked out! Why doesn’t the team have a backlog? This is serious! The problem was sorted out in very short order and the team had their backlog.

I’ve decided that there is something about the common ways we communicate in some companies that makes us deaf. If you need help you can’t just tap someone on the shoulder and ask, because you will very likely be ignored. Dramatic actions like threatening to send the team home can serve a useful purpose within a company by getting everyone’s full focus and attention on an issue. Something about that kind of drama punches right through our collective apathy. That’s what happened in this case. It required a little boldness, a little courage, and perhaps a dash of mischief, but it got the job done.