Workshop with a Scrum Team - from setup to retro

1. Setup
2. Definition of the workshop contents
3. Selection of suitable activities
4. Test run
5. Implementation
6. Follow-up

Whether it is a workshop on a specific topic or a retrospective with a team, such a date is preferably tailored to its purpose and, if necessary, to the participants in order to obtain a high benefit from it.

At the beginning the planned goal of the appointment is defined. Here, there may be guidelines from outside or own observations from working with the team may initiate a need for a workshop. If, for example, topics are identified that occupy the group, in which the team or the Scrum Master see potential for improvement. Or there are disruptive factors which should be identified. In concrete terms, possible goals could be to promote cooperation within the team, to correct these or even to create a platform for this in the first place. Maybe the team members work side by side or do not trust each other yet. Whether the workshop should focus on a specific topic or whether it should be kept open can be essential for the next steps.

Practical example: Workshop to improve team cooperation

I would like to give an insight into a workshop we initiated with the management of a customer. The team stability was affected by some personnel changes. In the team, consisting of Namics developers and the client's developers, there was a cultural difference. The collaboration was done remotely and in 4 small local groups of 1-4 people. Some already knew the Agile approach, for others the project was the first point of contact with Agile software development. We observed that these different factors had a negative impact on team performance. This initial situation provided a very good reason for a workshop.

If the purpose of the workshop is known, I recommend to gather as much knowledge as possible about the participants in order to optimally adjust the workshop to the individual characters. Even if this is not always possible, such knowledge can make a big difference. If, for example, more observant characters, active questioners, extro- or rather introverted people take part, or if there are perhaps even conflicts between participants in the group, this can affect the constructive cooperation in the workshop. Here it is important to create a trusting and respectful environment. This should then be the focus when starting the workshop.

As varied as the possible constellations of framework factors are, the larger the group of participants, the more important one thing is: Have the courage to decide what you want to do with the group. You can make a science out of it or pick out one or two aspects and focus on them in further planning. Because if the workshop is successful in just one aspect, it will certainly not be the last.

Practical example: Intensive getting to know the team members

My observations of the team showed that the cultural difference was a decisive factor in teamwork, which prevented individuals from becoming more involved. Therefore I decided to place an icebreaker at the entrance, which leads everyone as fast as possible into a comfort area, in order to get relaxed into something new. I chose the theme of self-reflection with the aim of revealing and learning about oneself, combined with humour, to create an atmosphere of mutual goodwill.

Closer observations of the team showed that there were only a few constructive discussions and therefore the colleagues did not really challenge each other. Decisions of the other were accepted, sometimes with a gnash of teeth. Constructive discussions about solution ideas hardly took place. There was even an emerging tendency towards "finger pointing". The different level of experience with the agile principles and their tools from agile software development was one aspect that stood out as a possible cause of the problems. Another reason for the missing but important discussions was that the different competencies knew little about each other's work. To outsiders, the differences between DevOps, backend and frontend engineers may seem insignificant, but up close they can be as different as day and night. Due to the increased remote collaboration, the knowledge of the motivation of the other competencies seemed to have been lost, something that was previously conveyed rather subconsciously when working in the same office. Each person finds himself or herself in a different context in which he or she takes in, processes and stores or develops information. These diverse views can be important in order to arrive at holistic solutions, to support people in their development and should be generally encouraged. However, they can also lead to conflicts if apparent incompatibilities arise. With mutual understanding, however, this can also lead to high-quality teamwork. From my own experience, these are the holistic software solutions of which I still get a transfigured look and joyful goose bumps when I tell them years later.

The overall goal of the workshop should therefore be to make the motivation of the team members visible again and to refresh the knowledge of agile values.

As a Scrum Master or Agile Coach we face the challenge of moderating a workshop in a meaningful way. We have the opportunity to draw on a broad portfolio of methods and tools, e.g. technical literature, online tools or personal exchange with like-minded people. The fuller our toolbox and the more lively our network, the better. But of course you don't have to reinvent the wheel every time. It is important to realize that the methods are only the means to an end, namely to bring the goal of the workshop into focus and let all participants work towards it. But preparation alone is not enough. A spontaneous change of strategy may also be necessary during the workshop. If something unexpected happens, planned methods develop away from the workshop goal, we have to decide whether this is a welcome development and we revise the chosen approach or whether we and the team should return to the set goal. Here the facilitator is strongly challenged to continuously observe the group and it is recommended to have an alternative method up our sleeves that is a bit more generally applicable. There are no limits to creativity. Of course, there is a lot of technical literature available, which we strongly recommend to read.

If you are new to the field, we recommend the book Agile Retrospectives: Making Good Teams Great (Pragmatic Programmers), which provides many basic principles, including practical ready-to-use examples. The Retromat is also a great source of ideas for experiments.

Practical example for the selection of methods

Check-in for a trusting mutual goodwill

Even if it serves various clichés, figures from comics, film & television were the ideal candidates for our team workshop, as most of the participants should have a concrete picture in mind. Each participant including me should answer the question "If I were a comic/film or series character, which one would I be then and why? Each participant received his figure for the rest of the workshop day printed out as an avatar. The answers usually provide cheerfulness, surprises and mutual understanding. So a good basis for further good cooperation in the workshop.

Alignment of the agile mindset

To create a common basis for agile software development, I decided to include the agile values and principles as a theoretical part of the workshop. These can be referenced very well in the daily work of software developers, if something doesn't run smoothly and you have the impression that you are getting off the common path. The participants can also gain insights about each other, if everyone in the team can choose a favorite that he or she is particularly strong behind. The principles are also very suitable for a workshop or a retrospective in order to highlight individual principles that you may not yet see fulfilled or that you simply want to recall.

Strengthen cooperation by knowing the motivations

After a brainstorming with another Scrum Master about possible methods the realization came quite quickly: I only gain understanding if the team members know the motivation behind a decision. For this purpose the "Moving Motivators" offered themselves well. This method is about finding motivators for yourself and to find out where you are currently taking care of these motivators well enough. The method is initially conceived as a one-on-one method, but it is also very well suited for use by oneself or in a team. The concrete motivators are recognition, curiosity, freedom, status, fulfilment of meaning, honour, perfection, order, influence, solidarity.

Well, the theory is always fair enough. However, I advise against trying out a completely new method for the first time in direct practical operation. A test run is the easiest way to find out whether the chosen method is perhaps unsuitable, or the test run shows that you did not fully understand the method before and that you have reached a dead end. The test run also makes it very easy to compare the method found with the external conditions, such as the number of participants and the premises. Thus, a dry run is always a gain in security and why not involve uninvolved colleagues and play through ideas? New and known methods can be questioned or impulses for modifications can be picked up.

Practical example: How the test run revolutionized the format

A test on myself and one with an independent and experimental colleague showed some important findings. For one thing, he revealed that I would do well to practice the explanation of Moving Motivators again beforehand. Furthermore he showed that there was still "something disturbing" - not quite tangible at first, but in exchange with another colleague we were able to name it. There are a few basic things developers with these very general motivators would not learn from each other: namely, what software and quality related motivators drive them. After all, the goal was to support them in sharing their motivations for decisions and their strengths that they encounter in their daily work.     

So much for the decision to use a motivator format after the general "Moving Motivators", which fits the participants even better and makes them more aware of their daily basis for decision-making. The classic software quality ISO standard knows seven factors: changeability/maintainability, usability, efficiency, functionality, transferability, reliability. A few handicrafts later a small "Software Quality Motivators" card deck was created.

For the workshop itself, the facilitator should have enough free space to observe the group. For this purpose, participants can be asked to take over small tasks or to give up time-consuming secondary activities completely. Timeboxing of the individual activities also requires attention. It would be a pity if planned key activities were to be missed out because the check-in to the workshop is exhilarating but took up a third of the time. I also like to make a note of the planned vs. required time for methods in order to be able to make a better assessment for later workshops. Notes where there were deviations from the planning are also helpful to create a good basis for the follow-up.

Case Study: The Motivator Workshop

Due to difficulties with the journey the workshop was delayed a little bit. To let hecticness come up, I shortened something in the theory part. The workshop itself ran as planned in the timekeeping. For the motivator activities I had recorded my own results from the test run and used them as an example for the explanation. In the end, we even had time from the Software Quality Motivators, which some participants considered important but not yet fulfilled, to define activities for the team and the Leader Team, which they could then tackle directly as action items. Last but not least there was a lot of laughter and the personal exchange and conversations were celebrated at our coffee machine.

An effective workshop actually always has results on which one can build further. Be it new insights about the group, from participants about each other like strengths and potentials or simply further concrete fields of action and action items. Also whether activities have achieved the effect that was intended and whether the time allotted is sufficient, according to the number of participants. Did discussions arise that were unnecessary because there was perhaps a problem of understanding or would it have been useful to give more space to a necessary discussion? These and other insights are a good basis for further work with the team and give us Scrum Masters more security in the next workshop.

Practical example: Common insights

As a result of our workshop we could see which strengths, similarities and differences of the participants stood out. Our findings sharpened the picture of the advantages of this group constellation. We were also able to pass on the need for action found to the group accordingly or to work on it in the team afterwards. The Software Quality Motivators as well as the Moving Motivators have moved into my toolbox and are waiting for the next suitable assignment. They have also helped me in my personal application to have my next goals more clearly in sight.