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 – zombiescrum.org

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, Retrospectives, Working as a ScrumMaster

Liberating Structures: Design Storyboards – for planning productive meetings and workshops

Liberating Structures fundamentally changed the way I work, and they are helping me becoming successful as Scrum Master and Agile Coach. Liberating Structures are a set of patterns, that allows a group, of any size, to collaborate and self-organise around a topic, problem or challenge, by involving and unleashing the potential of each individual.

The structure Design Storyboards has proven very useful to me, when preparing meetings and workshops. Even though it is designed for a group, this structure fundamentally changed how I prepare to facilitate group gatherings.

It really helps me focus on the goal, and then select the best approach to achieve that. Without this, it is easy to fall in the trap of selecting the structure/activity first, and then missing the goal.

Answering the following questions, help me stay on track. The visual representation that comes out of it, serves as my “facilitation canvas”.

  • What is the purpose of the gathering?
  • What structures would I normally use for this session?
  • What Liberating Structures or other activities could achieve that purpose?
  • Which structure/activity is best suited to achieve the purpose?
  • What would the invitation that will trigger reflections and conversation with many perspectives look like? (See Characteristic of Powerful Invitations for Liberating Structures)
  • What should be asked to debrief if the gathering achieved the purpose?

The answers are recorded in the “storyboard”:

This example is a retrospective, evaluating my team’s newly created Definition of Done, dealing with some of the concerns the team raised: (1) we now have a Definition of Done, but we have tried that before, and it will just go on the wall and we’ll forget about it. (2) our new Definition of Done will not work with ‘backend stories’ so I can’t see how it will work. (3) To what use is our Definition of Done if we are not able to go all the way to done in each sprint?

The visual representation of the planned gathering is a great way to create shared understanding and foster fruitful conversations about what we want to achieve, when planning together with a group.

I have found it hard to use this structure together with people who did not yet discover the power of Liberating Structures or are not familiar with some Liberating Structures. So far I have been preparing on my own, presenting a design storyboard to the group, and then working from there. That is not really the intention, as my opinion will be more dominant, and makes it harder for others to contribute… Yet it is still better than what we use to do.



Posted in Liberating Structures, Working Agile, Working as a ScrumMaster

An approach to kick start the usage of Sprint Goals

Sprint goals proves to be a vital element of Scrum, but it is often overlooked and neglected because it is difficult. This blog post will describe one way to kick-start the use of sprint goals in a team or ScrumMaster CoP. Before I describe the approach I would like to explain the background, that lead me there.

Background

I was blinded by my own approach and I was just executing Scrum in a Zombie like way. In my eagerness of facilitating the events “right” I have forgotten why we were doing this in the first place. I was fallen into the trap, but the content of Barry Overeem and Christiaan Verwisj from The Liberators came to the rescue.

One of the two driving principles as described in their article about the Scrum Framework made me realize that using and working with sprint goals, was something I have neglected, even though I know it is important. Then I listened to the the podcast Scrum Mythbusters: Having A Sprint Goal Is Optional In Scrum. It changed a lot for me. The podcast highlighted many of the challenges I faced together with my teams, and I felt that every sentence was an important point that could help the team. This was too much information for me to remember, and I didn’t want to miss a thing, so I decided to do a graphical recording of the Podcast.

It resulted in 4 posters.

 
 

With these 4 posters in hand, and a topic to important to be forgotten, I had to find a way on how to share this and enable others to reflect upon and start working with spring goals. I ended up with the structure below, which can be used in many settings, such as a Scrum Master Community of Practice, a team or any group that work with or could benefit from working with sprint goals.

My approach to kick-start the usage of Sprint Goals

Purpose: Share the content (in this case about sprint goals) and let participate arrive with their first impressions and conclusion about the topic. This is the foundation for the future development and usage on the topic.

Preparation: Hang up the 4 posters in different places of the room allowing people to walk up to it. If you want to facilitate this online, add the 4 posters to an online white board, where every participant have the access to view.

Step 1 (10 min)

Invite the participants to walk around the room an take in the impressions from the posters. Let them imagine they are on a museum. Encourage to take personal notes.

Step 2 (3×5 min)

Prompt the whole group with one question, and invite the participant to go to the poster that match the answer to the question (1min)

At the the posters, people form small groups (2 to 4) And discuss the topic and the prompt (4 min)

Repeat step 2 three times, using different prompts. Here are the prompts i used:

  • What confuses you the most? Why?
  • What do you feel strongest about? Why?
  • What gave you the most valuable insight? Why?

Step 3 (5 min)

Debrief together, by sharing insights from the group discussions

Step 4 (25 min)

Use the Liberating Structure 15% solutions to help the individuals discover and focus on what each person has the freedom and resources to do now.

  • Explain the concept of 15% solutions (2min)
  • Invite people to make their individual list of possible actions based on inputs and insights from previous discussions. (5min)
  • Share your lists, in groups of 3 (3 min per person)
  • Refine and improve each others lists (actions) (3 min per person)

My reflections

Based on the discussions during the workshop, and feedback afterwards, it seemed like this was a good approach for participants. But why is that? Giving this a few thoughts I have come up with the following

  • It enables participants to drive the change by themselves.
  • It gives any group/team freedom to decide what to focus on – in this case when working with sprint goals.
  • It changes the concept of learning from “teacher to students” to “Emergent learning”, where a group or a team learn together by sharing experiences and perspectives.
  • It allows people to focus on “the first step” in dealing with a difficult topic, and fostering a “one step at the time” approach for the change.

Maybe you have input on why this seem to work well or maybe you have other comments. anyway, it would be great to hear from you.

Posted in Working as a ScrumMaster

More storypoints completed = More effective?

Here are 2 stories…

Story #1

Manager (to team): “I would like you to become more effective!”
Team: “No problem, we’ll just double our story point estimates, then we will complete twice as many points next sprint.”

What will the manager answer?
A. “Great! I’ll say that to my boss”
B. “Well, that really don’t make you more effective, only the metrics changed”

Story #2

“In my team, we use estimates. After the sprint, the manager says: “You did not deliver all you promised”. The team feels bad and decides to increase the estimates as a buffer, to ensure they won’t take too much into the next sprint – without telling the manager. The team completes everything the following sprint and the manager is happy. The next sprint the team silently increase their estimates a bit more, only to complete a higher amount of points at the end of the sprint. The SM and the Manager is really impressed because this team now completes more points than any other team.”

Story 1 is one I made up (kind of), and story 2 I was told by a friend of mine, when he wanted my opinion on the topic “Storypoint inflation”.

Putting it as simple as in story 1, most people will believe B is the best answer – without hesitation – and will not accept the suggested solution to just devalue the story points. But story 2 seems to appear more often, even though the only difference compared to story 1, is the speed of story point inflation. So why does it happen? Continue reading “More storypoints completed = More effective?”

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

Need more details!?

Product Owner: “Please code this feature”.
Developer: “I can’t code this, until I receive a better spec”.
PO: “Just go ahead, I want your input to this as well”
Dev: “Alright”
— Developer codes it like he believes is the best, and show it to the Product Owner —
PO: “Why wasn’t _this_ included?”
Dev: “It wasn’t a part of the spec”
PO: “Well, I think it is kind of obvious, and I wanted your input as well”

Continue reading “Need more details!?”