Building a great software team requires more than just a good tool, technology, or technique. That's something we learned time and again from the many brilliant people who contributed to Beautiful Teams (O'Reilly, 2009). It's an idea that seems to really fascinate people: that when a team build great software, even the right programming tools or best practices, solid processes or methodologies can't make up for a team that doesn't start with trust and respect (not to mention skill, talent and good ideas).
It seems like such a straightforward idea when you think about it. But it doesn't stop so many of us—myself included, at times—from trying to find the next "silver bullet" tool or technique to help a team in trouble, when really what's going on is a simple failure of communication or trust.
That's the topic of the interview with me that recently ran in InformationWeek Global CIO. It's called Teamwork: It's About Trust, Not A Technique. I was interviewed by Jon Erickson, editor of Dr. Dobb's Journal (and just a terrific guy to be around, especially if you're traveling through India and need to kill time in, say, Chennai Airport or a hotel in Hyderabad). The interview in InformationWeek was edited down; he ran the extended version called Q&A: Teamwork in Dr. Dobb's.
There are two quotes from Beautiful Teams that really come to mind to demonstrate teamwork over tools. This idea—that a team is more than just the sum of their tools and techniques—came up over and over again in Beautiful Teams. We got such great ideas from some really smart people that I wanted to take a few minutes and share those quotes with you, because they really helped change the way I think about software teams.
Jon asked a great question about tools, and it really got me thinking:
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.
Just to give this a little context: I'm a big fan of software tools, techniques, and practices. In fact, the first book that Jenny Greene and I wrote, Applied Software Project Management (O'Reilly, 2005), is all about great practices that you can use on software projects. This is one of the reasons that some of the best open source projects build such high quality software: they bring their teams together using some of the best practices, tools, and techniques found anywhere in the world of software engineering.
But one thing I learned from many of the really fascinating people who contributed to Beautiful Teams is that it takes a lot more than tools to make a great team. I wrote a post on Building Better Software last year while Jenny and I were working on Beautiful Teams. It's called Bringing a "Teamwork Feel" to your projects, and it talks about one of the things that came up many times: the idea of an "elevating vision," and how it can bring a team together. One of my favorite Beautiful Teams contributors, Steve McConnell, put it really well:
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.
(If that's interesting to you, you can read more about it in the blog post.)
The second quote I wanted to share with you has to do with the very common feeling that a team needs a particular methodology—especially great agile methodologies like Scrum—in order for a team to thrive. This came up in the InformationWeek/Dr. Dobb's interview:
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.
This is exactly why in our book that we wanted to talk to Peter Glück, 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.
A great team needs to adapt to their project. A lot of times, we can use tools and techniques out of the box. But sometimes your project has challenges that make it hard to adopt those tools, and the team has to be flexible (or, in some cases, rigid). That's why I love this next quote from Peter, because I think it shows you how a great team can cope with a difficult project that doesn't necessarily work with a purely agile approach.
The heart and soul of agile, in my opinion, has a lot to do with trust and teamwork. If you and your team stay true to those goals, and to the idea that everyone on the team has to take responsibility for quality (and not just push it off on testers or users), you can get great results even if you're not using an agile methodology.
So I'll leave you with this excerpt from our interview with Peter in Beautiful Teams, starting with a question Jenny asked.
Jenny: A question hit me as you were talking about the testing team earlier. One of the big tenets of agile development that both Andrew and I really like a lot is the responsibility for quality that's put on developers, the fact that they're expected to unit-test their own code and that through continuous integration, it gets easier and easier to monitor changes that are made in code. So I wondered, do you guys use any of those techniques?
Peter: I am not aware of anybody using agile development here.
Jenny: Not agile development, per se, but more quality-related activities that are done by developers themselves.
Peter: Yes, we do expect our developers to unit-test their code before they deliver it for integration.
We tend not to do continuous integration. It's more along the lines of everybody gets together, we figure out the requirements and the design for the current cycle, we then produce those modules, unit-test them, and they come together at once.
Andrew: I have a question about integration testing. What you just said reminded me about when I first read about integration in general, back when I was first learning about software engineering.
If you guys didn't invent the term integration with respect to software, you certainly were some of the first to popularize it back in the '80s and early '90s. For those of us purely working on software, where every system in the project is a software system, integration just means integrating modules together. But I'm assuming that when you say integration, you're using the larger, original meaning of the word, where you're integrating the development of the software and the development hardware, too. And if you go back to that meaning, the term unit—as in "unit testing"—had a specific meaning, too. So, is that what you mean by "integration"? Integration of your software with a hardware component within the larger system that you're working on?
Peter: Yes. So, there are two levels of integration. We develop independent software modules, or units, which are pieces that are small enough that a single person or a couple of people can actually get their arms around them and adequately implement them and test them.
Then those come together in our software integration. We put those together, and those get linked together, and then we run some software integration tests on, say, one of our SoftSim test platforms that I mentioned earlier, or perhaps even on a hardware test bed if we have one available.
Then, once the software is integrated and ready to go, it's declared ready by the software manager, and it gets sent to the hardware test beds for certification. It then goes to the vehicle.
One of the phases of the mission is called ATLO—Assembly Test and Launch Operations. That's also known as Phase D, which is just a letter designation for that particular time in the project life cycle. That starts from the delivery of hardware to integration on what you could call the factory floor, although we attempt to do it in a clean room.
Andrew: So, I guess for somebody who when they first heard you say, "We don't do continuous integration" wasn't sure why not, that should explain it. I think it's safe to say that if your integration process involves a clean room, it probably precludes automated integration.
— From Beautiful Teams, chapter 18