“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.
August, 2006 – Phenomic acquired by EA – the product we pitched was a trading card RTS game with the working title BattleForge.
November, 2008 – BattleForge is still the title of the game and the beta is receiving welcome amount of attention from the beta participants.
It’s been over two years in development. We have changed so much in two years. We as in “we as a team”. New development methodologies were introduced, adapted and improved. Colleagues got married, babies were born. Some were not so fortunate and parted ways. Some decided to leave Phenomic to pursue other interests. Some came back after their internship. Some took on new roles, new responsibilities. Some went to visit other EA studios or presented our game to the public and press. They always came back with lots of positive feedback. My tasklist is slowly disintegrating. Last time i looked i have one lonely C bug left. I am about to move on … to another project in a new role. Time to reminisce!
One of the things that did not change was the vision for the game and correspondingly it’s name. I don’t know if there has been a decision to keep the name, but frankly speaking it somehow fits well into the BattleField line of games, and in a way we borrowed BattleField’s distinctiveness and extended it into the Realtime Strategy and fantasy realms.
From my perspective BattleForge has become the game we wanted to make. Granted, in our eyes it still has so many rough edges and unpolished surfaces … but we’re also looking at it through a magnifying lense, like the jeweler inspects his rough diamond. He sees imperfections where others see a jewel. It’s always hard for us to look at our game for what it is, and not looking through the lense, not being overwhelmed by the number of tasks and bugs that are still in our system. Not looking at the small imperfections, gloating over them. We are developers, we are perfectionists – in a way we can’t help it.
For me personally, the move to EA has opened up ways to grow in an environment that fosters growth. At the end of 2006 i was still a “junior” programmer, moving from the Level Design position to become a full-time programmer. I’ve had experience with Lua and C# and wrote our Script System and several tools. It seemed logical to continue with tools programming. But it took some time getting acquainted with the new job. I still remember that i was tasked to build our asset pipeline. I quickly discovered that this isn’t the kind of tool i wanted to work on. It was too technical, too low-level. It has no users at that point other than to be run automatically on our server.
I switched to working with our database frontend tool. That meant learning database concepts, SQL, Hibernate and also C# and .NET and several 3rd party UI libraries. If i had known back then that this tool would pose even more technical challenges, high expecations from users and numerous conflicts of interests when trying to balance technical design with user interface issues. It’s only now, almost two years later, that our new intern discovers all the oddities and design decisions which enables me to really look at it and see where i have succeeded, and where i gave up. Sometimes there was just no time to dig deeper. Other times i must have been in a certain state of mind, accepting ill-conceived notions of how things work that i don’t fully understand. It takes time to understand. It takes a different perspective. On the other hand … despite all the learning-in-progress that you can see all over the code, it was a success. It is stable, it is flexible, it scales well although performance issues did start to show when we added localization. And the dynamic UI did not scale as much with the enormous amount of data we are dealing with – much more than we initially estimated. But there is always a way, always a solution. The only limiting factor is time.
In late 2007 i switched to C++ for a few months and refactored and basically re-engineered our Script engine interface in C++. Here it was easy going, maybe a little bit too easy because some of the plug-in functionality was probably overdone and not used as much – on the other hand BattleForge will continuously be worked on so i hope that it will pay off in the long run. I knew exactly what i wanted to achieve, which things needed to be improved over our SpellForce scripting engine both because it made things easier for us and more powerful. Some of that power was absolutely necessary given the design -the little coop scripting we did in SpellForce 2 showed severe limitations of our scripting system regarding a scripting in a multiplayer environment. The BattleForge scripting system got the needed overhaul, and then some.
I believe in fall 2006 i evaluated, installed, administered, improved and costumized our wiki system. I was one of those who openly campaigned against our first wiki installation maybe another two years earlier. Back then we used TikiWiki which was coder-friendly but utterly user-unfriendly, irky syntax only coders can relate to, it was easy to mess things up. This time we went with a commercial product, one that has a true WYSIWYG Rich Text editor, markup syntax that is as simple as it can be, plug-in functionality to add nifty things like checklists, galleries, collapsing paragraphs, voting and so on. It was still complex enough so that i gave our staff training sessions and open support. Even today people occasionally come to me to ask me about the Wiki. It’s become ubiquitous.
On a personal level … i learned a lot about how emotional work can be. How i and others react in certain situations under varying circumstances. How frustration and anger come quickly with stress and fear of failure. How subjectively success and failure are perceived in general. How people tend to exaggerate. To blow things out of proportion. How others perceive “their” world and how they want me to share theirs. Gradually i had to learn to stand ground, or risk falling over. I learned that there can be demand and expecations hiding behind an innocent question. But I also hat to learn that most of the time, it’s just an innocent question and everything behind it the memory of a bad experience. But sometimes even innocent questions can be very demanding, when they show how little has been learned, or how much of my sanity it will cost me to answer it.
Managing expectations is probably the single most important skill you have to have when you have a costumer – even if it is an internal costumer. I learned that under-promise and over-deliver really works and makes everyone happier and more productive. You have to leave room – especially mentally – to be able to react to the people around you. To be able to help them when they need it. To enable them to help themselves so i don’t need to anymore. I was surprised about the number of issues i’ve got in the last months from our Level Designers – there were so few compared to previous projects, and most were easily solved.
It’s also hard work. The hardest work of all is being and staying a professional with what i do. It’s not their fault, it’s mine. Of course, there are exceptions but this is the general rule. It’s my fault. I didn’t teach you. I didn’t tell you. I didn’t understand you. I didn’t have to when i should. I shouldn’t have when i did. I dig it.
Still learning, though … always will be.
Hi And Welcome!
Recent Comments