Posted in Liberating Structures

Liberating Structures – Min Specs for Definition of Ready

I have realized that Liberating Structures are helping me with being a more successful ScrumMaster. I have written about my experienced benefits of Liberating Structures as concept, as well as links to useful resources in the first post of this series. This post is about my experiences and reflection on a specific Liberating Structure. The primary reason for writing about it is for the sake of my own reflection. If you can use it as well, that’s awesome. Also, if you disagree, have questions, or if you spot room for improvement, don’t hesitate to comment.

Context and reason for choosing

The team had previously identified the need of having a Definition of Ready. Previous attempts in making a Definition of Ready has resulted in a poor list, which the team stopped referring to quickly after the meeting. And when a team member mentioned the need of a Definition of Ready, heated and unfruitful discussions emerged about should we have it or not?; What should it contain, and what not?

As a Scrum Master I needed to find a way to facilitate a discussion that gave everybody equal possibility of contributing; a feeling of being heard; ownership for decisions made, as well as doing it effectively, to avoid wasting time of worthless discussions.

The “Min Spec” is designed to Specify only the absolute “must do’s” and “must not do’s” for achieving a specific purpose so I chose this for the Team’s Definition of Ready workshop.

The group consisted of 4 people in the room, and 2 via skype, and me (facilitator)

Steps and reflections

I highly recommend to read the original Min Spec description from the inventors, which I used as basis for this Definition of Ready workshop. Below I have listed the steps I went through, along with my reflections.

My personal notes, for facilitating the Min Specs

Check-in: Ask participants to shout out “Why do we need a Definition of Ready”, and noting their answers to a flipchart. (5min)
This step is not actually a part of the Min Specs, but I chose to do it, to get participants in the right mood for the session. It also gave the team a common purpose for the session, so discussions about “Do we need it at all?” was not broad up during the rest of the meeting, as previously experienced.

Invitation: “Let’s begin by exploring all potential subjects for a definition of ready. Make your own individual list” (2-3 minutes)
Participants were using sticky notes and markers. The making of individual list gave participants time to reflect on their own, and a chance to work with their contributions, before having to speak out.

Invitation: “Let’s consolidate the individual list to make one long list, as long as possible. Duplicates are removed” (5 min).
Using the phrase “a list as long as possible” focused the attention to compare post-it’s but without evaluating if they were good ideas. The long list served as a common base, for the further discussion, and we had only spent 10 minutes, on something we previously could have used hours to reach. The energy got high in the room, as we were progressing faster than ever

Invitation: “If we broke this rule would we still be able to succeed? (app. 30min)
This question was the turnaround for the team. The team discussed each item one by one, in beginning with too many details, but after a reminder to be “more aggressive” the pace became faster. This made room for discussing the important things, rather than wasting time on things the team already agreed.

The team realised during the talk, that removal of an item, didn’t mean “Not important” or “Irrelevant”, It just meant, it is “not a must do”. This realisation led to changing the wordings on some items, turning them into must-do-action, and thereby more relevant for the team.

Closing: “This is now our must-do list – let’s bring it to the next refinement!”
At the end, the team owned the list. It was theirs. It made sense to them, because they could see how being strict about following this list would make them do only the bare minimum effort for making a story, but still leaving room for doing more if relevant for that specific story. In other words, the list was not limiting the team, it was fostering the open and creative dialogue needed to come up with better solutions. As closing it was enough just to sum up what the team already felt.

The “Min Spec” approach allowed everybody in the group to…

  • Contribute equally
  • Feel heard by the group
  • feel and take ownership for the groups decision
  • Feel their time was well spent

This is now my go-to process for Definitions of ready/Done. I also intend to use this approach for MVP discussions, and for discussing skills needed when looking for a new team member.

Posted in Liberating Structures

How to involve and unleash everyone in a group

As a team facilitator, your responsibility is to ensure that everybody in the group

  • Has equal possibilities to contribute
  • Feel that their input has been heard
  • Take ownership for whatever decision the group makes
  • Feel their time is well spent – Efficient and valuable

Seem like a big responsibility, and if the list makes you feel a bit anxious, I perfectly understand it, because I feel the same way. Yet, I need to say, there is more to it. Today’s world is changing faster than ever, and everybody needs to move faster. This also calls for a need to be able to foster “Creativity and Innovation” when facilitating.

Did you lose your breath now? I almost did, just by writing it!

When it comes to facilitating retrospectives, I have a decent toolbox to pick from to achieve some or all from the list above. However, I have been struggling to find ways on how to ensure equal contribution, ownership for decisions, efficient processes and room for creative thinking, outside of the retrospective.

Søren Weiss, who is an agile coach, change agent and someone who inspires me a lot, introduced me to Liberating structures. It changed everything.

Looking back at the situation before I was introduced to Liberating Structures my “go to methods” was not as effective, as I could wish for, and I can now identify some of the patterns, that weren’t helping me. I tried different things, with some success, but still ending in this pattern, or variations of it.

  • Presenting my thoughts and my perception of the situation which justifies my selection for processes and activities. I am the only one talking, and I don’t get to hear the team members perception of the situation.
  • And then I ask the team about their perception to have an open discussion. It tends to be words of the most outspoken people that often shapes the next steps. Leaving the uncertainty: Did we really explore all options?
  • Then I tend to manage the discussion by asking specific people about their opinion. Then I’m suddenly in charge of who can speak and when. And since I don’t know what everybody is thinking, how can I ensure that people get to talk when they have something on their mind?

So, what is Liberating Structures?

Liberating structures is a set of structures that allows everybody to be involved and contribute equally, as well as unleashing the creative and innovative potential in the individuals and in the group. And because of this it makes the individual take more ownership on the groups decisions. And this goes for groups in any size

It was almost to good to be true, but after reading about it, and trying a few of the structures on my own in smaller group I must say, that so far Liberating Structures live up to what they promise. I can’t wait to expand the use in larger groups, once I get a chance. If you are a ScrumMaster, Team coach, Agile Coach or facilitator, the chances are high that you’ll find these structures valuable to your work too.

If you want to know more about the concept of Liberating Structures, I suggest that you go to for the original source, or visit “The liberators” and their introduction to liberating structures.

My personal key insights and reminders

My adventure with exploring liberating structures has only just begun. I am eager to learn more, to truly understand and master them, because I see they have great potential. Some of the new insights and the ‘reminders’ that stands out as the most important to me right now are…

  • When preparing for a session or workshop, don’t plan to control content. Plan to achieve a purpose and not to get to a specific conclusion.
  • During facilitation, make the invite, and step back. Let the group unfold.
  • Liberating structures breaks the limits of conventional meeting structures such as presentations, open discussions, and managed discussion by removing limitations and barrier for contributing – Awesome!

I’m still exploring the concept of Liberating structures and trying to figure out how I can use them in my daily work as a ScrumMaster. I see the potential to use them not only in retrospectives, but other Scrum ceremonies, group discussions, department meetings etc.

In the following posts on this blog I will write my reflections on my experience with the Liberating Structures that I have tried so far, and how I have used them in my daily work as ScrumMaster.

Posted in Uncategorized

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?

Before I elaborate on that I will say that I see indications of a company not having an agile mindset – They might be “doing agile” rather than “being agile”. That will be wrong for me to conclude with my limited knowledge about their situation, and it will be naive to think that a few words about “Storypoint inflation” and “Commitment” could solve their challenges. Having said that, I still believe that these few words on the topic, could be a first small step, to changing the mindset in an organization like that. And here is how I would go by it as a ScrumMaster.

  • Coaching the team and the manager to believe the “sprint commitment” is a forecast rather than a promise.
  • Ensuring storypoint estimates are for the team, and the team only!
  • Fulfilling the managers need for measuring effectiveness.

Coaching the team and the manager to believe the “sprint commitment” is a forecast rather than a promise.

If the manager, the product owner, or a team member, or anybody else for that matter, treat sprint commitment as a “promise of delivery”, “commitment” is not used as intended. In software development we never build something that we have done before. Therefore I find it difficult to believe that we can foresee everything, and that makes it hard to make a “promise to deliver”. Though, it should still be the goal to deliver. We should have the intention of delivering, including considering and talking about what makes it possible or not.

Theres a good read, of why “Commitment” was changed to “Forecast” in the 2011 Scrum Guide. Commitment vs. forecast on

If you think this means, commitment is no longer needed, you might want to read this as well: Scrum values – Commitment from

Coaching the team and people around the team to use “Forecast” instead of “Commitment” (as a promise to deliver) can give the team the space they need to focus on developing good software. If the manager is still in a need to know about progress, and when the team can deliver, Invite him/her to join a demo, so he/she can see the product. After all, the primary measure of progress should be working software.

Ensuring storypoint estimates are for the team, and the team only!

Storypoints is NOT a metric for measuring effectiveness, and it should NOT be used for reporting to management. I can’t state this clear enough. Nevertheless, this seems to be the case a lot of places. I think it´s because storypoint estimates are numbers, that are easy to work with, if you come from a traditional way of working with projects. But this way of using storypoints, causes some uintended problematic behaviour.  So, what to do about it?

Storypoint estimation is a tool for the team. It serves two main purposes. It is a tool to get a good dialogue going in the team, and it is a tool for forecasting. Everybody around the team must understand that the estimates made by the team, is for the team only. Any interferences with the estimate and/or estimation process from someone outside the team, is in risk of resulting in storypoint inflation.

Does a team even need storypoint estimation? No! If the team have sufficient dialogue, and is able to make forecasts to managers and other stakeholders, the team does not need to do estimates at all. One way of finding out, if the team needs it, is by stop doing it, for a fixed timebox, and then evaluate. If not all aspects are covered during team dialouge, it might be a good idea to use Storypoint estimation.

Fulfilling the managers need for measuring effectiveness.

So now we have made the manager and other stakeholders understands that a “forecast” is something we aim for, which is not the same as a promise. The team are now estimating storypoints only for the purpose of the teams own dialogue, and as a tool for forecasting, and only if they benefit from it themselves. But the manager still needs to report to his manager how effective the team is working and now we’ve just left him hanging there. Some might argue that is should not be needed for the manager to know this, or that managers are not needed at all, but I’ll bet you will have a hard time explaining this to the manager. And if we cannot change the organisation, we have to deal with it somehow.

So, what if the manger asks: “How effective is the team at this point?”, and the team could answer “We’re at 87%”, Would that work?

My good friend and ScrumMaster colleague, Lars Buhl Schamaitat, made this short presentation, and if you can relate to some of the challenges in this post, this might be of your interest. Enjoy

Posted in Uncategorized

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.

Trap 1: Believing you have the skills to change the world after a 2 day ScrumMaster course

How could I be so naive to think that a 2 days ScrumMaster course would solve all the challenges I faced in my team? Writing this sentence seems so stupid, but nevertheless, I felt I knew everything, and I had it all figured out – If just my colleagues would do as I instructed them to.

Looking back now, it was not surprising that I faced a lot of confrontations, when I told businessowners, that have been in business for many years, to change their way of working, based on the 2 days course I have attended.

I learned, the hard way, that being a ScrumMaster is an area of expertise, and I didn’t have the skills at the time to change anything, so my ScrumMaster career could easily have ended there. But my belief, that this way of working would mean better products and higher jobsatisfaction, was still intact, and it kept me in business. I was longing to dig deeper into Scrum and other agile practices to gain knowledge, and experiment with my team to change the world a little by little – Starting with the “world of the team”.

Be humble and let your lack of skills, be the motivator to develop yourself.

Trap 2: Being afraid of “Scrum-buts”

I met the term “Scrum-but” on slide 2, on my Certified ScrumMaster Training. It could be due to my lack of knowledge at the time, or the communication skills of the trainer (or both), that let me to think that deviating from Scrum was dangerous. “Dangerous” like somebody would die. I went home from the training believing that I needed to implement the entire Scrum-guide, word by word. At any cost. When entering Scrum forums and debates online I also get the impression that some other people went home with the same feeling.

Guess what? Nobody dies from deviating from Scrum. In worst case you won’t get all the benefits from Scrum, if you’re leaving things out or doing it differently than prescribed. That doesn’t mean that deviating won’t be the right thing to do in your team. The team might not be mature enough to cope with a full implementation. If the team hate a specific ceremony, or don’t get it – then don’t do it. Show them you care about their valuable time. Introduce the ceremony again when the team feels a need for it, or it can help the team solve a specific problem.

Of course, you should know what Scrum is, and what is isn’t. And of course, you are not allowed to state that Scrum doesn’t work until you have tried a full implementation. And if you are stating it doesn’t work, you are most likely doing something wrong.

Don’t be afraid of Scrum-Buts – be aware. Don’t be afraid of deviating –  experiment, inspect and adapt.

Trap 3: Getting too excited about a tool

During the journey of building your ScrumMaster toolbox – I’m not talking about the physical box of sticky notes and markers, I’m talking about the toolbox of agile tools, practices, methods, theories, activities etc. – you occasionally run into a tool that inspires you so much that you cannot help introducing it to your team. Only to find out that the team hates it and/or find it useless and resists using it.

It is frustrating to see your teammates don’t “see the light”, and the backbone reaction of a ScrumMaster is often to try to convince them. I have done this several times, and unfortunately I don’t think I have done it for the last time. Preaching is not helping – You will waste your time like a Christian trying to convince a Muslim to convert (or vice versa).

The reason for the team not wanting to use the tool, could be either because they don’t see the problem, the problem doesn’t even exist or simply because they don’t think the tool can solve the problem.

Therefore, when trying out new tools, ask yourself: What problem is it going to solve? Does the rest of the team share the same problem?

If you can’t answer the first question, don’t even bother implementing the tool. If the answer to the second question is no, then either let it go, or help the team see the problem before experimenting with the tool.

Trap 4: Not acknowledging peoples thoughts or perspective

As a dedicated ScrumMaster you are most likely a few steps ahead on your agile journey compared to your teammates. This can easily end in a situation where you say: “Yeah yeah, I understand, but here is what you should do”. Your suggested action might be the correct one, but it slips over the head of your teammate and nothing happens.

In the beginning I was getting frustrated of why my teammates wouldn’t listen – after all I studied this subject, so I knew what I was talking about. I tried to explain solutions to problems I spotted. But I couldn’t solve the problems I spotted, and even worse, my teammates felt I wasn’t solving their problems either. After I started caring more for what they saw as problems instead of what I thought was the problem, it was a lot easier to help the team. Asking questions to my teammates rather than explaining solutions helped me identify and solve the real problems. It also helped me selecting the right tools to solve problems. I still see problems the team doesn’t see, but I tend to prioritize doing something about the problems the team sees. Simply because the effect is greater.

Acknowledge your teammates thoughts and perspective and care about them as if they were your own, will help you become a great ScrumMaster. If you spot a problem, ask you team if the see the problem too. If they don’t, acknowledge it and let go, for a while.

Final thoughts

If you made it so far reading this post, I assume that you are still hooked on a career as a ScrumMaster. That’s great. You have at least showed persistence to some degree – keep it up, you are going to need it. But I’ll tell you, the reward of seeing your teammates or organization benefit from your work, even in small scale, makes it totally worth the effort. I have even come to a point where I enjoy the resistance and see it as the next hurdle I need to jump – but it may also just be stupidity in disguise.

Posted in Uncategorized

Agile or Not – Retrospectives is key!

As human beings, it is our nature to learn. We start learning when we are small, we learn as we grow up, and even as adults. We learn about life – to make decisions. We learn more – to make better decisions than previously. We do it all the time. It’s our nature. We are hardwired with this skill.

Regardless how natural this come to us when it’s about daily life, and only ourselves involved, it becomes something extremely difficult, for many many people when we put ourselves in a workplace together with other people.

This could be the result of “management” – The command and control kind of management, that manages and control people. It kills initiative from individuals and it kills creativity.  Which again will result in poor performance, for the individual, the team, the department and the company.

If you have been studying “agile”, whether it’s Scrum, Kanban, SAFe or any other agile framework, you will notice that when you cut it to the bone, it’s all about creating environment for – you guessed it – learning. It is about learning as an individual, a team, a department or an entire organisation, learning about  your product, learning about your work processes. Learning, so you can make better decisions in the future.

Implementing an agile framework prove to be “not as easy as it sounds”. Not because it is of no value, but because it requires change. Change in behavior, change in mindset, organisational changes and more.

Maybe you have tried agile methods and found “it wasn’t for you”, maybe you are already in the process of implementing agile methods, or maybe you just don’t see the point. Nevertheless I believe you would like, your team would like and/or your organisation would like learning to make better decisions in the future. Luckily there is a very powerful tool, which you can implement regardless of which agile framework you are using or not using.

It is called “Retrospective”.

It is a powerful tool which is about gathering people, for a fixed period of time and have them reflect upon and learn about “they way we work”, and based on that decide small things that can be done differently next time. And then keep doing it.

If will foster individual initiative. It will boost creativity. Empowering people through well conducted retrospectives will eventually make you team, department, product, projects and/or organisations better. Nice!

To get started you need:

Doing retrospectives does not solve your problems by it self. But it will help you uncover known and unknown circumstances that have impact on whether you perform good or bad. Based on your findings (learning), you can decide on what to do differently.

Posted in Uncategorized

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?

There is nothing wrong with the desire to get things done. After all, this is what companies live from. But there are many underlying problems that this particular sentence can be a symptom of.

In a software development team of mine, we faced failed sprints. Every 2 weeks. Mostly due to this type of requests. Ever changing priorities was one reason for not meeting sprint goals. The solution to this, according to the “Scrumbook”, is obviously to lock scope of work for a sprint, and move the incoming requests to succeeding sprints. This just didn’t work for us. Developers felt this was the same as saying “No, your tasks is not important”, and product management did not like to hear that. It worked for nobody. We did not have a full time product owner, which was also a part of the problem. I have written about this subject in another blog post

All tasks are important, otherwise it won’t be a task in the first place. Therefore the argument “I have this very important task” is not an argument for getting the task first in line. Believe it or not, adding another “very” or even “very very very” doesn’t make the argument better. So let’s stop discussing if a task is important, let’s discuss how important is it compared to the other task we have, seen from a company perspective. This may sound simple, and result in what we know as a “prioritised backlog”, but it can prove to be difficult to understand for some – even people with agile training.

It was a big issue being part of a team who got “slammed in the face” every other week with “The sprint failed – Again”. So to keep our motivation up, we decided to kill “sprints”. With that decision our board turned into a plain kanban board, where the highest priority was on top. This gave instant advantages such as:

  • As developers we could say, “We can do the task, it will be placed on our board”
  • Product management no longer felt their tasks was not taken seriously.
  • Priorities became very visible, and a constructive dialogue instantly began.

Even though the amount of task on the board exploded, it was a relief for the team, because, we were able to focus on the task on the top of the board, and we could be flexible. As product Management experienced that the tasks on the top of the board got done quicker that the others, they began discussing priorities from a company perspective rather than a personal perspective.

The visualisation of work was the first step towards managing the flow of work, rather than managing people to do the work.







Posted in Uncategorized

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 Uncategorized

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

Posted in Uncategorized

Lack of Product owner – What to do?

I often hear from ScrumMasters and Agile Coaches stating, that you cannot have a succesful Scrum implementation without a Product Owner. The importance of the Product Owner can not be discussed, but there are “everyday situations” out there where a Product Owner for some reason is not available, as much as desired, and for sure won’t be for  period of time. Telling the Product Owner to be more available won’t help anything, and calling off the desire of becoming more agile, doesn’t seem to be the solution as well.

Continue reading “Lack of Product owner – What to do?”