A couple of weeks ago we were honoured and excited to welcome Alistair Cockburn, one of the authors of the Agile Manifesto, into Redbubble HQ. It was a hastily arranged, last minute opportunity, and we were thrilled that Alistair could spare the time for us out of his busy trip to Melbourne.
Alistair took over Level 2 (none of our meeting rooms were big enough for the occasion). He told us a bit about himself, his views on Agile Software Development (he describes it as a “co-operative game”) and ran an exercise with us.
This was his famous Draw the Drawing Game. It involved us splitting into self-organising teams of “artists” and “specifiers”. Specifiers would spend their time in one room, writing specifications of a drawing that the artists should draw in a separate room. They could only use textual messages between the groups (delivered to and fro by one of the specifiers). Speaking, drawing or gesturing was against the rules.
There would be 3 iterations, with time for the teams to reflect (retrospect) between each. My team decided to split into 3 artists and 3 specifiers. No thought went into this sizing other than “let’s see if it works”. Call us crazy!
In Iteration 1, we definitely had some issues with communication. The specifiers gave us artists a long list of detailed instructions – it took a fair amount of time to process this information and turn it into the drawing it was supposed to represent. Furthermore, we didn’t feel we had time to pass messages back to the specifiers to clarify things that we under debate. All of this inevitably resulted in an incomplete and inaccurate representation of what was being specified.
In our retrospective we decided to try and improve those problem areas. We agreed on smaller lists of instructions so that we would have time to process each instruction. This would mean less ambiguity and we would have a better flow of communication between the specifiers and artists. We also agreed for the messenger to be more available for the artists to send back questions. It was interesting to hear what problems others teams were facing, and their different proposed approaches to improve things. There was definitely a common theme of improving communication, collaboration and clarity.
Arguably, Iteration 2 was worse for us than iteration 1. So much for retrospectives – pah! Perhaps we tried to change too much in one go? Shorter messages were coming in, but now we were getting multiple messages arriving before we had completed the instructions from previous messages. There was inevitable confusion in the artist room. We tried sending messages back to the specifiers to get better clarity, but the disruption in flow was too much for us to turn round.
At this point, Alistair reminded everybody to make sure that we were not blindly following rules that weren’t explicitly specified. Perhaps there were ways of staying within the constraints, but with better opportunities for collaboration and removing waste from our process?
We realised that while there was a rule that artists and specifiers were to be in different rooms, there was nothing stopping the specifiers being close enough that we could pass messages faster. The specifiers could also actually see what we are drawing and could provide instant feedback. For some reason, none of the teams used this tactic from the start. We implicitly assumed rules that did not exist. There is a valuable lesson in there somewhere.
Despite this realisation, we struggled again in Iteration 3. It highlighted that we might be battling against factors that had not yet become clear to us. For example, we seemed to lack drawing talent, at least in the artists. We never got the chance to assess who were the most talented artists in the team, and thus optimise the split of functional ability. Perhaps having 6 people in our team was too much?
There is a stigma attached to not being “busy”, and thus there is often a tendency to try and utilise everyone 100% rather than determine the most effective team size for the job at hand. Perhaps our team size was OK but there was a suboptimal split between artists and specifiers?
Alistair was hammering home to us the importance of continuous improvement. There are so many factors at play in the development of something useful, requiring disparate people and teams across a company. The only way to move towards effective outcomes is to always assess the way we are working together, and identify where the rules are impeding us from being effective. It is the removal of these impediments that allows for truly impactful increases in effectiveness. Making small changes within “the rules” will only provide marginal gains.
Everyone really enjoyed the 90-minute session. Such a simple exercise can reveal some powerful insights about what is effective collaboration between people working toward a common goal. It is also a stark reminder of how easy it is to get drawn into the day-to-day “normality”, and not make time for learning and improvement. Alistair drew a diagram to press home this point:
Thanks again Alistair. You’re always welcome back here, any time. As a small token of our gratitude, your Redbubble T-shirt with the above message proudly emblazoned on the front will be winging its way to you soon :)