Posted in Team Dynamics, Working Agile

What a shared purpose can do to your teams

I have often heard managers expressing:

  • I encourage the team to take the responsibility
  • I need you to collaborate with other team

Only to hear the same manager complaining about why it doesn’t happen. Why is that? I mean, the Manager just expressed what they wanted.

There can be many reasons for this. One of them is most likely, that teams are not used to having the responsibility and managers are not used to giving away the responsibility. If managers suddenly give responsibility, it will be awkward, because no one knows how to act. I have seen this situation too many times, which will eventually result in managers taking back the responsibility. “If the team would just take the responsibility as I do, the problems would be solved. But they don’t, and that’s why I have to do it myself.”

The interesting perspective is not who has the blame, the interesting stuff lies in The interesting perspective is not who has the blame, the interesting stuff lies in discovering why this situation happens in the first place. If we understand and truly believe that everyone are doing the best job they can, given the knowledge, skills and abilities and resources available in the situation at hand, then we can free our minds from blaming each other and start investigating the actual causes. So if both managers and teams are acting with good intentions to be more efficient, then why are we often in this situation? Let me elaborate on this using a real life example.

3 software development teams were practicing collaboration and alignment techniques, such as big room planning(Together with other teams as well). The teams were experienced in the techniques, but both managers and teams felt something was not right. Managers would like to see the teams taking more responsibility for the solution, the quality, and the collaboration needed to get done. However, the teams did not feel why all this cross team collaboration was needed, after all the work was already specified, so each team just needed to execute their part. Then, from one day to the other, the teams worked closely together, taking the initiative to coordinate and build the best possible solution to meet the objective and deliver the solution faster than anyone had hoped for. The same people with the same skills, were suddenly able to do what management had longed for.

What made the difference? The main difference was that the management did not have time to prepare. They had to involve teams early, and because of the urgency the management didn’t have the time to specify the solution in as many details as they were used to. I want to stress that this was a real urgency, like losing market opportunities if they didn’t succeed. Not the kind of urgency where a manager picks a random date, and calls it a critical deadline.

Because of this urgency the management acted differently. Instead of specifying what the team should do, they specified the objective they wanted to achieve. They explained very clearly “Why this feature/capability was important to the company and to the customers, and why it was needed fast.”

The teams then instantly started working together. The collaboration practices that did not previously make sense to the teams now made sense. They were now on the same mission, they had a shared purpose of working together, and they knew they couldn’t succeed without each other. Nobody discussed if it was important to meet up, they just met because they needed to, in order to meet the objective.

Also the teams were now making decisions about their work that previously was done by others. The time pressure didn’t allow for the traditional decision making process to take place, there wasn’t time for asking for permission, and after all the objective was clear. This resulted in people with the actual knowledge were the ones making decisions.

If we look at The surprising truth about what motivates us, we will recognize 2 out of the 3 elements that Daniel Pink defines for unlocking intrinsic motivation. The opportunity described above created room for giving the teams a shared purpose, and provided autonomy in the teams to make decisions to meet the objective.

If you are a manager or a Product Owner reading this I would recommend you to figure out how you can help your teams by setting objectives, and explain why the work they need to do is important for the customers and the company, instead of explaining the work you want to be done. Then truly trust that your teams will make the best decisions to make the best solution within the given circumstances. Doing this will help set the purpose and give autonomy to the people with the needed knowledge.

What about Mastery then? All people have a desire to get better at something. Why do one want to get better at playing an instrument? Because it is fun! When creating a (shared) purpose and when providing room for autonomy, you will also create opportunities for learning and growing together and as individuals. The desire to get better will only increase, as it will now serve a purpose!

Despite the significant improvements the organization experienced in my example, there is still lots of room for further improvement. It became nowhere near perfect. But I can’t imagine the magnitude of improvements we would see if we started to define purpose and give autonomy as a deliberate practice, instead of waiting for market opportunities to demand us to do so.

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 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.