Team-building workshop: Feedback on skills development

Once I came up with a team-building workshop which you can carry out with your teammates. It focuses on skills being developed during the project duration. It may help with early burnout detection, silent disagreement or simply it may help you with moving forward with some nice techy idea. After the workshop I've acquired quick feedback with 2 x 4/5 and 2 x 5/5. It should take about 30-40 minutes (depending on few factors).

1. Motivation

How did I get into the idea of the workshop? First of all let me remind you 3 of 12 principles from agile manifesto.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Continuous attention to technical excellence and good design enhances agility.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The workshop should help you find some opportunities to learn from each other in some areas/technologies to become a better professional. Also, consider the other way - you can help other to become better as a team. You can find out also about some common interests and decide to try something new (do some experimentation) to keep the team motivated. That was the main reason that drove me to do this - I felt simply a little bit bored, I felt that I am not learning anything new at my job, I just teach others and my free time is the only span where I work on self-development. Spoiler: I was wrong.

2. The how-to

We will need:

  • Markers for each of the participants.
  • A paintable space (board or wall).
  • Sticky notes

Participants: whole team (even product owner). Start with a short introduction:

Dear team, we gonna look into what have we been learning during our cooperation. That's it. Keep the rest for yourself now. It will help others to stay focused.

Now - give everyone 2 sticky notes and a marker. Ask them to think about what they have learned during the last 6 months (feel free to adjust this interval) at work and write on the first sticky note a grade in range 1 to 3 where

  • 1 means that I've learned nothing or almost nothing.
  • 2 means that I've learned something not too much but still.
  • 3 means that I've learned great stuff.

Once they are ready, ask them how much have their learned during last month, the same scale. Take the sticky notes, write names on the board, and place the notes next to the names in rows. The board should look like this:

1

You should be able to see if the learning curve did not drop. If everyone learned a lot during the last 6 months but almost nothing in the last month you should start a discussion about what prevents the people from further skills development. Keep in mind that the learning curve isn't linear - there are many distortions including your teammate's private life distortions so the drop doesn't have to be a bad thing. Maybe you are just on the "flat" part of the curve.

learning

Now it's time for a short interview. Start asking the people in turn about what have they learnt and write this next to the sticky notes. When you are ready ask if someone wants to change something (the given grade or the mini-list of stuff learned). This is desired - the people should now come into the "A-Ha!" moment that they learned this and that as well. You can write the changes in a different color to visualize the changes. The board should look like this:

2

Now it's time to short storytelling. Ask the people to talk about the things they have learned. Should we spread that knowledge? Do a workshop, pair programming, etc. Maybe someone learned something good in his spare time and we can invest some time to use this knowledge to improve something? If no one talked about it, tell a little bit about the fact that people have learned things they would not even think they have learned. This will keep their motivation in good shape.

The final round is about "wishes". Just ask the team members in turn what they are looking to learn next. The final board:

3

The side effect of this is that you can find out that someone has no ambitions. I advise you to leave that person for now and coach a few days later. Probably till that time the person will think about it and ask himself the question:

How I want to be a good programmer when my only ambition is to do the 8h workday?

This is dangerous and you should coach carefully - maybe someone has hard times now and needs a month to fix something in his life? Maybe someone is simply lazy and he will better match somewhere else? These are hard questions and it has to be addressed individually.

The key takeaway from this part should be a discussion again: do we have common interests? If yes what we gonna do with them? Why does someone want to learn X-stuff? Can we invest in that to make an improvement and let that person learn this X-stuff during his workday?

Our team found out that we want to write more F# and so we do. One team member also wrote that he wants to learn more about stuff we currently use in the project so we decided to do more pair-programming with him. Listen closely and try to find these actions.

3. Expected conclusions & actions

I hope you will find more, but this are the most certain points:

  • You may find out that despite your doubts you still do learn new things (my case). This will keep your motivation in good condition.
  • You may find out that you don't learn new things and neither do your teammates (I believe it's not possible that you are the only person that does not learn anything new in the team. If this is the case - time to change the team). As you have identified the problem it's the right time to talk about it. Try a new library? Create a new project in a new language? Rewrite some legacy part into new tech? There are plenty of things you can do.
  • You may find out that someone learned something important and it will be extremely useful to spread this knowledge to improve bus factor.
  • You may find out that you and some of your teammates have similar interests. For example if there are 2 persons in the team that wants to learn Kubernetes maybe it's worth to pair find some good points and convenience the rest to invest some time in the research and do it! Learn by doing it and get paid for it.

Finally I can imagine that the workshop can be a total disaster in one case - no one learns nothing and no one wants to. You should notice this without the workshop but to be honest with you - It's not the workshop to be a disaster, it's the team.

Summary

I hope you will enjoy the workshop with your team and that you will come into some "A-ha!" moments. Feel free to modify it - If you have some nice suggestions reach me via the contact form! I am looking forward to improving my home-grown workshop.