In my experience, the value in “brainstorming” (thinking of ideas as a group) is that others can vet each idea as it is proposed. Ideas that are fundamentally flawed can be rejected quickly and those that show promise can be further developed immediately. When dealing with complicated systems, few people (if any) have a deep enough understanding to properly evaluate ideas alone. A diverse group is required. It could be done asynchronously as well, of course.
This does require a high level of maturity and professionalism on the part of the participants, however. It is also imperative that there be no “keeping score”, if there are costs to having an idea rejected quickly, it won’t work. This doesn’t seem to be what “brainstorming” originally meant, but it is how I tend to see it practiced.
As I’ve had the original idea of brainstorming explained to me, there’s no discussion of ideas, and no negativity; anything anyone says is written down unless it already has been. Then sorting happens later. It sounds frankly unproductive, but I’ve never tried it in a professional context, only when compelled to, and those were situations where everyone just wanted to appear to participate so that they would be allowed to leave, so… hardly a fair test.
What you’re describing sounds dramatically more productive. :)
Pair programming is sometimes very useful, but I agree that it inhibits leaps. I find it least productive for “routine bugs”.
It really dramatically improves team communication and spreads skills around a team. Its great strength, though, is exactly what this article says brainstorming lacks: everything you write is immediately subject to criticism. This makes everything you do take a little bit longer, but it also means you don’t waste 45 minutes doing something you didn’t need to, or looking for an obvious bug.
It also means that when you’re done, there’s at least two people on the team who understand the code you were working on. Which is rather important, and slips through the cracks a lot of the time.
Agreed, and while you could say that that’s a matter of improving team communication, it’s sufficiently important that it’s right to call it out on its own.
In my experience, the value in “brainstorming” (thinking of ideas as a group) is that others can vet each idea as it is proposed. Ideas that are fundamentally flawed can be rejected quickly and those that show promise can be further developed immediately. When dealing with complicated systems, few people (if any) have a deep enough understanding to properly evaluate ideas alone. A diverse group is required. It could be done asynchronously as well, of course.
This does require a high level of maturity and professionalism on the part of the participants, however. It is also imperative that there be no “keeping score”, if there are costs to having an idea rejected quickly, it won’t work. This doesn’t seem to be what “brainstorming” originally meant, but it is how I tend to see it practiced.
As I’ve had the original idea of brainstorming explained to me, there’s no discussion of ideas, and no negativity; anything anyone says is written down unless it already has been. Then sorting happens later. It sounds frankly unproductive, but I’ve never tried it in a professional context, only when compelled to, and those were situations where everyone just wanted to appear to participate so that they would be allowed to leave, so… hardly a fair test.
What you’re describing sounds dramatically more productive. :)
[Comment removed by author]
Pair programming is sometimes very useful, but I agree that it inhibits leaps. I find it least productive for “routine bugs”.
It really dramatically improves team communication and spreads skills around a team. Its great strength, though, is exactly what this article says brainstorming lacks: everything you write is immediately subject to criticism. This makes everything you do take a little bit longer, but it also means you don’t waste 45 minutes doing something you didn’t need to, or looking for an obvious bug.
It also means that when you’re done, there’s at least two people on the team who understand the code you were working on. Which is rather important, and slips through the cracks a lot of the time.
Agreed, and while you could say that that’s a matter of improving team communication, it’s sufficiently important that it’s right to call it out on its own.