I recently facilitated two advanced BDD/Specification by Example workshops for the Australian branch of a well known agile consultancy. This was an interesting challenge because most of the workshop participants already had experience with the technique, some quite a lot in fact, but it was impossible to measure what they already knew and what their weak spots were over the phone. I decided that, on my way there, I will come up with a good way to measure their knowledge quickly and use that on the start of the first day to actually produce a schedule for the workshops. As the flight was looooong, I had time to experiment. The result worked brilliantly and I think that it could be extrapolated to other teaching other techniques to a certain level as well.
From my experience helping others implement Specification by Example I learned that different teams often focus on different expected benefits and problems and that tells me quite a lot. By knowing what people consider key challenges and benefits, I can spot misconceptions, lack of understanding and signs of typical problems. This information is enough to plan a good workshop, so I decided to capture that.
The general advice from Training From the Back of the Room is to provide a connection with students’ current knowledge as an ice-breaker for training. This works really well as students prime their brains to relate better to the workshop material and accept new knowledge. Apart from capturing the information I needed, I wanted the students to work in groups of 3-4 and talk about what they already knew, sharing it with the others in the group. This way they can have a good exchange of ideas before the workshop really starts, which will enable them to relate better to the remaining material. And it will turn the first half hour of a workshop into something really useful rather than a dull chain of introductions.
I like the collaborative aspect of Innovation Games and the discussions around whiteboards every time I played the Speed Boat. That seemed perfect to get people talking and collaborate, and innovation games also have a visual aspect that makes them very appealing. People can see and imagine the engines and the boat in the Speed Boat game and that drives them. I wanted to stimulate the collaboration by giving the workshop participants something to imagine visually.
I decided to combine all those goals and create something similar to an innovation game, focused on collaboration around benefits and challenges of Specification by Example, from which the participants would benefit by connecting their experience and existing knowledge with the rest of the material. Unlike the innovation games, I wanted to use it to measure the level of knowledge about a topic rather than for product innovation.
I came up with the metaphor of climbing a mountain – which I imagine as a long, challenging and exhausting process with some very interesting views along the way, similar to implementing a process change in a software firm. I asked the workshop participants to imagine a mountain path with three log-cabins for refreshments along the way and a backpack at the bottom. The mountain path described their clients’ journey to implementing a process (reminder: these guys are consultants, so adjust for an internal development teams), and they started with a backpack full of challenges. The clients climb the mountain to get the stuff from the top log-cabin (long term benefits), while getting refreshments at the mid-way cabin (mid-term benefits) and the cabin at the bottom (short-term benefits). Using a few free clip-art images, I created a simple Prezi to introduce this game. (feel free to use it for your own stuff)
The participants worked in groups of 3-4 to draw this path on a whiteboard and put sticky notes with challenges, short-term, mid-term and long-term benefits on it. Here is one of the results (click here for a high-res version).
I was able to adjust the schedule to fit their individual needs, and I felt that the discussions they had during this game enabled them to connect much better with the rest of the course. The feedback I got at the end was probably the best one so far, which means that the idea worked out nicely.
|
|
Very interesting – love the speed boat exercise. I think we have fundamentally visual brains, and visual exercises always create better engagement.
I didn’t know about Prezi before and went to have a look – have you taken a look at the “Maths is not linear” Prezi? It has some points that I really think pertain to the learning process in general, and it crystallized in my mind that all projects are learning exercises.
The “Maths is not linear” Prezi emphasises that telling someone how to do something for which they have no need and in which they are therefore not interested, with the argument that they will require it later to do something they that they do need, is not a motivating way to learn. Instead it recommends going straight to the end to define the goal that the individual *is* interested in, and working back from there.
This seems to be to fit perfectly with the rationale for specification by example. Show me the money – the business goal – the outcome – and I’ll work back from there, motivated by my desire to achieve it. Keep telling me what to do, without me understanding the goal or where I’m headed, and I’m hardly going to be motivated.
More and more I come to understand that projects are projects, no matter what industry you’re in. Each team needs its particular hard skills, but the driving forces for high performing teams delivering high quality with low cost, are communication and motivation. And communication is a pre-requisite to deliver motivation.
URL for the prezi I mention – http://prezi.com/aww2hjfyil0u/math-is-not-linear/
Gojko,
Thanks for sharing! I like the idea of active participation and visualization right at the start of the session. I have an upcoming workshop and will consider using this.
Cheers,
Declan