Stellman: There's no single magic formula to make a team work. One thing that can set the stage for an effective -- even "beautiful" -- team is that team members aren't afraid to fail. A team that's afraid of failure is a team that isn't going to take risks, and risk-taking is how innovation happens. Another quality is trust. If team members trust each other, then when one person goes out on a limb, everyone else won't have a knee-jerk reaction and pull him or her back. Finally, a great team has great leadership.

Dr. Dobb's: Is an ugly team simply "none of the above" or something else?

Stellman: Teams that might be considered flawed -- people who don't get along, problems with the projects or their companies or the world in general, a complete lack of those great qualities that we just talked about -- can still accomplish great things. This was a realization for us because it helped us see that the whole exploration of how teams work and what makes them tick is more complicated than we thought at first. There are lots of contradictions and messiness.

Dr. Dobb's: Can tools alone turn an ugly team into a beautiful one?

Stellman: A good team tool can help a good team be better. But if you've got a team that's deeply flawed, just adding a tool won't fix the problem. At best, it will help you make mistakes faster.

Dr. Dobb's: Can teams thrive in non-agile environments?

Stellman: Absolutely. We've gotten so used to Agile practices like test-driven development, continuous integration, and constant communication between the team and users that we have trouble remembering that a lot of great software was built by great teams before these things had even been invented. Indeed, great software is still being built by teams that don't use agile techniques.

Dr. Dobb's: Why do we see more ugly team than beautiful teams?

Stellman: Because it's very easy for a team to get sunk by its obstacles, and those obstacles come in many forms: people who can't work together, bosses who sink your project, problems with buildings and facilities, bad product ideas that you can't shake. Sometimes they can break up a team permanently.

Every team faces obstacles. It's the nature of working on projects. If a team can get past its obstacles, it bonds them together. Most of the time, unremarkable teams muddle through the obstacles and deliver something. We wouldn't call that "ugly" as much as "plain" -- not beautiful, but not too unattractive, either.

There are definitely truly ugly teams out there. All of us have been on at least one. Maybe it's the one with the boss who yelled at the junior team member until he started crying, or the project that you worked 70 hours a week on only to see it canceled at the last minute. The ugliest teams are the ones with the biggest obstacles that don't manage to get over them. The funny thing is that if the team can figure out a way to get past the obstacle, they have a shot at turning ugly into beautiful.

This is exactly why in our book that we wanted to talk to Peter Gluck who manages software teams at NASA. We specifically asked him about tools and techniques you'd find on an agile project, like continuous integration. He pointed out that their integration process generally involved putting a rover or satellite in a clean room and loading software onto it. That's not exactly something that you can automate and run continuously.

That said, there's a lot in common with the teams and teamwork that Peter described at NASA and a good agile team. The biggest one is that everyone on the team takes quality very, very seriously. That's something that we really credit the agile movement with: making quality the developer's responsibility. In fact, we're really pleased that it's possible to ask a question like the one you asked about whether or not teams can thrive in non-agile environments. Agile practices like test-driven development, continuous integration, well-planned time-boxed releases with high enough quality that they can actually ship, user stories and other agile requirements techniques, and most importantly, constant communication between the team and the users (and, in the best case, bringing the users right onto the team) -- we've gotten so used to these as part of our day-to-day work that we have trouble remembering that a lot of great software was built by great teams before these things had even been invented. Indeed, a lot of great software is still built by teams that don't use agile techniques. As Peter showed us, NASA has some very good examples in its past.

Dr. Dobb's: What's the best example of a software development team you've run across?

Stellman: To be honest, the best team either of us have been on was the team that was just the two of us. We were working on a great project that was interesting, challenging, and, in our opinion, important. We were building software for public health researchers who were studying the effects of herbicide exposure on Vietnam veterans. We had great rapport as a team and with our client, and we got a lot out of working on something that was going to actually help peoples' lives. We built a really high quality piece of software: It was used to do many thousands of calculations (some runs lasted for weeks at a time), and we never had to fix a single bug after the software was released.

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!