66. Seelenverwandtschaft¹

¹ Ask a German.

The organization allows a particular team to shortcut even the most fundamental rules of its development process.

Here are some of the traits you first notice about this kind of team:

• They revile scheduled meetings, but they hold lots of small, ad-hoc meetings, of which nearly all are—or soon become—design sessions.

• They prefer white boards to other media for writing down ideas, designs, and to-do lists.

• They work from incomplete, high-level requirements statements. They often skip written design documents altogether, and they move on to coding very early in the development process.

• They throw away and rewrite lots of code. As soon as they have demonstrated a feature, they start to rework it.

• They do all of this very, very rapidly. Typical feature development times are one-to-three days. Extremely complex features might take ten days. Many tasks are completed and ready for testing in less than half a day.

This is not a common pattern, but it is so remarkable that it is worth noting. For lack of a better term, we call these “guerilla” teams. They are generally more common in the Agile community,² but some have evolved guerilla behaviors independent of a specific method.

² A good survey of agile methods and their underlying principles can be found in Alistair Cockburn’s Agile Software Development: The Cooperative Game, 2nd ed. (Boston: Addison-Wesley, 2006). Or use www.agilealliance.org as an entry point.

When you come from a conventional software development background, there is something quite disturbing about guerilla teams. They seem almost reckless, but there is just no denying that they make real progress at an amazing pace. They can cause you to revisit your reasons for valuing many of the more formal elements of the software development process.

So many of the things we do in software are based on some basic beliefs, such as, “The cost of finding and correcting a problem escalates radically as you progress through the development cycle.” Therefore, we want to get the requirements (and design) right, as early as possible, and to avoid rework in later phases. There is an even more fundamental assumption at work here: Construction and verification of working software is too expensive to be done many times over; you only get one or two shots per project. While this may be generally true, guerilla teams succeed because they operate outside this generalization. They develop and test code so quickly that they truly can afford to discard vast amounts of it in the course of discovering what it is they need to build.

So, what are guerilla teams good for? Well, version one of a new product for sure, and sometimes version two. These teams are at their best exploring a relatively new problem space and devising innovative solutions for it. Although they can produce very good, very durable code, guerilla teams are wired for innovation.

Guerilla teams are like power tools with no safety devices. They can be amazingly productive or amazingly destructive, depending on how well they are led and directed. They also have some inherent limitations.

Guerilla teams are organic. They cannot be created quickly, and they absolutely cannot be created by mandate. They typically form around one or two compelling leaders. They add members slowly (because their standards are very high) and they remain together only as long as the leader stays. They can be effective for years, but when the team begins to break up, it happens very quickly.

They are inevitably small and co-located. Guerilla teams do not work particularly well with other teams, especially distant ones. Their internal team cohesion is extraordinarily high. This model demands very loose external dependencies. Consequently, they do not grow by very much, they do not relocate, and they do not network harmoniously.

It is important to know when to stop using a guerilla team. Because developers like these thrive on breaking new ground, they typically begin to lose interest in a product or system once it has become established. Guerilla teams rarely stick around for version five of anything. Long before that, you might want to consider transitioning to a more conventional team structure. You will need to find fresh territory for your guerilla teams to conquer, or they will find it for themselves, somewhere else.

A final warning about guerilla teams: Posers abound. Since this model is extremely attractive to developers at all skill levels, many small teams believe themselves to be guerillas, but the real thing remains rare. Before you bet your project on such a team, you need to be sure that you are dealing with Che Guevara, not Che Leno.