Sharing Responsibilities: Circles Workshop

Reading Time: 6 minutes

 

Earlier this year, I found myself on a team with a total of five testers – a welcome change from the solitary one.  With this new count came a new challenge: how could we split tasks and responsibilities in the most sensible, fair and efficient way?  To solve this problem, I held a workshop within the testing sub-team, and was pleased to find that it worked very well – the workshop itself, the format we used to decide how to share responsibilities between us, and the resulting artefact as a daily tool to guide us.

 

In this post, I’ll explain how we did that, using a more generic version of the slides I prepared for the workshop.  You can also download the slides as a .pptx or download the slides as a .pdf to hold the workshop with your own teams.  The workshop is designed to be completed in one hour.

 

Since it’s taken me longer than anticipated to write this post and the original artefacts had to be deleted at the end of the project a few months ago, I have to rely on memory for some details.  As a result, some details might be lacking, but I hope it’s still enough to provide value.

 

 

Note for Users of Screen Readers

 

This post uses images of slides.  To avoid duplicate text or unnecessarily long alt text, images of slides are not described.  If you are using a screen reader, please download the slides via the links provided above to read alongside the post.

 

 

Introduction

 

When holding any workshop, it’s important to provide meaningful context as to why you’re all there and what you want to achieve by the end of it.  This gives people incentive to engage and participate. In my case, I gave an overview of some of our team and individual needs, then explained some obstacles to fulfilling those needs.

 

 

 

Potential Solutions

 

Next, I briefly covered some potential solutions.  First, I gave a quick overview of the popular RACI matrix and reasons why this wouldn’t be a good fit for us.  One of the main ones is that we simply wouldn’t look at it again after creating it.  I’m really not a fan of “outcomes” that no one uses.

 

 

Secondly, I introduced the format I was keen to try – “circles”.  I’m not sure exactly where this originated from.  We use it in my DevOps and CloudNative department at MaibornWolff, and we borrowed it from another department.  However, my attempts to find out where it originally came from (or what the “official” name of it is) were unsuccessful. If you recognise this base format and know who originally created it, please let me know in the comments. (Edit: I’ve now been informed that the circles format comes from holacracy.)

 

 

(Yes, I know these are more ovals than circles, but that’s not the point.)

 

The main points of the circles format are included in the slide shown below, so I won’t re-type it here.  I also had some adjustments I wanted to make, which are explained as we continue.

 

 

 

Creating Circles

 

Next comes the main part of the workshop and actually creating the circles.

 

 

Collect and Cluster

 

The first step is to have participants think of different tasks and responsibilities that should be shared amongst the sub-team, and collect them on sticky notes.  Digital stickies are best for remote participants, easy documentation, and reducing waste.  We used https://www.webwhiteboard.com/ for this.  You should also collect sticky notes with specific challenges or obstacles towards completing these tasks, so they can be kept visible throughout the workshop and you don’t forget to account for them when refining your circles.

 

 

When everyone is finished adding tasks and challenges, the next step is to cluster these into themes (or circles) as a group and give each one a name that reflects what’s included in them.  Try to make the clusters similar in size in terms of the amount of responsibility / workload they cover for the best results.

 

The number of clusters will vary and depend on your context.  In our case, we were lucky that we just so happened to have five testers and five clusters, which made it easy for every tester to lead one circle each (more on circle leads later).  If your numbers don’t work out so neatly, that’s not an issue.  The circles format can still work well for you.

 

 

Map Interests and Expertise

 

The interesting bit comes when mapping out everyone’s individual areas of interest and expertise.  What can each tester teach someone else, and what would they like to learn?

 

 

When planning the workshop, I was a little concerned that there would be some “unloved topics” or tasks that no one would want to be involved in, so I asked everyone to map at least two things they wanted to learn and two things they could teach.  In the end, most people had many more than that, and we ended up having to pick our favourites.  In a team with more testers than clusters, it might not be necessary to set a minimum.

 

 

Discuss Circles

 

You now have the basis of your testing (or any other) circles.  (This format is not exclusive to testers or testing tasks.)

 

Have a look at the people in each circle.  Make sure there is at least one teacher, and enough people to carry out the tasks of the circle.  It’s not just about the number of people.  Have another look at the challenges / obstacles you collected.  With those in mind, does it make sense to have those people in the circle?  Look at the circles people are currently assigned to.  Is it realistic for them to be involved in all the ones they’ve chosen?

 

 

Consider everything as a whole and decide as a team which adjustments need to be made.  Remember that not being in a circle doesn’t mean not doing any of the work associated with it.  Circle members are first line supporters and the first people to go to with related tasks or questions.  People outside the circle are second line supporters and can still be called on for help, or contribute to related tasks if work in their circles is already handled.

 

 

Assign Circle Leads

 

Once you’re happy that the people in every circle makes sense, appoint a lead for each circle.  Pay attention to the slide below about what leads are and aren’t, to avoid confusion and unfair distribution of work.  Remember that leads can be learners too, since leading is about keeping circles organised and focussed.

 

 

 

Wrapping Up

 

Congratulations, you’ve now successfully decided how to share responsibilities within your team!  The final steps are just to make sure that everyone is comfortable with what you’ve come up with, understands what is expected of them, and that the new circles are documented and available to the whole team.

 

 

 

I also recommend reviewing and adapting the circles regularly, perhaps as part of your normal retro.

 

Here’s an example of the circles for testers, so you get an idea of how the finished product might look.

 

 

---

 

What do you think of this circles format, and the workshop?  Have you used any other methods to decide how to share responsibilities between multiple people in a similar role / discipline?  Let me know in the comments below.