Posted in Retrospectives, Working Agile, Working as a ScrumMaster

Shorter and fewer Retrospectives, please

Previously I have asked my team my team for feedback. I was surprised that the team rated the retrospective as our least valuable scrum event. Surprised because it is the event I, as the scrum master striving to help the team improving, put the most effort into preparing and facilitating. I honestly felt that we were making progress, and in some aspects I would argue that we were. However the team was not sharing the same perception, and then my perception does not really matter.

To show the team, that I take their feedback seriously, and to help the team readjust the focus retros on what matters for them, I designed a retro, with the following agenda

  • List all recently defined actions from memory – Besides gathering a list of actions for further treatment in this retro, the ambitions was to get the thinking going, while getting an impression of which actions we had defined actually seemed important. We used the liberating structure 1-2-4-all, to generate the list.
  • Generate insights on the listed actions – The purpose was to explore the retroactions to build shared understanding of what the next step could be. I wanted to get everybody’s perspective in play, only then can we come to a truly shared understanding. We used the liberating structure What, so what, now what, for that purpose
  • Define individual actions for moving forward – The purpose was to help the team identify small and actionable steps, that could get the ball rolling. We never got to this part in the retro. The conclusions from previous step required a shift in the agenda, more on that later.

The team discovered they had a hard time remembering what actions they had decided on, which let to the conclusion that if they cannot remember the actions, they are not that important. When asking” what is a good next step, what makes sense from here?” The team conclusion was: “Let’s do fewer and shorter retros”.

This has been the conclusions in many teams, it is like a universal and natural thing to conclude. Previously I have reacted to this conclusion with an “I know better, so we’ll continue attitude” or being childish like “Ok, then facilitate it yourself”. Sometimes I even agreed to reducing frequency and length, just to see nothing changed. None of these solutions solved the problem of not getting value out of the retrospective.

The reason for the problem not being solved, should be found in the concept of single- and double-loop learning.

Double loop learning illustration form the Zombie Scrum Survival Guide –

Single-loop learning is about taking actions within the system. Double-loop learning is about challenging the system. In our case we needed to understand why we were not succeeding with our retroactions, as well as setting a base for why we even do retrospectives, before we could determine which frequency and length we should have. Addressing this, was more important than defining actions as planned. So we pivoted.

The questions that helped me bring deeper learning at this retro was the following invitation: “I will gladly change the frequency and length of the retrospective, if we are conscious about why we want to do it, and what we expect from it – not because it is the easiest way out. So in order to get that consciousness we should reflect upon, what are the reasons we don’t get value out of our retros, despite defining small actionable next steps?”

We identified the following challenges preventing us from benefitting more from the retros:

  • Obvious problems are solved during the sprint, leaving an empty space of what to talk about on retros – which is great!
  • Actions are so small that we don’t see they fit in the bigger picture.

This let us to the action, that we as a team need to define the bigger picture. What themes would we like to address on retros, in what areas would we like to improve as a team?

Our action from this retro was to retake the evidence based Scrum Team Survey to help us define the areas where we could improve as a Scrum team. The survey gave us good insight in our improvements since last time, and helped us define new areas to improve.

Because we now have a shared understanding of the bigger picture, as well as shared understanding of why we have retros and what will be discussed in those, our retrospective quality already increased – even without changing format, frequency or length.

Posted in Working as a ScrumMaster

Do I want feedback?

I often express “Please give me some feedback” in relation to my work. Actually most people I work with express this in some form. Obviously because we want to know if we are doing a good job. But when I ask for feedback, a part of me reflects “What if the feedback I will get is not what I want to hear?”. Sometimes it even prevents me from requesting the feedback or postponing it until later. I may even subconsciously ask in a specific way, that will leave no room for true feedback, but only room for stating what I want to hear. And that’s great, because it can keep me out of those awkward moments where I feel undressed in front of a crowd, because I have just realized that I have been doing something wrong for a long time.

I recently had one of these moments. I asked my team about their perceived value of our regular meetings, as well as the format of the meeting. In an anonymous survey. To my big surprise. Retrospective was the meeting that scored lowest of all, both on value and format. I must tell you that it was tough for me, who claims to be a retrospective geek, and put the most effort into preparing and facilitating the retrospective, compared to the other events.

You can imagine, it was NOT a good feeling. It hurt, and lot of thoughts went trough my head:

  • OK, I’ll just let them facilitate the retro themselves (offended like a child).
  • I’m the expert on this, I’ll just tell them and continue what I am doing.
  • What if I never share the survey results – the team might just forget about it.

I then realized that I was just making excuses to NOT take action on the feedback the team had spent their valuable time giving me. And why was that? Because it was tough! It was scary to not know were this would end? I was afraid that I might find out that the team hates everything I do!

But if I call my self a retrospective geek, and I’m a Scrum Master that works for achieving psychological safety in the team, I know I needed to take this challenge head on! I decided to be curious. I decided that this was NOT about me personally. It was about the situation.

Therefore I designed a retro to explore what prevented us from getting value out of the retro. The details about the retro, I’ll save for another post, but it was the most difficult retro. Both for me as the facilitator, but also for the team. The outcome was, that the team was able to express what they felt, and I learned new ways of how I can support the team even better going forward. Awesome.

So, when you are asking for feedback, are you truly asking for feedback, or do you just want your to hear others say that you are doing a good job? Are you avoiding the difficult situations? Or Ignoring the feedback you do get? Or in other ways miss out on opportunities to learn and grow?

Instead ask yourself “how will you approach the feedback, if it something you don’t like to hear, or makes you uncomfortable?”

Posted in Liberating Structures, Purpose-to-practice - Building a New Team

Getting “done” – a key practice

When a new team is formed we hope that it will be long lasting, and that it eventually will become high performing. Sometimes it happens, sometimes it doesn’t. What determines the success? Despite there are no guarantees of success, there are still things you can do to increase the likelihood of your team becoming high performing. In this blog post series, I would like to share some experiences of mine, from starting up new teams. Inspired by the Liberating Structure “Purpose-to-practice” I am helping the newly formed team to design five essential elements to make the team resilient and endurable. The 5 elements are Purpose, Principles, Participants, Structure and Practices. This post will cover my approach to help the team design practice.

Practice are key for success

After all, what we do is what determines our success. Therefore designing the element of “practice” is essential for a teams chances of success. For a Scrum team that wants to harvest the benefits of Scrum, the ability to create a “Done” increment each sprint is essential. This session is specifically designed around the practice of “getting done”. First step, of getting there, is knowing what ‘done’ means, and why it matters, and this is what this session helps explore.

Which structures and why

This session is kicked of with a 1 min self reflection, just to get peoples thinking going, before jumping in to the activity.

The backbone of this session is the Definition of Done exercise made by Christiaan and Barry from The Liberators. This exercise is designed to create transparency of the consequences of not getting to a proper state of “done”. I highly recommend purchasing this exercise (No, im not sponsored. I paid for it myself), as it is also applicable for virtual teams. Specific instructions on how to facilitate is included in the package, so I’ll leave out the details here. Overall the group get a chance to have conversation around mapping typical developer activities to common steps in development process. Hereafter the group will do the same with typical unexpected problems.

I divided my group into four pairs, to give more room for the individual to talk. Each pair did their own mapping.

After the Definition of Done exercise I added the Liberating Structure Min Spec, to help the team form their first Definition of Done. This is for specifying the absolute must do’s to deliver a “Done” Increment, which also is a set of practices we rely on to achieve success.

Facilitation canvas for defining a teams practice – with a focus on “Getting done” as a Software Scrum Team

My observations and experiences

  • The short 1 min silent reflection in the beginning gave participants a chance to “arrive” and tune in to the topic. If time allows, it could be beneficial for the group to share there thoughts with each other.
  • For a non-Scrum team, it might be beneficial to design the session around a broader question, such as “What practices much be in place in order for us to achieve success?”.
  • Putting “Done” as a theme for discussions about practices, allowed me to take the Scrummaster stance of teacher to my scrum team, without being the preacher. This initiated a specific conversation on this essential practice.
  • Depending on experience, the group might need some guidance on which patterns to see from the definition of done exercise.
  • While there are many activities to take into account, for reaching a “done” state, the Min Spec, helped narrow the list in to the truly essential. The list became short enough for the team to actually take ownership for it. It is better to start with a list too short, which can be extended as the team gain experience, rather than making a complete list, which no one will look at because it is too comprehensive.
Posted in Retrospectives

Practicing retrospectives – A retrospective training workshop!

How do one become a good retrospective facilitator? The same way as with anything else you want to master: Practice, Practice and Practice. But when dealing with retrospectives we run into a dilemma: You can’t really practice the execution of a retrospective unless you execute one. And it may seem hard to just throw yourself into trying it, without practicing first.  If you don’t know if you can swim (or simply keep your mouth and nose above the water) would you jump into the ocean?

Previously I have conducted workshops on the topic “facilitating retrospectives” with a combination of teaching theory and facilitating self-reflection. It was alright, but something was missing. Kind of like a swim teacher standing next to the pool telling the group of students how to swim, asking them how they think they are doing, and then telling them to jump in the pool in the deep end. Maybe the student got a few useful tips in the process, but did they learn to swim? Did they get the courage to jump in? Did the ones that jumped in survive?

If I were a swim teacher, I wouldn’t accept that uncertainty, so why should I when trying to share my knowledge on facilitating retrospectives? That’s why I wanted to put together a retrospective workshop where participants could practice preparing, planning and facilitating a retrospective in a safe zone, were total failure did not have any consequences. In the Swimming metaphor, I wanted the students to get into the pool and try swimming without risk of drowning.

In this post I will share the process and some reflections (in italic) I had, for the 4,5-hour workshop I facilitated for the ScrumMaster community in my company. Continue reading “Practicing retrospectives – A retrospective training workshop!”

Posted in Working as a ScrumMaster

ScrumMasters are stupid

Are you a ScrumMaster? Have you chosen to build your career as a ScrumMaster? Yes? Well, that’s stupid! I mean: It is a job where you will always face resistance to change either from your team or from the organization around the team, or even both. They may not even understand the role. In the beginning you might not even truly understand it yourself. The successcriteria of a ScrumMaster is vague, and difficult to navigate after, so you will constantly question if you are doing a good job.

To some, a job like this is self-torture. It can be sometimes, but other times it is the most satisfying job – at least in my opinion. So if you are as stupid as me, and keep on trying, because you think it is the right thing to do, this blog post might be of help to you.

The purpose of this post is NOT making you capable of avoiding the traps I fell in, because I believe you must learn from your own mistakes. Instead I hope it will ease the fight of getting out of the traps, so the learning process for you, will be shorter than it was for me. Or as a minimum you can identify with the challenges, making you aware, that you are not alone – which can give you some energy to hang-on and continue what you are doing. Continue reading “ScrumMasters are stupid”

Posted in Working as a ScrumMaster

Visualisation of “Very very important tasks”

“I have this very important task that needs to get done. Who will do it?”
This is a phrase often heard, and every ScrumMaster eventually will have to deal with. A mature agile team will have it’s work agreements and processes to deal with this type of request in an efficient manner. However, not so mature agile teams, and teams in a early state of their agile journey, should be very alert when hearing this sentence, as it maybe a symptom of an underlying and more serious problems.

But why should we be alert? It’s just <someone> who wants to get this task done, what is wrong with that? Continue reading “Visualisation of “Very very important tasks””

Posted in Working as a ScrumMaster

Doing Scrum – Leading the way – Learning agile

“I have heard Scrum is ‘the thing’, please google it and implement accordingly!”. This was the exact words from a previous boss of mine, when he wanted me to make our team deliver on time and with the desired quality. This was the beginning of my career in “doing Scrum”.

I have learned quite a few lessons since. In this blogpost I will deal with a few of the hardest challenges I have faced. You will most likely not learn from my mistakes, but being aware of them, may help you overcome them faster when you face them. Continue reading “Doing Scrum – Leading the way – Learning agile”

Posted in Working as a ScrumMaster

Let’s call off Scrum!

A software development team, had been “doing Scrum” for years, since it was decided that Scrum was the “way to go”. A classic. All meetings were conducted, but gave no or little value. It was just accepted like “that’s what happens when Scrum meets reality”. Failed sprints were the standard, frustrations were building and unfortunate leadership mecanisms were “needed” to get things done.

When I was appointed as the ScrumMaster, I quickly realised that I had to do something drastically to gain the team’s trust to Scrum, and to build the team’s trust in me, as a ScrumMaster. Especially because I do not have a developer background. I had to relaunch Scrum in a way I had never tried before…

So I said: “Let’s call off Scrum!”

Continue reading “Let’s call off Scrum!”