Greene - Beautiful Teams

• DRM-free ebooksuse your ebooks across devices without restrictions or limitations

• Multiple formatsuse on your laptop, tablet, or phone

• Lifetime access, with free updates

• Dropbox syncingyour files, anywhere

WE'VE BEEN ON A LOT OF DIFFERENT TEAMS OVER THE YEARS, IN A LOT OF DIFFERENT COMPANIES AND building a lot of different kinds of projects. And over the course of writing books, articles, and blog posts about how to make projects run better, we were always nagged by a question. It always seemed like it was our job to come up with prescriptive "best" ways to run software projects: how to plan the projects, how to build the software, and how to make sure that it doesn't break. But the more we wrote and the more we talked to people, the more we questioned this idea.

We started down that path after writing our first book, which we thought of as a practical recipe book for running successful software projects. We'd done a lot of research, experimentation, and real-world project work over the years to find practices that worked for us: ways to plan software projects, techniques for developers to write better code, and ways to test the software. We took the ones that worked best for us and packaged them up into as lightweight a book as we could come up with. We've gotten a lot of great, overwhelmingly positive feedback about it over the years, and a lot of people have told us that they use it every day.

And that's where things started to go wrong for us.

Ironically, we fell into a trap that we actually wrote about in that book: we started to get a kind of tunnel vision. We saw this particular set of practices as the "successful" practices. We never intended to say that there was only one way to plan out your project, or to estimate it, or to do a code review, or to test the software. But what we found, as we started getting out into the world and talking to more and more software people, is that we were getting pigeonholed. People would say, "Oh, Stellman and Greeneyou're the Wideband Delphi people? I always use that to estimate!" (Seriously, people actually said that to us!) Or, much worse, they'd tell us, "Your book talks about requirements specifications, and I never use them. But I develop software just fine. You must be wrong!"

Practices are cold. Practices are theoretical. You can sit and talk about the virtues of one or another, and have hypothetical arguments about whether they'll work in one situation or another. We've done our own share of arguing about that ourselves, talking until we're all blue in the face about when is the correct time to do requirements gathering and how to make a project more or less agile. Those kinds of things are really where people draw battle lines.

But it's not where the meat of the work happens, honestly. How you make those decisions has an impact on the project, certainly, and sometimes a big one. But it's not nearly as important as who you have on your team: how skilled they are, and how well they work together. That's when we realized that practices are only one aspect of building better software. And although it's the aspect we've spent the most time studying and dealing with, it took us a long time to realize that it's usually not the most important aspect.

So, we started looking for ways to get people to open up about their own projects, and to listen to each other about what they've learned. We put together a talk about best practicesbecause that's what we wrote about and what we knew bestand tried to explain, in as general and non-prescriptive terms as we could think of, how to use them to make your projects run better. We navely thought that people would be excited to hear about what we learned, both in writing our book and in running our own projects. We'd talk about the kinds of pitfalls they'd avoid, and we'd give them the tools to avoid them ("Look, here's one way you can run a productive estimation session!").

It was a disaster. One talk comes to mind as particularly bad, although not too much worse than many others that we gave. We were invited to give a presentation for a brown bag series at a major Internet company's New York office. We started in on the talk, going through the kinds of problems that software teams typically face, and outlining the practices that we found to be useful to prevent them. We could see the mounting boredom and even frustration on the faces of the developers. They were mostly young, the majority under 30, and by the time we were halfway through the talk most were checking their PDAs and laptops. Some people even got up and left. And when we got to the Q &A session at the end, we found out where their heads were. One programmer, a large guy with a long gray beard, challenged us when we mentioned agile project planning: "Agile means that you don't write anything down, you just start coding immediately." Everyone nodded their heads. We tried to redirect that"No, that's not what agile necessarily says!"but it didn't matter. Our message wasn't getting through, and we were clearly wasting everyone's time.

We shouldn't have been surprised that we were met with a lukewarm (at best) reception. After all, we'd sat through our own share of networking activities (project management group meetings, architect SIG meetings, software process network meetings ). And for every one that featured a really memorable talk or discussion, there were literally a dozen that boiled down to an advertisement for a consulting company, or a book, or a professional product or service of some kind, and left us completely cold.

So, we reflected on the criticism about agile we'd gotten at that talk. And to our surprise, we realized that he wasn't wrong to criticize us, even if we disagreed with him on the facts. Yes, the criticism stung at first, and we really had to take some time to figure out why the talk ended up the way it did. But in the end, his criticism ultimately showed us what was wrong with our approach. There is no "best" practice at least, none that we know of that will guarantee success every time. Whether a particular tool or technique works depends on the circumstances: the project, the people, and all sorts of mushy, messy stuff that you just can't quantify or prescribe. Now, that's not to say that we don't care about process. We're not distancing ourselves from the practices that we use and that we write about. In fact, just the opposite: we still use them every day, we still write about them, and we still train other people to build better software using them because they really do workin the right situation, for the right project, and with the right people. But sometimes the way to get something done is to do anything