Random Ramblings About Making Games and Stuff from Cloud

Posts tagged ‘agility’

Trust is stronger than control

We producers tend trust processes and forget that trust, communication, skill and determination is a huge thing. We tend to rely on Scrum, Kanpan or similar over persons skill and expertise. I know I did. I truly believe that we try to learn from the past projects and even postmortems written by kind folk in Gamasutra, but we usually miss the true reasons why we fail in a game dev projects.

Making software is hard. Making games is damn near impossible. We keep making mistakes and we try to find reasons and that is what we are supposed to do. The things where we usually make mistakes are not the ones that following a processes will solve. Problem might be that we really don’t know how to make a fun game. We know how to make games and we want to believe that we know what a is a fun game, but ultimately it is the players that will tell us how we did. When we fail we tend to take a good look on what went wrong and make adjustments on the processes. While reflecting the past is a good idea we tend to dismiss the persons behind the process. Usually its not that mistake was made because we did not have full control over what happened. More often reason is that direction, goals or communication was not clear. In some cases we just did not have the skills or knowledge. I don’t think that these situations can be solved with adding more and more control by fixing processes.

In my opinion processes should not be treated like silver bullets that work all the time with different companies, projects and team members. No process is a substitute for skill, motivation, communication and ownership. If the team and its members don’t want or know how to or are not allowed to make a fun game I believe it can’t be done with any processes. Using strict processes might tell you that project is not going according to plan, but it will not launch a game. I challenge you to find what works best with your team and with each member of the team and heavily modify the ways you currently work if needed. It will not be easy but as I found it will pay off in the end. The process should give all the people in the team clear goals, improve communication and build trust. In most of companies I used to work we used processes to get control over team, games design direction, get visibility on how well team did their work and usually people actually working in the team did not find them that useful.

I was recently fortunate enough to work with a dream team and it opened my eyes. We managed to launch a top quality game in nine months with next to no pre-production. During that time I had one of the easiest projects in my producer experience. It was odd since we had a hard launch with fixed deadline and a brand that demanded excellence on quality and fun factor. Reason why it was easy was that I was able to truly trust that team was doing their best. Even when the game’s design direction was fluctuating quite a bit, I managed to remain calm because I knew that the team believed it was the best thing to do. I could fully focus on producing: foreseeing possible problems, getting help to the team when needed, reminding the team about goals and schedule, communicate what are we doing and why to the rest of the company and keeping the troops fed, happy and eyes on the big picture.

After our nine months game project I believe I have a hunch on how game projects should be directed and how highly productive team should be built. It is essential to trust the team and that the team is trusted by the company. We should let the professionals to do their work and make the decisions even if you don’t fully agree on everything. That is why you (or someone else) hired them in the first place. When the team works well together, has the skills, motivation and clear direction where to take the game to, then you don’t need heavy processes just communication and shared goals. Just agree the goals with the team, decide who does what and go for it. Follow up on the goals on high level by looking at the daily build. Changing the goals should be as easy as identifying that current ones are no longer relevant and agreeing with the new ones.

How we worked as a team

Word of warning before you read on. Our team had been working for a while together and we knew how we work together. The tools we used and the game genre was familiar to us and team members were highly motivated and skillful professionals. So we knew what we were doing. So don’t apply following ways-of-work without considering if they can work for your team.

Extra warning for the not so indies out there. We really had a creative freedom, peace to operate and we were allowed to make decisions inside the team. The following things will not work if you don’t have the power and freedom to make decisions that your team believes are best for the game.

What worked in our team was one week short sprints with goals like “character abilities for playable demo” and “players are able to purchase gold from shop”. In start of the sprint we had a meeting with leads and we agreed with the goals. Next developers had their own meeting where they agreed on who does what and how to get there. One developer was reserved for designer to code game-play stuff as soon as possible without heavy game design documentation. We had two daily meetings where we showed to the team what we did and what we are planning to do next. Only record of things to do was a whiteboard with huge calendar to remind us how much time we had left. Whiteboard was redesigned couple of times in the project to better match the current state of project. Only thing that remained stable was printed A4 papers labeled Important in top of the white board and not Important in the bottom of the white board. Targets, goals and tasks where put on top and not important ones to lower part of the white board. Usually not important ones were removed from the wall without actually even implementing them at all. And that was the whole process it looks and smells a lot like scrum, but, with two main differences. One the process was designed to give as much information to the team keeping the focus on the end results and not the tasks. Second differences is that we did not measure or monitor how long tasks did to complete. We only looked what was in the game build in each day, at times by each dev build per hour.

What comes to working with the people in the team it varied. One developer preferred to work with a prioritized list so we made it for his tasks. One developer preferred to take one huge goal like “payment system” or “event system” and work with that until it was completed. One developer liked to prototype so we paired him with the designer and they talked together on what would be the next thing to try out. One artist liked to work on the scenes and another wanted to have list of game assets to work with and so on. What I am saying is that only thing that was uniform on how we tracked the progress was two times per day we showed what we had done and we talked a lot to each other and we trusted each others opinions and decisions.

Final words

So anyway this was what I learned in the last nine months on what is important in game development and how highly productive team can be build. Hopefully you find something useful from my ramblings. Start trusting people and see where that takes you.

Thanks for reading and hopefully you got something out of this post.

Also published in Gamasutra as featured blog post.


Why Cloud Services are bought behind IT’s back?

A cloud worker in his thoughts, yes, that's me thinking about the shadow IT.

I wrote this post originally to my company blog.

A common situation today is that the business units are purchasing SaaS services, secretly without knowledge and/or acceptance of the IT department. The reasons for are many, but at least that they:

  1. do not believe that IT will give them a permission to order the service,
  2. are afraid of that IT will offer some custom-tweaked Intranet setup,
  3. will get “similar” but inferior service, eventually when IT gets time to do it.

How did we reach this point?

I would say that lack of understanding and the illusion of total control are to blame. Similar findings can be found on a recent publication of University of Turku, SaaS Handbook, consultant company Sulava’s Marco Mäkinen’n video about the shadow IT, and in an article in Tietoviikko (the leading Finnish IT professional paper). I’m sorry that previous references are all in Finnish so you just have to take my word for it or use Google translator 🙂

I’ve been thinking this issue a while and my opinion is that the biggest problems are following:

Firstly, IT says “No” because it does not understand the business problem at hands or the benefits that the chosen SaaS solution would offer. As IT professional myself, I too used to start with listing problems and risks whenever a new service was presented to me. I did not believe that the solution would solve the issue because I just simply did not understood how much this would actually help the business units. Ok, I did some soul-searching and found a reason for My Inner Problem Troll. I have had such a bad experience with implementation of new software services: sales cycle is long, price is high, laborious server procurement and installation, mandatory customization and integration projects, bad end-user training experience, and poor usability. And very often after the software implementation project nobody wants to actually use the product – and everybody is feeling sick and tired of it. These experiences lead further to the problem number two.

With an engineer style, we often tend to overdo things and aim for perfection and making everything ready at once. Very typical at least in Finland, Nokialand. The new service must be fully integrated to other systems, the information must not be in silos in the different systems, the service must perfectly adapt to our processes (how outdated they ever are…), and on top of that it must adapt to changing business needs, and finally, the implementation must happen to all personnel at once. Phew. Everything has to be one complete solution.

When the chosen service is finally in production, the business need may have changed and therefore nobody wants to use the service. Summarized; all the integrations, customizations and implementation took too much time and way too much money.

The price of the traditional software product will easily lead to the problem number three.

Does this sound familiar? Because the purchased product was expensive and the implementation was painful, you desperately want to use the licenses and servers for almost any problem you encounter – even if there are better (and less expensive) solutions available. In other works, it is easy to end up trying to save money by using one single product to solve the various needs.

I dare to argue that by doing this way you will end up saving money from the wrong end. As an example: how many of you organize events by email and Excel sheets? Did you know that there are alternatives? If you count the hours you use for excel work and emails and compare this to services like Lyyti (this is a Finnish service) we don’t need to be a Nobel awarded mathematician to understand a) the cost savings and b) increased value to the event participants.

How did we end up here?

The need to control everything, futile (and expensive) perfectionism, fanatic avoidance of data silos and emphasis on the potential risks instead of the benefits have led to a situation, where SaaS services are purchased without the acceptance of the IT management.

So what can we do about it? A lot! The solution is not to add more technology or interfaces.

Software production companies have already accepted that agile development and early trials are the way to get a product that is good enough for the actual business needs and the schedule. So why would IT department want to act in a way that is suspiciously similar to the waterfall method? I would highly recommend added agility and demo mentality are also tested in the IT departments – SaaS services are very easy to test and experiment!

If a SaaS product does not meet your needs, it is really easy to skip it and test another one. The testing of new services costs way less than you think and it gives you possibilities to react to actual business problems – and not only to the problems that you can afford, have time to solve or know how to fix!

Researcher Antero Järvi from University of Turku said this to me when I asked about how to integrate SaaS services to the rest of the applications: “Don’t integrate anything before you use the service for a while and evaluate if you even want to continue to use the service.”

%d bloggers like this: