​Brainstorming With Your Scrum Team

While our designers spend most of their day supporting their sprint teams, a large percentage of their time is also dedicated to “vision” work. This is work that’s not in sprint yet, work that’s focused on future features still being fleshed out and explored. By working far ahead, we designers get time for exploration and ideation. They often work in conjunction with other designers, undergoing research, testing and prototyping.

One of the dangers with this though, is ensuring that development staff get visibility on what’s being proposed. Developers hate surprises, so keeping them informed about upcoming projects is essential. To accommodate this, earlier in the year we started introducing sprint-team brainstorming.

Rather than traditional brainstorming sessions, populated by designers, these workshops include the whole sprint team — developers, QAs and of course, any stakeholders. The benefits of these sessions are:

• To give the team insights into upcoming features and concepts
• To get ideas from multi-discipline teams
• To build a unified vision of what’s expected
• To get by-in from as many contributors as possible.

While our UX teams are well-versed in brainstorming, we were concerned as to how people less familiar with the idea would get on. There’s no doubt that including different disciplines generates a greater range of ideas, but we were concerned as to how new participants would get on. Even discussing it beforehand made some people restless. Below I’ll list some of our suggestions for making the process smoother and more productive.

Try to get everyone in the same room

This is either going to be easy to do, or very difficult. But where possible, we highly recommend getting as many people into the same room. When people are together they feel more included and produce more ideas. Seeing each other’s performance also inspires people to perform better. Once people get split between locations communication becomes exponentially more difficult.

We’re lucky enough to have some great teleconferencing facilities here at GF which certainly help a lot. But even then we found that things weren’t understood as well by people off-site.

Once the ideas start being generated, one of the major difficulties we faced is sharing work between locations. If one team produces a great sketch, how do we share that across all three locations? We’ve tried numerous things but we’ve yet to find the perfect solution. I’d be very interested in hearing suggestions from anyone who has overcome this.

Setting the scene

Send out a brief description of what you’re planning about one week in advance. Especially if you want your participants to do some research. It’s also no harm to remind them the day before. People have short memories, and if it’s not on their to-do list, it can be quickly forgotten.

Once the meeting starts, make sure you get off on the right foot. Keep the mood lively and humorous. John Cleese has long extolled the virtues of humour in creativity (http://bit.ly/1xfn9kk) and he’s right. Nothing livens up the mood like laughter.

To encourage this, we often start meetings with a fun icebreaker game. Try bringing in a simple household object. Participants pass the object around the room and each person has to come up with an innovative way to use it. We’ve had people using shoes as phones, hats as ashtrays. The crazier the better. It really helps to break down any uneasiness. Normally if you’re just with your sprint team, people will be very familiar with each other too which will help a lot.

Giving an example

Even the best description of your plans can be hard for new recruits to understand. We’ve found that giving an example of the kind of thing you’re looking for is really helpful. Rather than just describing, take the time to create an example for them. Pick an obvious UI pattern or technique, draw it out roughly and present it. Talk them through your thought process. Describe your sketches. However, make sure whatever you draw is kept rough and loose. You don’t want to intimidate your team. The idea is to not just give participants an idea of what you’re expecting, but to also reassure them that you’re not expecting DaVinci style drawings.

Teams

Once we get started, we’ve found it very helpful to let participants work in teams. This reduces some of the burden for the individual. People don’t feel that they’re on trial as much. We’ve also found it’s a great way of generating fun banter and healthy competition.

Conclusion

Overall, we’ve found this process very beneficial. The teams we’ve tried this with have been incredibly enthusiastic and the results have been inspiring. I’m always amazed at how people from different disciplines produce ideas that I would never have thought of. The only outstanding problem is how we share sketches and ideas across locations but some more research and trials should get that sorted. I’d love to hear how others have tackled this problem.