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
- an opportunity to validate design decisions before implementation gets too far
- 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
[
](http://www.implementingscrum.com/2006/09/11/the-classic-story-of-the-pig-and-chicken/)
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.