How we harnessed our knowledge to upskill our team with an Unconference

How we decided to run a learning focussed unconference

Our 20 person delivery team at Citizens Advice have a quarterly in person day.

During these days we prioritise knowledge sharing, building connections and exploring shared challenges. Alongside creating space for fun and team building.

In June, our in person day focused on building connections. We started out with a mixer style session. Picking questions out of a hat — with a mixture of work based and ice breaker type questions. Rotating the groups as we moved through a few rounds.

This allowed us to surface our different contexts, experiences and knowledge bases. Highlighting that there is so much we can learn from each other.

As a delivery team we want to support each other to learn and develop. the afternoon of that June team day was a retrospective focussed on how well we’re achieving that goal.

We held space to reflect on good practices as well as useful tools and resources that we use for our own learning.

We also looked at where we can improve and what we can commit to doing as a team to aid our collective L&D journey.

We were really keen to lean into the idea that we have lots to learn from each other.

Matt Saull, one of our Senior Delivery Managers pitched the idea of an unconference for our next in person day. So we took this forwards and made it happen for September.

What is an unconference?

Google defines an unconference as

a loosely structured conference emphasising the informal exchange of information and ideas between participants. Rather than following a conventionally structured programme of events.

For us, this meant asking the team to pitch sessions, which could be anything from introducing a topic and sharing their own experience with a group and asking others to do the same. All the way through to a fully planned and facilitated workshop.

The team made suggestions knowing we’d decide the final agenda together on the day. Meaning, it was likely not all sessions would run.

Our process

Prep

Two of our Senior Delivery Managers Matt and Jim lead on pulling together the broad plan for the day. They:

Setting parameters for the sessions
We’d have two different types of sessions. Breakouts which would be at most 45 minutes long and lightning talks which would be at most 10 minutes.

Setting the outline agenda
We’d have two tracks, so at any point during the day there would be two things happening at the same time, with attendees free to move between the two tracks at any point (even mid session if they chose!). We’d between 4 and 6 breakout sessions and between 4 and 8 lightning talks. Depending on the number of submissions and how the team voted.

Collecting pitches
We used a simple trello board to collect ideas. With template cards and lists for each of the two types of session.

Deciding the agenda

Jim facilitated us in refining and prioritising our agenda on the day. We decided that we’d have 6 breakouts and 4 lightning talks, based on the number of pitches we’d had for each. We copied the titles of the Trello cards over to paper sticky notes and put them on a whiteboard.

Jim then asked everyone who’d pitched a session to give a quick overview of what the session would be. These pitches were sub 30 seconds and gave a flavour of what people could expect to do and learn. We even had new, last minute pitches on the day — which is exactly fitting the ethos of an unconference!

After the pitches we each took 5 sticky dots — 3 to vote for breakout sessions and 2 to vote for lightning talks.

We formed our agenda as a team by placing the highest voted session into time slots. Putting the lower voted sessions into a backlog to cover in the future.

Breakout sessions

Risky Business (Julia Sang)

The what
I’ve often found projects might have a couple of risks listed in a document, put together at the start by the product manager and delivery manager, and then never looked at again. I wanted to give people some ideas on how to engage the whole team in raising areas of potential failure, how to decide which ones are the most pressing and to plan mitigations, how to keep them relevant to the project, and how to write a risk so that it’s clear what could go wrong.

The how
I’d written a fake project brief — believable enough to be something we might actually do, but with a few easter eggs in there so people could have some fun with it. I assigned roles to each person in the group so we could represent a typical project team and get multiple perspectives on the work — developers, testers, user researchers, designers etc.

To start, everyone was asked to come up with one risk, so the first person can’t talk for ages. Once everyone had a chance to raise one risk we continued to go around until people ran out of ideas. Each risk was added as a sticky to a whiteboard. People really got into their roles and became quite passionate about the risks related to their area of expertise!

As we went, we grouped similar risks, and once we had finished brainstorming we prioritised the risks putting the highest impact and most likely ones at the top, with the lowest impact and least likely at the bottom. Doing this generated more discussions in the team and helped people to start thinking about what we could do to mitigate risks.

We stopped there, but had a few minutes left to talk about:

• How the next step would be to action-plan (to stop issues turning into risks)
• How to document risks (we do it in trello but we talked about other formats too)
• How to create regular space in your team to review and update risks
• How to use the ‘If… Then…’ statement to write risks to show their impact

The Review
The brief we were given was very cleverly crafted. It was plausible enough that we were able to identify risks that might be common to a range of projects and so the discussion about how we might prioritise and mitigate those risks was really relevant and helpful.

However, the brief was also far-fetched enough that we could both have fun with it but also explore how we approach risk when dealing with something new. The biggest risk was one that we didn’t immediately spot because it doesn’t come up in every project. This emphasised to me the importance of the whole team being involved in risk planning; it took a range of roles and experience to recognise the myriad of risks within the project brief.

By the end of the session, the brief, which had started off sounding reasonably plausible, seemed completely ridiculous. My take home message from this is that risk planning needs to be done properly and early or you end up with the biggest risk of all; a project that can never be delivered.

The Reflection
People had a lot of fun with the brief and getting into character, which really helped to bring this practice to life, and show how it’s so important to have people from all the different project disciplines involved. People went away with a few new ideas to try in their teams and an idea about what kinds of risks to look out for.

Scaletrix (Lian Gooden)

The what
This session was all about learning about different frameworks to scale agile, understanding the benefits and limits to these frameworks and working out where different elements might fit into our organisation and how we can start our journey to scale agile across the org.

The how
I gave an overview of SAFe Scaled Agile Framework and a brief summary of LeSs and also outlined my own experience with SAFe. I then gave the group the opportunity to ask questions, which led to a more general discussion about scaling agile. I gave the group different coloured Post-It notes to write down benefits, suggestions for where and how it might work at Citizens Advice, and lastly the possible challenges to scaling agile here. We ended the session talking about how we might be able to start experimenting.

The Review
Lian did a great job at ‘dejargonising’ (is that a real word?!) her examples from her time at Currys Digital and gave practical examples for how scaled agile had worked there, enabling us to think about how agile at multiple levels (team, programme and portfolio) might work here. The session was clear, fun, engaging and concise and I liked the way Lian used coaching questions to frame the opportunities and challenges for us here at Citizens Advice to prompt expansive thinking from the group. Her relaxed approach and the informal format really enabled the group to explore ideas, all contribute equally to the conversation and learn from practical past experiences from a peer!

The Reflection
I think this session went really well and I got some great feedback into it.

The team were really engaged, we had some great discussion and points made. I loved this session because it also challenged me and made me reflect on my own knowledge and experiences. Although the purpose of the unconference was knowledge sharing, perhaps this session felt unfinished by not continuing the conversation and assignign actions to make a start at scaling Agile.

All Aboard the (Kanban) Pizza Express (Martyn Bennett)

The what
In this session we wanted to explore how implementing Kanban could reduce waste and enable more effective, efficient, predictable delivery.

The how
The teams were shown a paper pizza and the process for making it. With some basic quality control elements highlighted. The pizzas needed to be of a roughly equal size and look reasonably uniform.

`The pizzas consisted of a triangle base, cut from yellow card. Topped with sauce (Red sharpie, of course) and two oblongs of cheese and two squares of ham.

They were then given the materials needed to make their own paper pizzas and set the task to make as many as they could before I shouted stop.

After I shouted stop, the scoring method was introduced. Teams gained points for complete pizzas and lost points for excess ingredients and unfinished pizzas.

They were then given a brief introduction to Kanban. Covering some of the core principles;

• visualising the workflow
• setting work in progress (WIP) limits
• monitoring and managing flow through the system
• implementing feedback loops.

The teams were then given Kanban boards and moved into a retrospective session. Tasked with reviewing what had gone well in the first round and what they could improve. With prompts to think about how the concepts of Kanban (and their shiny new board) could help them. They were asked to add columns to their Kanban boards and set some WIP limits.

We moved onto round two. Teams were given the same amount of time and maintained the goal to make as many pizzas as possible. Though now knowing they’d also need to minimise waste to maximise their score.

We added in a mid-point stand up, for teams to look at their workflow and WIP limits and make any changes.

All teams saw an increase in points scored, mostly through having less wastage!

The Review
I learned loads from this session and have been able to apply the learning back in my team immediately. It was such a fun way to learn about the principles of Kanban. Learning by doing really works for me, and this session had tonnes of that.

The lessons we learned were to pay real attention to our work flow & what we had visualised on the board and why it is so important to limit WIP. Having a mini-retro in the middle of the exercise allowed us to learn lessons in the moment and immediately apply them in the second half of the exercise. It was a highly effective way to learn many lessons very quickly and also walk away knowing how to apply them. It was an excellent session that I will always remember. Well done Martyn!

The Reflection
I got the idea for this session having seen Darrell from Kin+Carta post about running it with his team a few weeks before — he was kind enough to share some reflections and pointers with me in advance. So I felt I was starting from a really good place. I just needed to make it fit our session parameters!

People really had fun in this session which was lovely to see as the facilitator. Using something as simple as making a pizza to explore workflows and wasteage make them easier digest. I’m a big fan of removing technical jargon and complexity and this is a great example of that.

My biggest reflection is that crunching the session down to 45 minutes didn’t do it justice. It was challenging to introduce and explore the full benefits of Kanban with only two rounds. Having a second retrospective and third round would’ve helped with cementing the learning.

Estimation — What’s the Heckin’ Point (Waseem Chauhan)

The what
In this session I wanted to explore our understanding of estimation, share experiences of it and look at why you might (or might not) want to use it.

The how
We started by defining estimation, using think-pair-share to come up with a combined definition of estimation. This was an interesting exercise as we all realised that we tend to focus on different aspects of estimation as being key to the definition. The next step was to explore where this difference in understanding came from.

We shared our differing experiences of estimation with a partner, and then reflected back what they told us to the group. It was clear that we had all used estimation in very different ways, and some were currently using estimation while others weren’t (with all their teams at least).

To explore this further we split into 2 groups and wrote out 9 post-its on the benefits of estimation. In groups still, we put these into a diamond 9 formation. The diamond 9 allowed us to prioritise what was most important for us and what was least important (ie. what is our main drive to use estimation). It was interesting to note that one team’s top diamond was ‘align the team around the task’ while the other team’s top diamond was ‘forecasting cost and time’. This distinction was caused by the teams differing backgrounds, with the second team having a background more in agency work and the first team working more in environments such as the CA. It also linked well with the first task and provided an insight on why it was so difficult for us to actually agree on a definition of estimation.

The Review (by Julia)
Coming from an agency background, I started this session with one perspective on what estimation is for — to make sure you come in on time and on budget, of course! But through our discussions I realised there’s so many other reasons you might want to estimate the work. When we were asked to do the diamond 9, I thought we’d struggle to come up with 9 reasons to estimate but when we started listing them out quite a few ideas were generated. In my group we still ended up with cost and time at the top of the diamond, but came away from the session with an appreciation of the other benefits of estimating and an idea about when you might use them.

The Reflection
The diamond 9 activity really helped us understand why we used estimation, and brought out our different experiences of it, differences which shaped this view of estimation. Faced with opposing views of the purpose of estimation we were able to reflect on our own use and understanding of the purpose of estimation. I would have liked to circle back at this point and review the definition of estimation based on this discussion but we ran out of time.

The (Iterative, Incremental), Big Bang Theory (Martyn Bennett)

The what
We purchased a deck of the incremental, iterative, big bang cards from Scrum & Kanban, their description of the game is to encourage people to think about alternative approaches for tackling projects. but, rather than discuss boring work-like scenarios, to decide on an approach for everyday scenarios.

The how
We began with the facilitator giving an introduction to the different types of development and their features using the example given on the cards of building roads providing access and to and linking between 4 office buildings as framing. We had a brief discussion about the benefits and drawbacks of each of the approaches in this scenario, before moving into a slightly adapted version of the “lose the cards” game detailed on the Scrum and Kanban website.

We placed the black scenario cards, which give the everyday scenario such as knitting a scarf or converting a loft in the middle and shuffled and dealt out 5 white approach cards (mixture of iterative, incremental and big bang) to the players. This meant everyone had a random mix of approach cards to use throughout the game.

We then took it in turns to play the dealer and turn over a scenario card and everyone else submitted a white card to signify the approach they’d choose from the cards in their hand. We then gave everyone a chance to say why they picked their approach, with the dealer choosing the approach they felt was best as the winner, everyone holding this card could then discard it.

The Review
This was a really fun session, thinking about the optimum way to tackle each scenario made for some very interesting discussions and rotating the dealer meant everyone got properly involved. I feel like every delivery manager should have a go at this game.

The Reflection
This was a great game that really allowed the group to explore the different methods of development and crucially that often there was able to be justification for why you would pick any of the three approaches. Sometimes not being left with the ‘obvious’ card meant people needing to consider where value could be gained from a different approach.

I think this led to the learning that often an approach isn’t wrong, but just different, depending on what the most important elements of the overall thing you’re trying to achieve are.

The Wheel of Anything (Freya Joseph)

The what
The Wheel of Anything (also known as the Wheel of Life) is a coaching tool I was introduced to on an agile coaching course. I’ve found it to have a number of useful applications and wanted to share it with the team.

The how
The idea is you divide a circle into segments. Each line represents a theme, skill, or area you want to assess. You need a label for each line.

You then create a scale along the lines from 1–5 (or more, whatever scale works for you).

Next, you rate where you are now in terms of competency/satisfaction/confidence and draw a mark.

Finally, you rate where you want to get to against each label and draw a mark.

Colour in the gaps between the two lines. Biggest gap = biggest area for improvement.

I gave everyone a template wheel based on my example wheel (above) and talked them through the various uses for the tool. I then let them decide which theme would be most useful for them from the following suggestions:

• Assessing where you are and where you want to be across key delivery skills and capabilities (learning & development planning)
• Rating your current and optimal proportion of time spent across your various responsibilities (capacity mapping)
• Rating your current and optimal impact of your individual stress levers (resilience mapping)
• Rating your current and optimal proportion of time spent across your work and personal responsibilities (work/life balance mapping)
• A classic wheel of life

The Review
Freya ran this session really well and introduced us to a coaching and therapy technique that can be applied to anything. It was really interesting to see how different people applied it to aread of their lives, both personal and professional and also to hear how this can be used to solve different product delivery challenges. One such example was to plan team capacity and see where the team are currently spending their time and where it would be more ideal to spend working. It was great working in small groups and talking through our various wheels and hearing people coach themselves into solving their own dilemmas. It was really well thought out and well planned session with some tangible takeaways.

The Reflection
This is one of the main takeaways I had from a training course I was lucky enough to attend a few years ago. Unfortunately, we’re not always in a position financially to send everyone in our team onto this course, so it was great to be able to disseminate some of the learning I had found most useful.

The session itself requires a lot of self reflection, which was potentially a bit draining at the very end of a busy unconference, but hopefully the team got something out of it. It was simple enough to relay, although I do think there’s a bit of a flaw in the template design that caused a few participants to struggle with visually identifying the biggest gaps — try it, you’ll see what I mean!

Lightning Talks

Alongside our in depth sessions where we collaboratively explored things, we had 4 lightning talks each from a different member of the team. Where they detailed their views or experiences in a particular area. They all covered completely different things!

• Making a ‘Gantt Chart’ for an Agile Project — How can you present project plans to stakeholders who aren’t yet comfortable with Agile? (Claire Hammond)
• Is Being Agile Really Just About Being Willing? — How could you distil the concept of the agile mindset in the simplest way? (Martyn Bennett)
• Using Metaphors to Visualise Team Processes — Reflecting on how metaphors and analogy can help with problem solving(Josie Stone)
• Tips for Difficult Conversations — What are Some practical tips you can rely on when you find yourself in a challenging conversation (Paula Gray)

Feedback

The day felt at the time like it was an overwhelming success. Thankfully, the feedback the team has given really validates this.

“The organisation of the agenda at the start was seamless. The sessions overall were valuable and all ran basically to time and had engagement throughout.”

“Unconference format was perfect:”

“I loved the unconference! I learned loads and the pace and energy of the session was great.”

“I liked how the day gave members of the team (especially more junior members) a chance to share their experiences and thoughts in a freer way than usual. I liked hearing their very valuable thoughts about delivery”

“I really enjoyed learning from so many different people. I think it was a great idea to take a topic and give people the chance to share their experience / way of approaching the work, as it gave me lots of new ideas to think about. We have such a wealth of experience on the team it was a joy to be able to tap into some of it! “

The unconference concept is one that can be quite risky and we did have some moments where it felt like it could fall apart, as called out by another item of feedback

“It came together really well at the end but it was a little light on contributions in the lead up to the event which can’t have felt good for the organisers.”

So trusting in the format and in the attendee’s to bring ideas and that it’ll all be alright on the night is something that you need to lean into as an organiser.

As always, we have learnings for future iterations, one being that we ran two sessions at each end of a large room. This meant hearing the session people were in could be quite difficult with the background noise of the other session and also that the room we used was far too warm!

Overall, the unconference was definitely a successful way of galvanising our group and sharing some collective learning. It proved to be a cost effective alternative to formal training courses, and is something we’d definitely encourage others to experiment with and something we’ll definitely do again!

Perhaps we could collaborate with other teams and Communities of Practice inside and outside of Citizens Advice next time? If you’d be interested in co-designing and running such an event, please reach out!