How To Get The Most Out Of Your Design Sessions

Design sessions is one practice that most agile teams will find themselves engaging in from time to time. For some teams it will be completely informal (just get everyone together for 10-15 mins whenever you think it is warranted), for others it becomes more of a ritual where most non-trivial features get a once-over in a design session before implementation proceeds. There are many benefits to having regular design sessions with your team mates:

an opportunity to share knowledge about a particular area of the system with the whole team

promotes collective ownership of code as everyone has some stake in most non-trivial design decisions

gives an opportunity to brainstorm (brainstorming is not used nearly enough)

an opportunity to identify areas that are potential refactoring candidates

gets everyone more personally invested in the solution

gives people a break from cutting code and gives them an opportunity to engage in an alternative but still useful activity

an opportunity for the team to bond and ‘gel’ further

At least those are all the benefits that a design session SHOULD provide, but more often than not the potential of design session goes sadly under-utilised by many teams. Any sort of design session will provide some of the above benefits to some degree, however our goal as software developers and agile practitioners should always be to get the maximum benefits from all the practices we employ. So is there anything we can do to ensure we get the most out of a design session?

A Typical Design Session Scenario

A typical design session is a pretty informal affair and usually occurs when a pair would like some input from the rest of the team into the best way to implement the feature they are currently working on. When a pair calls a design session the rest of the team gathers in one place (usually in front of a whiteboard) where the team would proceed to outline the problem they are looking at as well as potential solutions that they have come up with. The pair running the session would normally use the whiteboard as a visual aid to help represent the problem and their solution (or solutions).

Ideally the rest of the team would have some insight into the problem and would offer better solutions or critique and improve the solutions that the pair running the design session has proposed. After some back-and-forth a solution that most people are happy with would emerge and everyone goes back to what they were doing before while the pair that called the session proceeds with the implementation.

While there is nothing overtly wrong with this scenario (and many teams would do well to even have that as one of the practices they follow), I believe there are many opportunities lost when a design session similar to the above occurs:

not everyone is an extrovert and since no particular effort was made to engage the more introverted people their knowledge/ideas may go unheard/unused

it takes a while to switch mental gears, since no particular effort is made to snap everyone out of the mode they’re thinking in, interesting ideas/solutions may not occur to some people until long after the design session is over

only visual clues (whiteboard) and audio (verbal explanations) are used to represent the problem and the solution, many people work better with tactile clues (use physical objects to represent the problem), or by seeing themselves as part of a larger abstraction (acting it out)

by presenting a solutions at the start, potential creative solutions are stifled as it puts the team into an analytical mode (analysing the presented solutions) rather than creative mode (coming up with innovative solutions)

design sessions can sometimes be a serious affair and so an opportunity for “play” (while still doing something productive) is lost (this is a fluffy one but worth a mention I think), a design session can be light-hearted while still providing all the value

A Much Better Design Session

A pair calls a design session in very similar fashion to the above. However before jumping into the problem, call for someone from the team a tell a joke or tell one themselves. It is unexpected in a work environment and will force people to snap out of thinking about what they were just doing, it is also a playful start to the discussion which I think is never a bad thing as it gets everyone more relaxed. This also has the potential to turn into a design session ritual that everyone on the team can look forward to which will be something they share that brings the team closer together.

Before we draw the problem on the whiteboard, we explain it using just words and then we try and represent the problem using a tactile abstraction (i.e. build what you mean using lego blocks or chess pieces or anything that people can move and touch). This gets people thinking about the problem domain before you draw it i.e. forces them to think about it before seeing it in a familiar medium. The other thing you can do at this point, either before or after drawing, is to act the problem out using people as objects in the system. Many people learn and appreciate problems a lot better by actually doing rather than seeing or hearing about it. As an added benefit, this provides another opportunity for play, gets the less extroverted people more relaxed in a fun and friendly atmosphere and gets everyone primed to participate.

Do not present potential solutions you have come up with to the team, get the team to brainstorm first and come up with solutions of their own. Chances are they will probably come up with something similar to what you had, but they will have a lot more stake in it having thought it up rather than just validated the solution that the pair that called the session contributes. By not forcing your potential solution on the team you also have a much better chance of the team coming up with something truly innovative that you haven’t thought of (remember it’s analytical thinking – validating a solution, vs creative thinking – brainstorming a solution). Of course if noone can come up with anything interesting present your solution, you don’t want to get stuck in design paralysis.

At this point everyone discusses and agrees on a way forward and the design session is concluded. The difference is:

the team was a lot more engaged

everyone had fun

people had a break from the routine

everyone was heard (there were no chickens in the design session, only pigs)

everyone goes back to their work feeling a lot more fulfilled

the team has bonded together that little bit more

At The End Of The Day

I have very strong opinions on design sessions. I believe they are an extremely valuable tool in the arsenal of any agile team. However I also believe that unless you can fully engage everyone on the team (who is present at the design session) and get everyone thinking creatively (and potentially in a different mode than they would normally) you’re wasting a large part of the benefit that a design session can provide. Do you use design sessions in your team (if so do you use them as fully as you can) and do you get a lot of value out of them? I’d love to hear what other people have to say on the matter.

Share this:

At my client site, we have meetings that talk about design, but they are not really design sessions. It basically turns into a competition to see who can blurt out the “best idea” and egos play a huge role. It is more important who says the idea, rather than what the idea is. And its like a the supreme court, where “precedence” plays a huge role. Its always, “well what has been done in the past, and let’s default to that.” There is no brainstorming, thinking out side the box or visual modeling. Older engineers get there ego hurt when someone challenges an idea or actually has an idea better than theirs.

I think a good rule to alleviate these characteristics of a meeting is to check the “ego” at the door. Have a theme “it doesn’t matter who comes up with the solutions, its whether or not we come up with the right solution.”

http://www.skorks.com Alan Skorkin

I design session should never be a pissing contest, it is important to remember that everyone ultimately shares the same goal. Doesn’t matter who comes up with the best solution, as long as someone does. There is a reason we work in a team, because we can’t do the work with just one person, no point trying to earn status by outdoing your teammates. Earn status by making your team and your teammates look good instead. You’ll get lot more out of that in the long run.

http://assarconsulting.blogspot.com Nirav Assar

Alan I completely agree. This is a systemic problem for the culture of the client. It is very difficult to change.