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.

Tagged with:  

Scrum in the Games Industry

On June 8, 2009, in Experiences, by Steffen Itterheim

I found a nice presentation on Boris Gloger’s homepage about the “professionalization” of the Games Industry by adopting Scrum:

I specifically liked page 32 “Lack of Visibility” and the following. I can relate to that. He goes on to say that Management’s typical reaction to a slowdown of production is to improve … management itself. This leads to a centralistic, hierarchical, dominant, slow, process driven, non agile company.

I would just like to add that – as sad as it may be – you can still be exactly that company while at the same time doing Scrum. How so?

If … (long sentence warning – keep your concentration) … if your company puts the word out at one point that from now on you’re using Scrum because that’s what others are doing successfully and that you’ll be subdivided into specialized teams and you’ll have daily meetings to improve communication but doesn’t even care to explain how this is going to help your problems or improve how exactly, nor train and coach the developers who are supposed to be living and breathing Scrum how to do just that while at the same time neglecting important parts of Scrum (for example: Sprint Retrospectives) and getting others totally wrong (ScrumMaster as merely keeper of the minutes, reporting back to Management) while giving orders from above and trying to stay “in control” (whatever that means) – then that can only mean one thing: ScrumButt!

At some point i did the Nokia Test for Scrum (PDF) with the information that was visible to me – certainly not applicable to the whole company but needless to say, some parts were even worse off – and with much goodwill the score i got was a mere 3 out of 10. At that time i’d given it just a 2 because we didn’t even do iterations anymore for a short time. Reason? We finished the product and were now only testing and bugfixing which apparently isn’t plannable anyway so you can just drop the iterations altogether, right? That makes a couple more hours each Sprint for managers to catch up because you don’t have to do a Sprint Planning meeting.

In that regard i can understand where the lack of buy-in from Game Developers to Scrum is coming from. My point is, if you take it out on Scrum because what you’re doing carries the name “Scrum” and you just don’t like it – take 10 minutes and do the Nokia Test for Scrum (still the same PDF – i’m giving you a second chance, take it!).

If you don’t score at least a 6 or 7, your problem isn’t Scrum – it’s your management!

PS: with that last sentence “your problem isn’t Scrum – it’s your management!” i was tempted to add some “maybe”s and “probably”s there. I didn’t, on purpose. I want to make a point. I know some people just don’t like Scrum, they do exist and i can understand and respect that. But i’m a firm believer that those who don’t like Scrum, well most of them apparently haven’t experienced the “good Scrum”, given the traces of information they leave in their blog posts and comments.


UPDATE: here’s a longer presentation with more of the same content, also from Boris Gloger:

Self-Management leads to Self-Loathing

On January 29, 2009, in Opinion Pieces, by Steffen Itterheim

“Ok, we’ll do Scrum from now on. Team, you manage yourself now!”

Uhm … yeah.

This is exaggerated what i feel has happened to me personally. I say this because i can’t speak for the rest of the team i work with but i’m very certain that i’m not the only one feeling the effects.

What effects?

Like, feeling overwhelmed, for example. Needing someone who you can at least talk to, in an ideal case to share some work as well, in order to keep things in check. Managing everything that is thrown at you yourself … well, in my case, it eats away a lot of time and energy. I’ve tried both … reducing the self-management clearly doesn’t work and reducing the quality in my work isn’t satisfying either. However, either of the two have to suffer. Or both.

It’s not that i’ve had to do too much work to do. I certainly didn’t need to go into “crunch” mode. No. I’m talking about a different kind of stress that appears when you are trying to manage all sorts of requests and bug reports from all kinds of people on the team, sometimes even outside of the team, and then also trying to go about your normal (expected) line of work.

When i was looking for help, the typical response was “Please take care of that yourself.”. Yes, we are an empowered team. (but are we? after re-reading this, i have my doubts) … However, there are times when you need help, and you may not know how to express it other than crying for “Help!” in some way or another. You know, who is able to exactly say why things feel like they’re going out of control, at the moment the control is being lost? So yes, being told to take care of it yourself – it’s in a way correct and it works but it also offloads a shitload of responsibility to me that i wasn’t looking for, with no way to defend against it. Plus now i feel bad because i had to be told to clean up my own mess. Thanks mommy (not!), for the friendly reminder …

The work i do – on at least 4 major code components and tools – plus a little managing people on the side, is regularly too much weight to manage all by myself. I simply have too many open loose ends, or strings that could break any moment, sometimes also things that i ignored because there was no time but they keep coming back at the worst of times. Behind each of these ends and strings is more than just one stakeholder, any of which could approach me at any given moment in time. These open ends and lingering work and ghostly popping in of stakeholders creates a lot of ongoing tension and unease. There’s a lot of people asking for information or support from me because two of the things (Scripting, Database) i worked on are very central things for the work we do and are used by a lot of people. Roughly 20-30 at any given time. Add to that such hot topics as localization and the process to get it safely through translation, proofreading and correctly back into the database.

And now please tell me again why i don’t need a person who keeps these things away from me as long as possible. In other words: a filter, a gatekeeper, a human shield … an effective Scrum Master!

It’s all those daily little disturbances, questions, small requests, the different stakeholders at play and what not that really drain the energy from me pretty quickly. Plus it disturbes my concentration, and that is often key to getting anything but the basic stuff done with quality (remember: i’m a coder). So to cope, what i did is to drop quality (heya, Mr. Schwaber, sound familiar?). Unnoticeable at first but once you have one of those days where everything seems to be going downhill, there’s just no room for testing, following up, looking for alternate solutions. At times like these i basically stopped caring for the work i do. On the other hand, i never did, but occassionally i get asked by peers wether i still care about the work i do – which hurts even more because i do, i really do, it’s just … i can’t. It’s sometimes impossible to care because if i would, i would … go crazy!

Now this whole situation isn’t as dramatic as it may sound but for me personally, there are days where it really feels like the end of the world is upon me. While from the outside it may seem to work pretty well indeed, i can imagine. Sometimes i even get praise for doing the work so quickly, so effectively. And this praise fed to my self-loathing because it’s just not true. I mean, it’s not what i feel to be true. Little do they know … about the quality that is lost. About the missed opportunities. About … almost anything, i fear. Rightfully?

Well, it’s still praise but it feels like … damnation. And it’s not like i’m hiding anything. I can say what i do, and why i did it and i stand by it. I understand the psychology behind it. Luckily, by researching Scrum over Xmas i finally understood why it happened to me and how i should be able to solve it. Also, i’ve been working in teams before that worked well together with little outside disturbance. So it’s definetely possible.

Inside of me, i carry a little flaming ball of hatred for how we’re working that continuously gives off some energy that i try to transform into positive feedback for the things that work well, and the rest i take as incentive to change the things that don’t work.

If, from reading all of this, you have deduced that we either have Scrum Masters not doing the work that i believe they are supposed to do, or no Scrum Masters at all – you are correct. Both cases apply. I don’t blame it on them though, they are typically really great peers and do a great job … but i’m not sure they understood the importance of being Scrum Masters, or what they’re supposed to do, or maybe there’s other things keeping them from achieving true Scrum Mastery. It’s probably simply because most of them are managers and have a shitload of managing to do and just wish (*beg*) the team would work all by themselves. And the few Scrum Masters who are members of the team, they don’t even know what it means to be a Scrum Master. They haven’t been told. They got no training. They aren’t coached and mentored. The whole team never actually learned about Scrum. This is our number 1 mistake!

The good thing is: i may become a Scrum Master myself soon, and i know what i want to achieve, and i think i know how it can be achieved – and i’m ready to step onto some toes if need be. But most of all, i want to lead by example, and make it unmistakebly clear where our problems are and how i would go about solving them.

Because i have nothing to lose!

My New Year’s resolution – i haven’t told many people so far – is to make a difference in 2009. For the benefit of the team. If i fail, or the resistance is too high, or things change too slowly, or it drags me down too much – i’ll be looking for someplace else to work! End of 2009 will be the time for revisiting, and making a decision. This is the deadline i’m working towards.

But …. don’t get me wrong! I love my work. I love what we do, i think we have great talent in the team and many have the right mindset. We just don’t know how to get the most out of it. In some areas, we’re pretty much blind and deaf. Day-to-day work efforts make us miss opportunities for improving or executing long-term goals. I want to change that because i really want this, my job, the team, the work we do, to go forward. This fuels my little ball of flaming hatred. I see the wasteland before me. And i don’t want to have to decide to quit my job at the end of the year!

Through my experience from last year, or the last two years, i decided that my number one priority when working as a Scrum Master should be: shielding the team from outside influences. I will have to become the bad conscience to those who can’t be held back, just to raise awareness that this isn’t the normal way to do things anymore, it’s the exception!

On second place comes training, coaching, providing feedback – actually anything that raises awareness and allows the team to truely manage itself – making sure everyone is aware of how we work and why we work that way and accepts it even if some might not like it. About everything else, we can talk, and we should.


PS: check that Scrum Resources link to the left if you are curious to know what Scrum is and/or if you intend to learn more about it.

Tagged with:  
Page 1 of 212