Brainstorming as a practice can seem completely nebulous, and so can quickly devolve into a practice that is completely unstructured. Like any productive practice, it takes a lot of mindful preparation and a lot of structure in terms of dealing with group dynamics and being capable of changing directions when the session isn’t fruitful. Some common questions your participants might be wondering are: What should I say out loud? Who gets to talk? When is it my turn? What if I don’t have any ideas??
I’ve already covered tips for preparation in earlier blog posts. Now it’s time to address those common questions.
What should I say out loud?
I’ll start by stating that I don’t believe that "the #1 rule of brainstorming is that there are no bad ideas." If there’s something you don’t think is a "good idea," AND you have some constructive feedback, i.e., a reason you think it won’t work, a tweak to the idea that turns it into something "good," or an alternative, then please speak up. My basic rule of thumb for this is: anything goes, as long as it’s on topic. Maybe you have an anecdote to share that you think sheds some light, maybe you need to collaborate in a certain way but you don’t have the tools to do so, maybe there’s a feature you particularly like in another software package, maybe there’s a feature you particularly hate.
What’s the point of encouraging such a loose format? The "Ideal Solution." Rather than focusing on what’s "realistically possible," I generally find it more useful to brainstorm on what your solution would look like with unlimited budget and time.
With a good understanding of the problem/scenario, and a master list of features and solution approaches, it’s easier to scale back the list to "must have", "possible", and "wish list if time/budget permit". Some features will be faster to implement than you’d think, while others will take much, much longer. Only your development team can tell you for sure, so don’t restrict yourself to only sharing those ideas that you think can be quickly developed. Plus, if the project implementation proceeds more quickly than expected, you’ll be able to go through your "possible" and “wish” lists to use that remaining budget and time to your advantage.
Who gets to talk? When is it my turn?
Usually, a brainstorming session will begin with a brief recap of the issue at hand to confirm that everyone is at the same starting point. As the "outsider," I find it useful to do this myself to make sure I have a firm grasp of the issue before I start participating in solution exploration. Then I open the floor for discussion. Be polite, don’t yell over each other, but don’t be afraid to jump in. A brainstorming session should be an open forum. Remember: everyone that was invited has something to contribute.
What do you do if one person starts running the whole show or there are quiet participants? Try switching to a round robin approach. Again, as the "outsider," I usually see this type of group dynamic analysis and tactic switching as part of my job.
This dynamic is certainly not a reflection of a group problem, per se. It seems like nearly every group of people, even if they’ve just met for the first time, will have at least one quiet member and at least one member that tries to run the show. As someone who has sometimes been the quiet member, I can tell you that being suddenly put in the spotlight is not conducive to a free flow of thought, or really any thought at all other than "oh no!" The fastest way to get to that "oh no" place is to be called on with something like, "You haven’t said anything yet. What do you think?" As someone who has sometimes been one of the aggressors that tries to run the show, I can admit that having a process ready to more evenly distribute time to other participants is a good thing; it passes the control to someone else without making it about the aggressor. It can be particularly hard for other participants to take the initiative to disagree with or even add to the ideas of an aggressor when that aggressor is also "the boss"; being ready to switch to a round-robin can diffuse that power dynamic before it becomes too much of a brainstorming blocker. After all, the participants were each invited because they have something to contribute, so it’s important that they all have the chance to do so.
A round robin format helps to include everyone. You can choose to start out this way and conduct the entire brainstorming session this way. Sometimes that can aid participants in building off the ideas of others. Or you can choose to switch to this method mid-session if it seems that the dynamic is becoming problematically one-sided.
If the group seems evenly engaged, a round-robin approach can also be applied more informally by periodically putting out a recap of where you’re at and then quickly scanning people’s faces to see how they react to what’s being said; those that seem to dissent or that seem surprised or that just do something other than nod along can then be called on to see why they had that reaction.
What if I don’t have any ideas??
Sometimes the whole room is at a loss for where to even start thinking about the issue at hand. Sometimes the issue is not clearly understood, or it seems like you’ve tried to address the issue in the past to no avail. It’s time to completely change tactics and try something called reverse brainstorming.
In "regular brainstorming," participants focus on discussing and shaping solutions.
In "reverse brainstorming," participants think about how to make the problem as problematic as possible. This sounds counterintuitive, but this method can really help to focus the brainstorming session. By thinking about all the ways they could make the scenario as nightmarish as possible for the users/clients/customers, brainstorming participants create a list of the things that should be avoided. By working through the list and thinking about ways to prevent these nightmares, you can sort of sidestep the block while still moving towards your goal.
Most of the time, in the world of software development, this will help to shape key features of the final product. But it can also help to uncover other issues that wouldn’t have been discussed otherwise, like related policies and signage that will impact the overall user experience.