Are You a Tweaker?

When I used to race sailboats in Puget Sound I got to sail with a lot of different kinds of people. Some people who like to sail are pretty laid back. The Jimmy Buffet types. You know, “The wind will come when the wind decides to come, and in the meantime, how about a margarita?” I really like sailing with folks like that. They are enjoyable and easygoing and that is important when you are trapped together on a cold, wet, boat for 8 hours or longer.

On the other hand, there was another class of folks that I might categorize as the “Tweakers”. Tweakers are the people who are compulsively changing the boat trim in an effort to get more speed out of the boat. They never stop. They are constantly pulling lines and adjusting the rig in an effort to squeeze every last ounce of performance out of the boat. Tweakers are awesome people to have on a boat when you are racing. A boat full of tweakers will almost guarantee you a win. That is if they aren’t fighting with each other over the things they are trying to tweak.

Personally, I preferred a mix of the two types. Tweakers are indispensable to winning a race, and winning is fun. On the other hand, there are times when frankly, the wind just isn’t going to show up. Tweakers tend to go a little bit crazy when this happens. They go into a veritable frenzy of tweaking. All to no avail. Sometimes what they need is one of the more relaxed folks to hand them a beer and point out that there isn’t any wind today.

Other times, the tweakers are the ones to point out that, with just a bit more effort, we could be in the hunt. Even if we are moving so slowly that our progress is imperceptible. Being in the hunt is fun. Sometimes the tweakers need to give the Buffet Heads a nudge in the ribs to put down the beer and get going.

So which type do you have on your team?

On Product Ownership

Recently I’ve been dealing with disengaged product owners. You know the type: they don’t show up for the stand-ups, when they come to the standup meeting they don’t bring any stories and instead simply review whatever the team has brought to them – and then leave early because they have more important things to do. When they show up for the demo, they obviously don’t recognize the stories and simply give tacit approval to the work that the team has done. And the scrum master marks the work as accepted. The only time they express any opinion about the project is if it is late. Otherwise they are off in other meetings for projects that seem more attractive to them.

Call me a jerk, but these are the product owners that I least like to deal with. I almost prefer an actively hostile product owner – at least then I know that they care! Instead these ghost product managers do nothing to engage the passions and the commitment of the team. Soon I find that the team is coming to me and saying, “We don’t see much value in the work we are doing…” This is a very bad sign for a team. When you hear this from a team you can rest assured that you have a product owner who at best is distracted or at worst just doesn’t care.

Of course part of the problem is that I just haven’t worked with that many really good product owners. I think they are a rare breed. However, I saw something the other day that gave me pause. I was watching a coordination meeting for a big program that was getting started. The meeting was being run by a talented facilitator and there was a very charismatic product manager who was conveying a very obvious air of “being in charge”. You could tell that he had an ego the size of Texas. He was comfortable with public speaking, he used terms that were dramatic and conveyed a sense of purpose and commitment. He also conveyed the sense that he was confident an knew what he was talking about. People would defer to his knowledge of the business domain. He was brash, arrogant, had a full head of hair, and I almost instantly despised him. I know that type of guy all too well. He was just like me – with hair. What a jerk!

I saw him again a couple of months later and he was still selling the hell out of his program. I remembered thinking to myself, “Does this guy ever quit?” There he was in front of the team. He was basically reaffirming the value of the product that they were all trying to deliver. He was still selling the heck out of it! At the time I’m afraid I must confess I did not recognize the value of what he was trying to do. It all seemed a bit too “high school cheerleader” to me. So instead I settled for quietly loathing his presence.

So lo and behold, there I am a month or so later working on my own program. And I don’t happen to have a product owner who is charismatic, energetic, or at least has a face. No, instead I’m working with some guy I’ve only met once who lives on the east coast and who has not shown up for a planning meeting in recent living memory. The project is stumbling along, like many of them sometimes manage to do. Schedules are slipping, impediments are being worked around rather than being resolved, and we all pray for the day when we get to work on another project. And then it hits me.

I need to sell this baby. Well, somebody does anyway. It’s probably more suited to the product owner’s role, but in their absence somebody’s got to do it. Otherwise this project will just quietly fade into obscurity. Perhaps it should be put out of it’s misery. If you can’t get the product owner to care, then maybe the best thing to do is to let it die. But there is another school of thought here. Leadership on projects is not always clear. By that I mean that sometimes the product manager is a strong leader, sometimes the project manager is a strong leader, and yes, sometimes that giant dork, the development manager is a strong leader too. Sometimes, but not always. In fact the chemistry has been a little different on nearly every team that I have ever worked on. The fact is that the leadership may be hard to find, it may lie in different, even unexpected places – but it must be there somewhere.

One thing to keep in mind is that your leadership needs are going to vary based on the size of the group you working with. If the project you are working on is a nice little single team project with just a couple of iterations to it, then you probably don’t require much in the way of overt and active leadership. In that case it’s probably enough for the team to be well functioning and trusting each other. The commitment is small enough that it doesn’t require any particular skill of vision or any additional requests for re-commitment. The value of these small projects is often small enough that everybody usually feels that they are easily achievable and they don’t require much additional motivation to achieve.

Then there is the more complicated project, really more of a small program. These projects might have two or three different phases, milestones or releases to them. They generally take longer than your typical individual project and they require more commitment on the part of the organization and the team. The added risk and uncertainty, simply due to that introduced by the increased scope and the concomitant unknowns make these projects more worrisome to all involved. We’re not talking major fear, uncertainty and doubt here, but we are talking about the kind of program where, with just a few things going wrong, the mood can swiftly change from, “We think we can do this” to “We’re all going to die!” These are the types of projects that require someone, an engaged product owner – someone who will consistently paint a clear picture of the overall goal and help the team understand and appreciate the value that they are delivering to the customer and the organization. It may not take all that much, and you may even find that you can get away without it, but like I said, it’s much more likely in these situations that you will find that life goes a lot smoother with someone who is willing to actively rally the troops.

Finally, there is the genuinely large program – to me this is any program that has 3 or more teams, each of whom has multiple overlapping milestones that they need to hit in order to deliver the program successfully. Often times these teams are also distributed/dispersed teams as well. These are the programs where you need one hell of a good salesman. You need someone who is good at bringing people together and helping them feel like they share a common goal. Someone who is good at working with large groups of people – this can’t be the kind of person who will shy away from a room filled with 50 people. They need to be fairly energetic and be able to tell a compelling story. And they need to know the business really, really freakin’ well. They have to have some sort of very real respect within the group. For the really big programs, you probably need more than one person like this. Or maybe not. When I have worked with the multiple leader scenario I have also see a lot of infighting, which can be death for any project, large or small.

These are just some observations and speculations. They aren’t based on any kind of empirical data. To a certain degree they are based on observations of things that I have seen missing in myself as I work with teams. They are also what I often need from a product owner. Teams really need leadership as much as anything else from the product owner. However, leadership is one of those intangible skills that is very difficult to impart in some sort of training class. Certainly it is not the kind of thing that you will find in any sort of product owner certification course. The point is, I think teams need it from the product owner, some more than others, but they all need it.

Of course I suck at things unless I find some sort of way to formalize it into a set of things that I find easy to remember. So how would I formalize what I am asking for here? First I would bring back a much stronger emphasis on the project kick off meeting. This is the first opportunity to sell the project/program to the team and it is very important that you do it well. Second, I would put together regular status updates with the group, perhaps along the lines of key milestones that would serve to bring the group together and reinforce that original commitment to the project. Finally, I will treat impediments very aggressively and review them with the product owner and make sure that not only are they aware of them, but that they are taking an active role in resolving them as well. The team needs to see that the product owner is just as committed to removing project impediments as anyone else – perhaps more so.

Breaking Down Silos

In the first two stages of our story of the Robbers Cave experiment we have explored how in-groups or silos are formed and how they can come into conflict. In the final stage of the experiment we learn how Sherif and his fellow researchers attempted to reconcile the conflict and defuse the tensions between the two groups. The third phase really gets at how we resolve conflicts between different groups. Everything else done in this experiment up to this point has been a setup for this phase.

The first thing to note is that the researchers considered a variety of different possible solutions that they could bring to bear in attempting to resolve the conflict between the two groups. As they outline it, they saw the following options:

1. The appeal to a “common enemy” – when the study was first performed in 1949 they had used this appeal to try and bring the two groups together, but they were not satisfied with the results. They felt that using a common enemy as a tool to bring two groups together only serves to widen the conflict by introducing conflict with a third party. This sort of defeats the purpose of the study. The groups stop fighting each other only to start fighting with another.
2. Disintegrating the two groups by focusing on the “shining” individual – This usually occurs at the expense of other individuals and the researchers felt that anything that brought about the disintegration of the groups again defeated the purpose of the study. The porpose of the study was to look for a way to defuse the tension between the two groups without destroying either group.
3. Using “leadership” as a tool to bring the two groups together – The researchers felt that this approach would not work. They felt that leadership, while important in starting off a conflict, is really too weak a force in the social dynamic to have a significant impact on the direction of the group once the conflict really gets going. They felt that appeals to leadership would be ineffective very quickly after the groups came into conflict. In essence, leadership may influence the initial direction of a conflict, but once that steamroller gets going, leadership is too weak a social influence to stop it.
4. Introducing common superordinate goals – goals that are important to and shared by the two groups but cannot be achieved by either group on its own. This is the option that they chose to test as the primary mechanism for resolving the conflict between the two groups.
5. Contact as equals – this theory is that if the two groups can be brought together into contact with each other in situations where they are equals, that the contact alone will help to reduce the conflict between the groups.

It was the last two methods that the researchers resolved to put to the test. The Sherif and company didn’t seem to have a lot of faith in the Contact as Equals idea, but they felt that it was commonly held and practiced enough that it deserved some consideration. With that in mind, they setup multiple pre-arranged contact situations for the teams and looked to see if there was a significant change in the tensions between the two groups. Long story short – no. In fact, the researchers felt so strongly that this wasn’t the right approach that they set a hypothesis for this stage that stated:

“It is predicted that the contact phase in itself will not produce marked decrease in the state of tension between the two groups.” p.160

I guess that means that getting people from competing groups in the same room isn’t enough. Even if you do it a lot. The researchers in the Sherif experiment did, and apparently it had no effect – as predicted. So they didn’t have a lot of faith in this approach, but they gave it a shot.

The approach that they really liked was the solution that employed superordinate goals. As they put it in the study:

“When groups in a state of friction are brought into contact under conditions embodying superordinate goals, the attainment of which is compelling but which cannot be achieved by the efforts of one group alone, the groups will tend to cooperate toward the common goal.” p. 161

To test this hypothesis the researchers arranged for the following kinds of challenges:

1. The Drinking Water Problem
2. The Problem of Securing a Movie
3. Campout at Cedar Lake
4. Tug of War Against the Truck
5. Meal Preparation
6. Tent Pitching
7. A Trip to the Border

I won’t go into the details of each story. A couple of things are apparent from this experiment. First, you can’t just do this once and have everybody walk away happy. Finding a single superordinate goal is not enough. I’ve seen this in practice too. I’ve been in situations where there were teams/silos in conflict and a situation arose where there was a superordinate goal. Everybody worked together to solve the problem, and then they went right back to their problem behaviors when the goal was resolved. What we see here is that their needs to be more than one superordinate goal in order for lasting changes to be made. At least that’s my hypothesis.

In the end, the two groups are reconciled. They become so tight that they start to blur the lines between the two groups. Rather than avoid each other, now they insist on including each other in activities. They even go so far as to sacrifice things so that they can include others from the previous “enemy” team. It’s a dramatic example of breaking down silos.

Dueling Silos

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.

Forming Silos

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.

How Others See Us Is Important Too

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.

Passion vs. Practices

I’ve been doing a fair amount of reading lately on the topic of deliberate practice. There is a sizable body of literature emerging with a lot of interesting things to say about how we can improve the way we practice. As I’ve mentioned before, in the software development business, we’ve really become quite obsessed with the notion of practices and what they can do for our projects. All good stuff – there is a lot of valuable learning to be had there. However, what is it that drives us to practice?

I’ve seen a lot of teams adopt various and sundry practices. Sometimes it sticks and sometimes it doesn’t. Why is that? You introduce agile practices to one team and they take off like a rocket! And another team just keeps plugging along doing the same old stuff…now with iterations. Ugh! So why is it that one team seems to benefit and the other doesn’t? Often times I think it comes down to passion.

What is it that distinguishes a great pianist from a mediocre one? Passion! It’s that drive that keeps them constantly seeking to improve their skills, to push themselves and their teams. But what do we do when we coach these teams? Well, all too often we teach the practices without the passion.

Teams – Tag, You’re Us!

I was in my brother-in-law’s office the other day. He’s a former Marine and on the walls of his office are various and sundry decorations and plaques. They’re on the walls in his office, the hallways, the garage, the bedroom – in short, they are everywhere. I’ve seen it all before and in my ignorance all I thought was, “Military dude” and never gave it another thought.

This day was different though. As I looked at the plaques I saw for the first time the same name repeated over and over, it was the company he belonged to (or some such military beast – I’ll confess my ignorance of all things military up front). In addition to the name of the group he was part of, many of the plaques contained the signatures of the members of that group. It reminded me a bit of a high school yearbook, signed by all your buddies. At that point it hit me – this guy was part of a really tight team.

Bear with me here – I know that last sentence sounds like one of the all time great statements of the obvious (hey, everybody has a super power – stating the obvious seems to be mine). Here’s my point: great teams tag their members. I get the term “tag” from John Holland (Hidden Order: How Adaptation Builds Complexity). In his book, he describes the essential characteristics of complex systems in nature. Frankly, a lot of it is over my head. But there is one part that discusses the ability of actors in a complex system to “tag” one another. He describes this property of tagging as critical for complex adaptive systems. Tagging enables them to discern important differences and to create order out of chaos. Teams are chaotic. Software teams are *really* chaotic. Last time I checked (on TV), war was chaotic too. So this notion of tagging struck me as important. How important was not clear to me. That is until I saw my brother-in-law’s office. Each one of those decorations on his wall reinforces the message, “This is who you are.” Tag! – you’re us.

Wow.

You see tags in all sorts of strange and wonderful places. For example: some asshole “tagged” my fence where it adjoins the street behind my house. He spray painted a slogan that I can’t even begin to decipher across roughly 10 feet of fence. I guess somehow that makes my fence part of his ‘hood.

Another example: I worked at Aldus in the early nineties. One of the innovative new product teams went out and bought themselves letterman’s jackets (The PressWise team: a.k.a. “The Wise Guys”). You know the kind I’m talking about – the nice colorful jackets that the jocks wore in high school with a big letter for whatever varsity team they were on? You saw a group of those guys wearing those jackets and what did you think? Assholes? Perhaps, if I’m honest I remember thinking, “I’ve got to get one of those!” In our peculiar little geeky corner of the prepress software world, those guys were tight. It worked. Tagging in action.

A final example: I remember the very first product that I delivered from concept to customer. On the day we shipped, the team gave me a box that was signed by every member of the team. I still have that box. That box means a lot to me (sniffle…). We gave a box to every member of the team and it was proudly displayed on their desk. Of course these days we don’t deliver “shrink wrap” software as much as we used to. It’s all on the web. So where do we keep our box? How do we identify ourselves as part of the team?

How do you know you are on a good team? Well what sort of tags do you have to mark yourselves? How does the team mark you to indicate that you are part of the group? After looking at my brother-in-law’s office, I think we could be doing a lot more tagging with our software teams.

To be perfectly clear, there are a lot of teams out there that we software geeks can learn a lot of valuable lessons from. I don’t mean to trivialize a squad of marines by comparing them to a bunch of pale faced, bespectacled software guys trying to support a gaming habit – but I see a lot of things we could learn from the military in terms of creating really tight teams. Given the complexity that software teams attempt to tackle, it may be essential.

ps. Mentioning my brother in law may have been a mistake. He may be forced to kill me. Sorry Dana. In my own defense, it seemed like a good idea at the time…

The Agile Meatgrinder

Have you ever looked at a really high functioning team and asked yourself, “Hmmm…I wonder what they would look like if they were sausage?”

Yeah, me too.

So, since all of us capital ‘A’ Agile types are really just wannabe chefs (and interior decorators) I would like to offer up a recipe for making a complete hash out of an agile team. I prefer a three stage approach that almost always works:

1) A pinch of Multi-tasking
2) A dash of Failing to address impediments
3) And a hefty helping of Increasing pressure on delivery

These three strategies are the secret ingredients to transforming a normally healthy team into a big steaming pile of chorizo. So let’s get started!

First things first: Multi-tasking (tenderize)

Multi-tasking has been much maligned as a hindrance to a well functioning team. The beautiful thing about multi-tasking is that the damage you do to the team is mostly invisible. When a team is multi-tasking, there are no idle hands. Everyone is working away like mad. How can that be anything but good? Nothing is quite as satisfying as the loud “Crunch!” a team makes when it hits the productivity wall head first.

Impediments not addressed/resolved (stew)

Even with multi tasking, I’ve noticed that teams can keep a fairly high morale (at least until the “crunch” hits). Especially tough teams need to be softened up a bit – the best strategy to wear them down is to fail to resolve impediments. Keep track of Impediments. Make them visible to the team – you want to remind them every day that the things that are holding them up are not being addressed. At all. There’s nothing like making it clear to a team that you, and the rest of your organization, really can’t help them in any meaningful way to achieve their objectives. If you listen very closely you can actually hear a team start to fry. I smell bacon!

Increasing Pressure on Delivery (bake at 425)

Now, in my experience, all the really great recipes for disaster call for the use of a pressure cooker. Here is where we really stir things up and heap on the pressure. There are 3 key strategies that I use to turn a team that is spinning like a top into the ultra high speed centrifuge from hell:

1) More metrics – on agile teams we like to call this “transparency!”
2) Focus on “productivity” over removing identified obstacles (see Impediments not addressed above)
3) More status reporting – even more “transparency!”

Agile teams are total suckers for this “transparency” thing. You simply crank up the metrics that the team is required to report, increase the frequency that the team has to report status, and then tell them they aren’t productive enough. And you do it all in the name of “transparency”. Be sure to remind them of that from time to time. Agile teams fall for this ruse like cattle in a meat packing plant.

Feeds 7 plus or minus 2.

Bringing Performance to Light

In the Tipping Point, Malcolm Gladwell talks about a phenomenon called Fundamental Attribution Error. Basically, FAE is attributing success to the wrong things. His point was that we often fail to take context into account when making judgments. He gave an example of a study where subjects were asked to judge the performance of two basketball teams, one playing in a darkened auditorium and the other under normal lighting conditions. The subjects were asked, which team is better? The answer: the team in the well lit auditorium of course.

The only difference between the two teams was the context (lit vs. unlit). Both teams were equally skilled, but the team playing in the dark missed many more shots. That led me to ask myself, “Is my team playing in the dark?”

The context that software development teams work in has a profound affect on how they perform. I’m not just talking about physical context, but also the culture, the technology, and even their social context. I suspect that there are many fantastic teams that are working “in the dark”. It’s our job to turn on the lights.