As I’ve mentioned a bunch of times, I tutor an Agile Project Management course at the Queensland University of Technology. Its been useful to me on a number of fronts, from making me think more about what the concept of being agile actually means to me, to simply giving me more experience speaking in front of large groups of people. On the other side of the equation, I hope its been equally useful to the students.

A secondary benefit of tutoring is that it exposes me to new concepts and activities that I’ve never really seen before. I’d never heard of Scrum City until we did it with the students back in the first semester, and the topic of todays blog post is a similar sort of thing.

Lean Coffee.

An Unpleasant Drink

Fortunately, Lean Coffee has absolutely nothing to do with coffee, well not anymore anyway.

Apparently the term was originally coined as a result of a desire to not have to organise speakers or deal with the logistics of organising a venue for a regular meeting. The participants simply met at a particular coffee shop and started engaging in the process which would eventually become known as Lean Coffee (one because its lightweight and two because it was at a coffee shop).

At a high level, I would describe Lean Coffee as a democratically driven discussion, used to facilitate conversation around a theme while maintaining interest and engagement.

Its the sort of idea that aims to deal with the problem of mind-numbing meetings that attempt to deal with important subjects, but fail miserably because of the way they are run.

Who Needs a Boost Anyway?

It all starts with the selection of an overarching theme. This can be anything at all, but obviously it should be something that actually needs discussing and that the group engaging in the discussion has some stake in.

In the case of the tutorial, the theme was an upcoming piece of assessment (an Agile Inception Deck for a project of their choosing).

Each individual is then responsible for coming up with any number of topics or questions that fit into the theme. Each topic should be clear enough to be understood easily, should have some merit when applied to the greater group and should be noted down clearly on a post-it or equivalent.

This will take about 10 minutes, and ideally should happen in relative silence (as the topics are developed by the individual, and do not need additional discussion, at least not yet).

At the end, all topics should be affixed to the first column in a basic 3 column workflow board (To Discuss, Discussingand Discussed.

Don’t worry too much about the relevance of each topic, as the next stage will sort that out. Remember, you are just the facilitator, the actual discussion is owned by the group of people who are doing the discussing.

I’m High on Life

Spend a few minutes going through the topics, reading them out and getting clarifications as necessary.

Now, get the group to vote on the topics. Each person gets 3 votes, and they can apply them in any way they see fit (multiple votes to one topic, spread them out, only use some of their votes, it doesn’t matter). If you have a large number of people, a simple line is good enough to avoid the crush during voting, but it will take some time to get through everyone. Depending on how big your wall of topics is, its best to get more than 1 person voting at a time, and limit the amount of time each person has to vote to less than 30 seconds.

Conceptually, voting allows the topics that concern the greatest number of people to rise to the top, allowing you to prioritize them ahead of the topics that concern fewer people. This is the democratic part of the process and allows for some real engagement in the discussion by the participants, because they’ve had some input into what they think is the most important things to talk about.

That last point was particularly relevant for my tutorial. For some reason, when given the opportunity, the students were reticent to ask questions about the assessment. I did have a few, but not nearly as many as I expected. This activity generated something like 20 topics though, of which around 15 were useful to the group as a whole, and really helped them to get a better handle on how to do well.

That’s What They Call Cocaine Now

After the voting is finished, rearrange the board to be organised by the number of votes (i.e. priority) and then its time to start the actual discussions.

Pick off the top topic, read it out and make sure everyone has a common understanding of what needs to be discussed. If a topic is not clear by this point (and it should be, because in order to vote you need to the topic to be understandable) you may have to get the creator of the topic to speak up. Once everything is ready, start a timer for 5 minutes and then let the discussion begin. After the time runs out, try to summarise the discussion (and note down actions or other results as necessary). If there is more discussion to be had, start another timer for 2 minutes, and then let that play out.

Once the second timer runs out, regardless of whether everything is perfectly sorted out, move on to the next topic. Rinse and repeat until you run out of time (or topics obviously).

In my case, the topics being discussed were mostly one sided (i.e. me answering questions and offering clarifications about the piece of assessment), but running this activity in a normal business situation where no-one has all the answers should allow everyone to take part equally.

Conclusion

I found the concept of Lean Coffee to be extremely effective in facilitating a discussion while also maintaining a high level of engagement. It has been a long time since I’ve really felt like a group of people were interested in discussing a topic like they were when this process was used to facilitate the conversation.

This interests me at a fundamental level, because I’d actually tried to engage the students on the theme at an earlier occasion, thinking they would have a lot of questions about the assessment item. At that time I used the simplest approach, which was to canvas the group for questions and topics one at a time. I did have a few bites, but nowhere near the level of participation that I did with Lean Coffee.

The name is still stupid though.

As a result of being a tutor at QUT (Agile Project Management, IAB304 (undergraduate), IFN700 (post-graduate)), I get some perks. Nothing as useful as the ability to teleport at will or free candy, but I do occasionally get the opportunity to do things I would not normally do. Most recently, they offered me a place in a course to increase my teaching effectiveness. Honestly, its a pretty good idea, because better teachers = happier, smarter students, which I’m sure ends up in QUT getting more money at some point. Anyway, the course is called “Foundations of Learning and Teaching” and its been run sparsely over the last month or two (one Monday for 3 hours here, another Monday there, etc).

As you would expect from a University course, there is a piece of assessment.

I’m going to use this blog post to kill two problems with one idea, mostly because killing birds seems unnecessary (and I have bad aim with rocks, so it would be more like “breaking my own windows and then paying for them”). It will function as a mechanism and record for completing the assessment and as my weekly blog post. Efficient.

Anyway, the assessment was to come up with some sort of idea to provide support to students/increase engagement/building a learning community, within my teaching context (so my tutorial).

I’ve cheated at least a little bit here, because technically I was already doing something to increase engagement, but I’ll be damned ifI’m not going to use it just because I thought of it before doing the course.

We do retrospectives at the end of each workshop.

Mirror Magic

If you’ve ever had anything to do with Agile (Scrum or any other framework), you will likely be very familiar with the concept of retrospectives. Part of being agile is to make time for continual improvement,so that you’re getting at least a little bit better all the time. One of the standard mechanisms for doing this is to put aside some time at the end of every sprint/iteration to think about how everything went and what could be improved.

I’ve been practicing agile concepts for a while now, so the concept is pretty ingrained into most things I do, but I still find it very useful for capping off any major effort and helping to focus in on ways to get better at whatever you want.

In the context of the workshops at QUT, I treat each workshop as a “sprint”. They start with a short planning session, sometimes feature the grooming of future workshop content in the middle and always end with a retrospective.

While I think the whole picture (running the workshops as if they were sprints) is useful, I’m just going to zero in on the retrospective part, specifically as a mechanism for both increasing engagement and for building a community that treats self-improvement as a normal part of working.

The real meat of the idea is to encourage critical thinking beyond the course material. Each workshop is always filled with all sorts of intellectual activity, but none of it is focused around the process of learning itself. By adding a piece of dedicated time to the end of every workshop, and facilitating the analysis of the process that we just shared as a group, the context is switched from one focused purely on learning new concepts, to how the learning process itself went.

Are Reflections Backwards…or Are We?

But what exactly is a retrospective?

To be honest, there is no one true way to run a retrospective, and if you try to run them the same way all the time, everyone will just get tired of doing them. They become stale, boring and generally lose their effectiveness very quickly. Try to switch it up regularly, to keep it fresh and interesting for everyone involved (including you!).

Anyway, the goal is simply to facilitate reflective discussions, and any mechanism to do that is acceptable. In fact, the more unusual the mechanism (as long as its understandable), the better the results are likely to be, because it will take people out of their comfort zone and encourage them to think in new and different ways.

To rebound somewhat from the effectively infinite space of “anything is a retrospective!”, I’m going to outline two specific approaches that can be used to facilitate the process.

The first is very stock standard, and relies of bucketing points into 3 distinct categories, what went well, what could we do better and any open questions.

The second is more visual, and involves drawing a chart of milestones and overall happiness during the iteration.

There’s a Hole In The Bucket

The buckets approach is possibly the most common approach to retrospectives, even if the names of the buckets change constantly.

The first bucket (what went well) is focused on celebrating successes. Its important to begin by trying to engage with everyone involved on the victories that were just achieved, because otherwise retrospectives can become very negative very quickly. This is a result of most people naturally focusing on the bad things that they would like to see fixed. In terms of self improvement, the results of this question provide reinforcement for anything currently being done (either a new idea as a result of a previous retrospective or because it was always done).

The second bucket (what could we do better) is focused on stopping or redirecting behaviours that are not helping. You will often find the most feedback here, for the same reason I mentioned above (focusing on negatives as improvement points), so don’t get discouraged if there is 1 point in the first bucket and then 10 in the second. This is where you can get into some extremely useful discussion points, assuming everyone is engaged in the process. Putting aside ego is important here, as it can be very easy for people to accidentally switch into an accusatory frame of mind (“Everything I did was great, but Bob broke everything”), so you have to be careful to steer the discussion into a productive direction.

The final bucket (any open questions) is really just for anything that doesn’t fit into the first two buckets. It allows for the recording of absolutely anything that anyone has any thoughts about, whether it be open questions (“I don’t understand X, please explain”) or anything else that might be relevant.

After facilitating discussion of any points that fit into the buckets above, the final step is to determine at least one action for the next iteration. Actions can be anything, but they should be related to one of the points discussed in the first part of the retrospective. They can be simple (“please write bigger on the whiteboard”) or complex (“we should use a random approach for presenting the results of our activities”), it really doesn’t matter. Actions are a concrete way to accomplish the goal of self-improvement (especially because they should have an owner who is responsible for making sure they occur), but even having a reflective discussion can be enough to increase engagement and encourage improvement.

There’s No Emoticon For What I’m Feeling!

The visual approach is an interesting one, and speaks to people who are more visually or feelings oriented, which can be useful as a mechanism of making sure everyone is engaged. Honestly, you’ll never be able to engage everyone at the same time, but if you keep changing the way you approach the retrospective, you will at least be able to engage different sections of the audience at different times, increasing the total amount of engagement.

It’s simple enough. Draw a chart with two axes, the Y-axis representing happiness (sad, neutral, happy) and the X-axis representing time.

Canvas the audience to identify milestones within the time period (to align everyone), annotate the X-axis with those milestones and then get everyone to draw a line that represents their level of happiness during the time period.

As people are drawing their lines, they will identify things that made them happy or sad (in a relatively organic fashion), which should act as triggers for conversation.

At the end, its ideal to think about some actions that could be taken to improve the overall level happiness, similar to the actions that come from the bucket approach.

Am I Pushing Against The Mirror, Or Is It Pushing Against Me?

Running retrospectives as part of workshops is not all puppies and roses though.

A retrospective is most effective when the group is small (5-9 people). In a classroom of 50+ students, there are just too many people to facilitate. That is not to say that you won’t still get some benefit from the process, its just much harder to get a high level of engagement across the entire audience when there are so many people. In particular, the visual approach I outlined above is almost impossible to do if you want everyone to participate.

One mechanism for dealing with this is to break the entire room into groups, such that you have as many groups as you normally would individuals. This can make the process more manageable, but does decrease individual participation, which is a shame.

Another problem that I’ve personally experienced is that the positioning of the retrospective at the end of the workshop can sometimes prove to be its undoing. As time progresses, and freedom draws closer, it can become harder and harder to maintain focus in a classroom. In a normal agile environment where retrospectives bookend iterations (i.e. the next iteration starts shortly after the previous one ends and the retrospective occurs at that boundary), and where there is no appreciable delay between one iteration and the next, this is not as much of a problem (although running a retrospective from 4-5 on a Friday is damn near impossible, even in a work environment). When there is at least a week between iterations, like there is with workshops, it can be very hard to get a good retrospective going.

Last but not least, it can be very hard to get a decent retrospective accomplished in a short amount of time, and I can’t afford to allocate too much during the workshop.

When running a two week iteration, its very normal to put aside a full hour for the retrospective. Even then, this is a relatively small amount of time, and retrospectives are often at risk of running over (aggressive timeboxing is a must). When running a workshop of 2 hours, I can only realistically dedicate 5-10 minutes for the retrospective. It can be very hard to get everyone in the right mindset to get a good discussion going with this extremely limited amount of time, especially when combined with the previous point (lack of focus dur to impending freedom).

Aziz Light!

You can see some simple retrospective results in the image gallery below.

IAB304 - S1 2016 - Retrospectives

The first image is actually not related to retrospectives at all, and is the social contract that the class came up with during the very first week (to baseline our interactions and provide a reference point for when things are going poorly), but the remainder of the pictures show snapshots of the board after the end of every workshop so far.

What the pictures don’t show is the conversations that happened as a result of the retrospective, which were far more valuable than anything being written. It doesn’t help that I have a natural tendency to not focus on documentation, and to instead focus on the people and interactions, so there were a lot of things happening that just aren’t recorded in those photos.

I think the retrospectives really help to increase the amount of engagement the students have with the teaching process, and really drive home the point that they have real power in changing the way that things happen, in an immediately visible way.

And as we all know, with great power, comes great responsibility.