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.
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.
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”
“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?”→
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”→
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.
“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.
“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”.
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”
— 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”
Imagine you’re in you car and you’re going full speed on the highway. You are listening to a traffic announcement in the radio, telling you, that your planned route is jammed. You know it is the shortest route to your destination, but you are in a hurry to get there fast. What do you do? Continue reading “Driving the Scrum Highway!”→
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.