22 September 04 - 16:20Engineering Effective Teams

If you manage software efforts, you are today facing a broader range of choices than ever before. Should you move work offshore, keep it all on one site, or distribute it across several offices? Current technology makes any of these possible but it doesn't provide the wisdom to choose effectively.

Recommendations about team composition tend to focus on an amorphous, aggregate model of the team -- "a team of five with a skill set including Java and UML" -- which served well enough in the past. Using this model, it may seem that offshore or distributed teams are a clear win, providing cost savings or more efficient use of personnel scattered across offices. But does such a model address the design considerations that matter in organizing knowledge work?

Extreme programming recommends having all team members in one room, customer included. This is a deliberate design choice, made in awareness of several factors and dynamics that apply in this situation. Consider, for instance, "overhearing," and what Alistair Cockburn calls information radiators. Consider as well how these methods trump more formal communication processes in a particular situation.

When a group of people pursuing the same overall goal are both colocated and shielded from interference from people not part of that overall purpose, they tend to be effective at acquiring information by overhearing. They are not disturbed by conversations taking place around them: the topic of these conversations is what occupies their own attention. But they will often pick up cues from these neighboring conversations and offer to help if someone is having trouble in an area with which they are familiar, even simply interjecting an observation that helps others make sense of the issue being discussed. Overhearing lets people share critical information in a timely and efficient manner, at practically zero cost or effort.

In the colocated situation, information radiators play a related role. These are conspicuous displays on the walls of the room of frequently updated information that reflects critical aspects of the software efforts. Good candidates for inclusion include number of defects, status of the most recent build, results of running test suites, risk of missing a deadline, and so on. Unlike information published on an intranet, these are constantly "in the team's face." Information radiators are hard to ignore, giving them a psychological impact out of proportion to the effort spent in publishing the information. A particularly notable result (failing many tests at once, for example) reported on an information radiator is likely instantly to elicit conversations among the team and mobilize the best of their skills toward a resolution.

These two effects and many more contribute to the effectiveness of information sharing and thus to the effectiveness of the project when the whole team sits in one room. In a distributed team situation, there is no single, easy, "standard" solution like putting everyone in one room, which at a single stroke achieves all these effects. We have to hunt around for bits and pieces. The structure of such teams is a complex design problem, with opportunities for mistakes that can easily wipe out the expected benefits suggested by the aggregate model.

Some team functions can be transposed relatively easily to distributed situations. The mailing list is a fairly good equivalent of the conversation dynamic; its nearly synchronous nature promoting intimacy, exploration, and so on. It even has something that face-to-face communication lacks: a memory. It does lack a number of aspects that are present in face-to-face communication, however, such as "meta" information about how people feel about the conversation, conveyed in facial gestures, intonations, and so on.

Other functions, among which I suspect are those provided by the overhearing and information radiator dynamics, may not transpose literally to distributed situations. For instance, consider the feature of some search engines that list keywords that people have recently submitted. That would be, for many software development contexts, a better transposition of "overhearing" than is the more literal transposition often attempted, at much greater cost, with speakers, microphones, and Webcams. What is important is not so much seeing and hearing colleagues as knowing what is on their minds and what has most recently grabbed their attention.

New technology is making the problem of designing effective teams more complex, not simpler. Don't be misled by oversimplified models into making choices that might turn out to be unprofitable. Do consider the design of your software team as one of the high-leverage choices for the project's success and plan to give it appropriate attention.

(Originally published in Cutter IT's "Email Advisor" newsletter, Sept. 15, 2004)

- Management - No comments / No trackbacks - § ¶

21 September 04 - 13:28Hiring Technical People

No amount of process can make your project succeed if you have hired the wrong bunch for that particular effort.

Johanna's book on hiring techies is out - get it from Dorset or Amazon. If Johanna's blog is any indication, the book will provide you with condensed and practical wisdom on the mechanics and principles of effective hiring - and much more besides. You will still have to deal with the complex job of creating a smooth team, but you will be in a position to avoid dozens of stupid (and all too common) hiring mistakes, any one of which can sink projects.

- Management - No comments / No trackbacks - § ¶

10 September 04 - 12:51Power naps

I am freshly woken up from my occasional afternoon nap. My brain woke up before I did. I often hit the Snooze button for an extra five minutes of sleep - this time an idea occurred to me - about a topic for a workshop submission at the SPA conference, the deadline to which is today. It developed into a full-blown train of thought, and before I knew it I was getting up, stretching my legs and turning off the alarm clock feature on my cell phone, ready for the keyboard.

For the past two years rather sporadically, I have been taking "power naps", so-called - very short stretches of sleep at the ebb of my energy cycle, which is usually shortly after lunch.

The main reason I started taking naps is that for a parent naps can have survival value; my wife and I tended to nap - from exhaustion - when the baby was having his. The reason they have remained sporadic is that it's a habit that's too easy to fall out of; and power-napping isn't at all the same as taking a long (1 hour or more) nap because the alternative is spending the rest of the day snapping at the other kids. It's supposed to be a discipline for mental focus, which is my main interest in it. For a while I toyed with the idea of researching the topic, and even of proposing a workshop on power-napping to a conference. (AYE could be a good venue.) I never did figure out how to solve the practical issues of such a workshop, which are... interesting.

For today, I'm content to have gleaned the following insight - you know it was an effective nap when your brain wakes up before you do, and it's the buzz of fresh ideas which pulls you out of your sleep.

- Private Life Of The Brain - one comment / No trackbacks - § ¶

02 September 04 - 12:39The purpose of testing

I was recently reviewing a PowerPoint presentation on testing for a colleague. One slide said: "The purpose of testing is to find bugs." Wrong, wrong, wrong.

Actually, the presentation didn't quite say that. The first such bullet point said "to find bugs in the product before customers do". (The next slide did baldly state "the purpose of testing is to find the bugs".)

The purpose of testing is not to find bugs - finding bugs is a fun thing to do, but it has no economic justification in and of itself. The purpose of a software effort is to create value; the purpose of testing is to support that larger purpose.

My experience with software - in programming, mostly, but also to some extent in maintenance and testing - suggests that testing supports the main purpose of software efforts in two ways. First, testing creates opportunities to remove software defects - "testing finds bugs", in other words. Second, and much more important, testing provides information about the software and the process of creating it.

That information can be of an economic nature. A more valid "purpose of testing", as the presentation also suggested, could be the following: to determine a break-even point computed by subtracting, from the expected revenue from the software, the cost of releasing the software to the field (in support costs, sales lost to a reputation for poor quality, etc.) or the cost of further testing the software (and removing the defects which cause the other category of costs).

One problem with this way of framing what testing does is that the information could come in too late to do any good. The information obtained might be along the lines of "we don't know how much more testing we need to do, but we do know it's likely to take us until later than the competitor's release, which will make our own project a loser because of time-to-market advantage".

Testing can provide information of a much more valuable sort, however: it can tell us how the defects are being put into the software in the first place. Such information about "defect injection" can make more of a difference than efficiency of "defect removal". It doesn't take much thinking to see that the fewer defects you write in the first place, the less costly it will be to fix the defects.

Seen primarily as a way of figuring out how defects come to be put into your software, "testing" also becomes easier to reconcile with what Extreme Programming and other agile approaches advocate. Automated tests detect defects early and thus provide better information about how defects appear. Involving the customer and the QA team early in the effort, and throughout, result in better information about what to call defects, and why they come about (including misunderstandings about the requirements). Software teams that obtain early and continuous information, and construct adequate theories, about how their software might go bad, are more effective at producing good software.

That is why I would much prefer the following definition:

"The purpose of testing is to provide information leading to adequate models of defect injection."

- Testing - ten comments / No trackbacks - § ¶