Overcoming Anxiety And Fear in Scrum

On February 13, 2010, in Good Advice, by Steffen Itterheim

I just read through the “Making Scrum Stick – Overcoming Anxiety And Fear” article over at InfoQ and wanted to quote a few lines:


Often people in an organization haven’t received any training in simple things like giving and receiving feedback or dealing with conflict – both essential ingredients in a successful, high-performing, self-organizing team.

So true and completely under-appreciated. In my experience as game developer, with my colleagues the things to learn and teach were always about the work at hand. How you create models, how to paint textures, how to write good code, sharing best practices of level design and what not. Not once have i experienced or heard of or even hear people express the desire for training in what is mentioned in the quote: dealing with conflict, praising, reprimanding, motivating, coaching – anything regarding true Leadership.

That is one of the things all team members of any team should learn, right next to the skills required to produce your work. But i suppose it may be part of our society that knowledge does not equal wisdom, and a good worker needs to know how to operate his tools first and foremost – anything beyond that may be seen as luxury, a nice to have item.

Personally, i think it’s the other way around. I’d rather cope with someone’s inability to operate his tools perfectly if i and the rest of the team can work with that person well and everyone simply enjoys working together.


Strangely enough, relatively few people are fearful of being Scrum Masters, despite it being a role that combines a lot of responsibility with no authority. People are most fearful of this role when they are selected for it and either have a poor understanding of what is involved or are not clear on how it is different to their previous role.

I was once asked to become a Scrum Master. I had no idea really what it meant to be a Scrum Master, so i was told: you moderate the daily meetings, see that the 15-minute timebox is kept, make note of any special occurrences, inquire further and then report back to the Manager with anything of note since the Managers do not have time to take part in each and every daily meeting. That was the whole idea of being Scrum Master. I thought it was a dull job to do and so did most others.

Then, end of 2008, i did my own research of what was expected by a Scrum Master. I was blown away. Neither did we get the idea of Scrum Master right, we basically failed at all levels of what we called Scrum. It was at that point that i wanted to become Scrum Master more than anything. Yet how things turned out changing projects three times didn’t help and sadly a few months later a 50% staff cut was announced and that was the end of it.

In the remaining time, when things still seemed as if they were about to change for the better, Scrum-wise – i talked to a few people, some of them were already Scrum Masters and some were set out to become Scrum Master. The reaction was typically that it’s a dull job and no one really wanted to do it. Some felt they did not have the time to do that next to their own work. Others felt anxiety that they’re maybe not the correct person for the job or that they were not succeeding at it.

No one really understood the role of Scrum Master. And we still had all kinds of Manager roles which i now consider a bad sign if you’re adopting Scrum. It’s as if Scrum was a play for the Team who had now additional roles like Product Owners and Scrum Masters who were in many cases team members, yet the Manager roles were left untouched. They continued to do their managing as always, were not integrated into the teams and in the few cases that they were, over time they had so much work to do, they had to remove themselves from the team’s work to get their work done. From what i’ve learned they were also disappointed by the buy-in of Scrum from the team but also came to conclude that many people just want to be told what to do. No wonder if the Team itself has no responsibility, and little to say, and more than a healthy distrust towards Management and their ideas. Actually, the Team had a lot to say but it only served to widen the gap between Team and what was perceived as “Upper” Management – even though we were a rather close group of people.

That just serves to show how much we moved apart from each other in perception only.


The good news is that a Scrum project will come up with a baseline view of how much the project will cost and when it is likely to be finished. The only difference is that we are very explicit right from the start that this is wrong and we will make it better as soon as we start working on it. There is an amazing feeling of relief when we can become comfortable with uncertainty and a freedom to actually discover what is needed at the appropriate time.

I feel this relief each and every day. As freelancer, i have to make proposals based on unpolished, unrefined and prone to be modified project ideas. I have to calculate time and money. Fortunately, i have the experience to come up with a good baseline and then experience tells me to double that, and in the end you’ll finish 20% under time and everyone is happy.

I achieve that by not planning the uncertainty but what i know. The things i know i can put times on and they usually match perfectly. It’s the things i don’t know, those i haven’t accounted for or haven’t looked into in greater detail that are of the greatest risks. What i do is to break them down into smaller tasks, try to consider everything that is involved in it from a high-level and then put on some number on that – in bulk tasks. They’ll be broken down as i go.

The good thing is, for example, if i have a similar feature but one is for single-player mode, i know i can take some shortcuts. If it concerns local multiplayer (same screen) i expect the difficulties to ramp up moderately. For Wifi/Bluetooth multiplayer i’d have to add a lot more to it. To more uncertain or unknowing i am about a feature or technology, the higher the numbers i choose to estimate them with. For example, creating an offline scoreboard with 10 entries is maybe a day’s work even if i include a rough UI layout. I may even be able to finish and polish the UI in the same day.

However, even if i can use some existing online multiplayer highscorelist technology, i would probably shoot for at least 3 days to get the technology working, plus another day for the UI as some things like delays for downloading may force you to consider adding “hourglass” animations while scores are transferred, or disable buttons until the request has been acknowledged, and so on. So a lot more complexity and since i’m already estimating this as 4 days it’ll be a whole week – this one-day buffer is for any unforeseen events. Risks like if the technology i use were only to retrieve one score at a time and didn’t include fetching then Top scores at once, for the sake of an example.


The only way you can get anyone to change is to explain how this change will be beneficial for them – you cannot buy commitment, only compliance

Signed.

Steffen Itterheim
Tagged with:  

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>