Bringing a “teamwork feel” to your projects

When cheering fails

Jenny and I have been thinking a lot about teams lately. Working on Beautiful Teams really focused us on teamwork: what makes teams gel, what causes them to run into trouble, and what you can do to them. So when I got this question recently, it was really timely:

I’ve been working on bringing more of a teamwork feel to our projects for 2 years.  It has proven to be a non-trivial task. Any advice?

Now, just so we’re clear here, I know this guy pretty well. He’s a very good manager, and he runs a software development group with some of the smartest people I’ve met professionally.  They’re definitely a functioning group: they’ve been building software for years, and that software is used in production in critical applications at his company. By many accounts, his group is successful.

But when I took a closer look at how that particular team works day-to-day – and this should seem very familiar to a lot of developers – I definitely saw what he meant about it being a non-trivial task. There’s definitely a lack of a teamwork feel on the various projects his team works on. Everyone is really good at carving out his or her own piece of work, and is able to work on that piece independently. But even when multiple people would work on a single release of the same piece of software, they’d work independently of each other, not really talking amongst themselves. Don’t get me wrong – they definitely get their jobs done. But they’re working on individual tasks, not team projects. And even when those tasks add up to projects, it just feels like loosely connected tasks to the people working on them.

So what’s the harm in that, if they’re getting the work done? Well, for one, having a group of people working like that doesn’t exactly encourage innovation. There are some genuinely brilliant people on that team, and they do reasonably good work, but I would honestly expect more innovative work from this particular group of people. And I believe that having more of a “teamwork feel” would encourage more innovative work.

What’s more, I got the feeling that this particular team still runs into a lot of the same problems that many other, less talented teams run into, and I think those problems could be improved through better teamwork. They have some serious change management issues, where they often have to rework their code because it doesn’t quite meet the needs of the projects’ users. They have a few code quality problems – they’re trying to address them with better code reviews, which they’re having trouble getting off the ground. And they have an overall client relationship problem, where the people they build software for often feel like they’re somewhat disconnected, like they can’t quite the software that really meets their needs. Again, these are highly talented, very smart developers, with a manager who’s on the ball – and they’re still getting stuck on the same problems that hit everyone else.

Now, I don’t want to make the situation sound worse than it is. The manager has made some very good progress in getting the individuals working in a more team-like way. One thing he did that I really like (and I think it worked really well) was to really encourage everyone to write things down in the Wiki. And this wasn’t just a general edict (“Each person must add X wiki pages, or else!”). It was actual encouragement and support, treating documentation like it was a real and highly appreciated part of peoples’ jobs. Like a lot of new tools, there was a slow start to it, but once a few people dove in and started to embrace it, it started to really take off. And a funny thing happened: as people started sharing information with each other, they started to learn more about each others’ work, and some of them started to get that “teamwork feel” that they were looking for.

So what’s going on with this person’s group? And, more importantly, what can he do to help improve the “teamwork feel” for everyone?

Whenever I’m trying to help a group of effective but disconnected developers become a team, I like to start with this great analogy from Watts Humphrey:

There are different kinds of teams. In sports, for example, a basketball team’s positions are dynamic while baseball team members have more static roles. However, in both cases the members must all work together cooperatively. Conversely, wrestling and track teams are composed of individual competitors who do not dynamically interact, although the members support each other socially and emotionally.

In engineering, development teams often behave much like baseball or basketball teams. Even though they may have multiple specialties, all the members work toward a single objective. However, on systems maintenance and enhancement teams, the engineers often work relatively independently, much like wrestling and track teams.

A team is more than just a group of people who happen to work together. Teamwork takes practice and it involves special skills. Teams require common processes; they need agreed-upon goals; and they need effective guidance and leadership.

When I reread that quote before pasting it in here, something in that last sentence stood out to me: they need agreed-upon goals. Now, I’ve been referencing that quote for almost a decade. But it’s really interesting to me that I always overlooked that last bit. But working on Beautiful Teams really taught me the value of agreed-upon goals. It was pretty remarkable, actually: contributor after contributor brought up the idea that the people on a project all need to be aligned to the project’s goals, and to have a single, overarching vision that the team can rally around.

So if I had to give a single piece of advice to this manager, it would be this: try to find ways to give everyone a good sense of their goals. Two different Beautiful Teams contributors – Mike Cohn and Steve McConnell – talked about helping the team see an “elevating” goal. I really like how Steve put it:

First, the team leader needs to establish an elevating vision or goal, and I think that this is truly a leadership function, not just management. It goes beyond the management function. An awful lot of thought should go in on the part of the team leaders into what is the team’s goal and what is it about it that is not just trying to trick the team into thinking they have a goal that’s elevating or inspiring, but to come up with one that truly is.

A classic example is if you’re out digging ditches, that’s not very elevating or inspiring. But if you’re digging ditches to protect your town that’s about to be attacked by an enemy, well, that’s more inspiring, even though it’s the same activity. And so the leader’s job, really, is to try to determine or frame the activity in such a way that people can understand what the value is.

Now, that’s not an easy thing to do. But Jenny and I heard this message (or one similar to it) from so many of our Beautiful Teams contributors – Keoki Andrus, Neil Siegel and Mark Healey all come to mind, although other people talked about it too – that it actually changed the way I think about how teams work. In the past, I always looked at defining a project’s vision and scope as a straightforward tool for setting the top-level scope of the project and preventing changes. One thing I learned was that I wasn’t giving “vision” part of it nearly enough respect. Talking openly and often about that vision – and coming back to it when you do things like discuss project assumptions, come up with scenarios (or user stories, or use cases… however you figure out how your users will use the software) and plan out the work the team’s going to do – is the first step in really getting your team to have that “teamwork feel.”

Beautiful Teams — on its way!

Beautiful Teams - on its way

Beautiful Teams is finally on its way to the printer!

For those of you who have been wondering why our blog posts slowed to a trickle over the last six months, now you know. Jenny and I have been working pretty steadily on Beautiful Teams, and we’re both really happy with how it came out.

Here’s a — well, it’s not really a sneak preview. It’s more like the promo copy we came up with for the back cover:

What’s it like to work on a great software development team facing an impossible problem? How do you build an effective team? Can a group of people who don’t get along still build good software? How does a team leader keep everyone on track when the stakes are high and the schedule is tight?

Beautiful Teams takes you behind the scenes with some of the most interesting teams in software engineering history. You’ll learn from veteran team leaders’ successes and failures, told through a series of engaging personal stories — and interviews — by leading programmers, architects, project managers, and thought leaders.

Looking back over the project, I’m pretty amazed at how much I learned about how teams work — from an incredible group of people, many of whom I’ve admired and looked up to for most of my career. Here are just a few:

  • Scott Berkun wrote a great essay called “Why Ugly Teams Win” — and he did an incredibly insightful interview with Steve McConnell where they talked about the kinds of practices that make teams work
  • Barry Boehm — and his longtime colleague, Maria Penedo — wrote a fascinating story about one of the first software process improvement projects ever
  • Grady Booch talked to us about how he creates a better team culture
  • Karl Wiegers, whose books gave me my first grounding in software requirements enginering, wrote a wonderful story about one of his early experiences with using use cases on a project
  • Cory Doctorow — and, mind you, I think I’ve actually got a paper copy of Boing Boing lying around somewhere! — contributed a story about a team of IP activists
  • Scott Ambler talked to us about the kinds of obstacles teams face, and how he works to get past them

And that’s just the beginning.We have over thirty contributions from people all around the software industry (and a few very insightful ones from people who aren’t in our industry at all!).

Now that I’ve got a little time to post again, I’m sure I’ll be telling you more about the lessons I learned, not just from actually writing and editing the book, but from the wealth of knowledge and experience all of our contributors shared with us. I’ve already started applying that newfound knowledge to my own teams and projects.

Oh, one more thing — my favorite part of the project! Not a single one of our contributors asked to be paid. Instead, they donated their time and considerable expertise to this project. Instead, we’re contributing royalties from the book to PlayPumps International, a truly wonderful charity that digs wells and installs pumps to deliver clean drinking water to rural schools and villages in sub-Saharan Africa.

Happy Kids on a PlayPump Roundabout
Happy Kids on a PlayPump Roundabout

One reason I love PlayPumps is that it’s more than a charity — in a way, it’s a major civil engineering organization in its own right. And PlayPumps does what they do in a unique way: by driving the pumps with merry-go-rounds or roundabouts, which the children in the village play on. Not only does this give them clean water, it also frees up women, who in many villages have to literally spend
their entire day fetching water, often from polluted sources. We had the privilege of interviewing Trevor Field, the founder of PlayPumps, not just because he does great work, but because he does it through great innovation, engineering, and teamwork. That interview is one of my favorite chapters in the book.

Okay, so I hope I was able to write this post without turning it into too much of a marketing piece. Stay tuned, and with a little luck you’ll see much more frequent updates now that the book’s out the door.