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!”