On the last several projects I’ve worked, we’ve been using some form of the Scrum methodology, which is a so-called “Agile” software development technique.  The heart of Scrum is that the team develops in one month increments called Sprints, with each member picking items off the big list of Everything That Needs Doing that they think they can personally commit to accomplishing during that Sprint.  At the end of the Sprint, there’s another big meeting where everyone shows what they did, then the whole team adjusts their techniques depending on whether they overachived or underachieved, and finally everyone picks a new set of stuff to do for the next Sprint, and the process completes until the project is done.

Really, there’s a lot more to it than that, but this isn’t a discussion about the Scrum methodology.  Rather, I’d like to talk about a side effect of the Scrum methodology, which is Team Building.  There are lots of ways to build teams, but very few that build effective teams that work well together and actually accomplish the Right Thing On Schedule.  That’s pretty much the goal of a good team, and Joel On Software refers to a team with this characteristics as “jelled.”  Building a good team is never a goal in and of itself, however.  A team is not a profitable asset.  You can’t sell a team (unless you’re a headhunter, or there’s some Software Developer Slavery Ring that I don’t know about), but you can sell the product that a team creates.  If you have a team that repeatedly produces revenue generating products, then you have the proverbial goose that lays the golden egg, and you should never ever give that goose away, or commit Teamicide, effectively killing the goose. 

Some techniques for building a good team involve complicated sociological and psychological methods, where people of certain personality types are put together in just the right recipe, and, like a managerial chef, it is hoped that a well functioning team comes out of the oven.  This isn’t such a good method.  Other teams are built by just putting a bunch of talented people together, and setting them loose on a project in the hopes that they will “manage themselves”.  Also, not such a good idea.  Then there are the teams of one, or teams of two, which really aren’t teams at all, and the project is then at the whim of the ego and whimsy of the individual.  Unless the individual has proven themselves to be a rockstar, these individuals usually have a special name: Consultant. 

So we return to Scrum, with a side trip down the unsurprisingly parallel lanes of the military and fraternity life.  The best way to build a team is to give the team a short, meaningful task, give them the tools they need to accomplish that task, and then set them loose on that task with a short deadline and the requirement of interdependence among the team members.  It sounds simple, but it’s actually quite complicated in that failing to meet every bit of this method will result in a team that is not actually good, cohesive, or prepared for increasing challenges. 

First, an example of what works.  When I was the President of my fraternity chapter, we had weekend projects where we would renovate our fraternity house.  These projects would involve every brother, as a mandatory requirement.  We would decide that it would only be one, or if we were ambitious, two days.  We would have a list of what we wanted to accomplish, we’d let brother pick the tasks they wanted in teams of two or more, and we’d make sure that we knew how to do these tasks, or at least knew how to find someone who knew how.  At the end of every work weekend, we were exhausted, but we were also amazed at what we had accomplished.  In addition, we were closer as a brotherhood, because we needed to work together.  We could all look on our house and know that it was better than it had been just two days earlier.  We had increased it’s value, every time, undone wear and tear, and made the whole place look better.  We had done it, together, as a team, learning each other’s strengths and weaknesses, and building all of us up as both individuals and team members.  And as a result, our next project ran more smoothly. 

Now a declaration of what doesn’t work:  Team Building Exercises.  It’s tempting to use so called Exercises to attempt to build a team, but the fact is, it doesn’t work effectively for two reasons.  First, there is no external goal outside of “building the team,” and this leads to an interesting example of psychological game theory.  Second, when there is no real external goal, people realize it’s just a game, and they don’t take it as seriously as if there is a “real project” on which to focus.  When the goal is simply to build an effective team, people will fall into arbitrary roles as leader or follower because they want to give the appearance that things are running smoothly.  There’s no strength they can draw on to complete an external task, so there’s no exchange of the leader/follower roles.  One person decides to be the leader, and they usually hold that role for the entire exercise.  Everyone else follows, and voila!  We’re a team!  But they’re really not.  If the team knows that they’re not actually gaining any external skills, or accomplishing any external task, then they won’t take it as seriously, nor will they learn to rely on each other.  There’s no real penalty for failure.  This is why the military has live fire exercises in basic training, and teaches valuable skills where recruits must rely on each other to accomplish their tasks.  When you need to know how to rely on your buddies to survive, and you need to help them out so they can reload their rifle before getting shot, there’s no doubt that you’re not joking around, and teams build up very quickly. 

Which brings us back to Scrum.  Scrum fits all the characteristics I’ve set out for team building.  The one month Sprint cycle results in a short task time.  The task is meaningful, in that during every Sprint, the team must deliver a working piece of the final product.  It’s obvious if they’ve failed, and equally obvious if they succeed: the team can hold up a shiny piece of product and say “we made this!”  On any real world product, there is interdependence, so the team learns who possesses what skills, and how to work together to accomplish their common goal.  They’re not trying to assuage egos, they’re trying to deliver their Sprint requirements.  Finally, everyone decides what they’re going to do, and how they’re going to do it, so everyone feels like they have ownership over their section of the product. 

Scrum works at building teams because it’s a fast iterative process, and there’s rapid feedback for both success and failure.  It works well with our innate Pavlovian desire for quick rewards for good work.  Nothing kills teams faster than a drawn out death march where feedback is rare.  And because a team becomes a great team faster than with other methods, the team gets continuously better at working together, and thus continually better at delivering great products. 

That is how great teams produce revenue, and that is the real value of great teams.