Story of Vertigo - 2/3

Before relaying all those years of experience to you, now I would like to give further information on how we work. I am not going to make a mention of what sort of experience we have to do these or what should be done in the future. This is an article regarding present time.

Every company and every game studio has a plan. Everybody has a trouble like publishing a product on market and marketing it. All of these individually require planning – meaning documentation – efforts and time to spend. Nobody reads the documents, plus plans drawn with multi-color and nice graphs never catch their real targets. Performing tasks in their given time-frame is almost like a dream. The game we develop only consists of design-documents (GDD), first excitement and dreams.

Sprints

Imagining and starting with passion could be really delighting. But we are also aware of the necessity of creating some advances that are significant and testable in the short term. Instead of long term and factoid goals, we had to set clear goals that users can immediately provide feedback and that we can perform in a short span of time. What does the player want? What sort of reactions will the changes and features that we made have impact? Wouldn’t it be much better to have answers to these questions quickly in 2-3 weeks, rather than at best in 6-9 months when we finish the game? So we adjusted our way of working according to this. We started to develop the game according to ‘scrum’ methods, firstly as 3 week-sprints, then as 2-week-sprints.

Divide & Manage

What changed and according to what do we plan sprints? In developing a project the most challenging and inconsistent factor is ‘deadline’.

We do 2 things to make everything as right as possible:

?  Divide and manage. Firstly we divide whole project into sprints. Then we divide each sprint into their most meaningful small tasks.Although making a prediction for the whole is very hard, on the other hand, making a prediction for small pieces is very easy.

?  Consensus. Brainstorming will not enter into this office. This is our resolution. Alright, but how do we achieve consensus? Instead of complex arguments flying around, everybody writes his own decision and possible duration information. Then we match these and dwell on those which don’t match. Sometimes someone sees something that others don’t see. We can achieve precious ideas that cannot be achieved through arguments. We don’t lose time.

According to Parkinson’s Law, "Work expands so as to fill the time available for its completion". So, if we guess a work as accurate as possible, it will be that much significant for the project. We do our best to guess it accurately. Be sure that nobody will be able to guess it accurately at the very first time. The important one here is backward evaluation. Knowing the team better and making a backward analysis of the deficiencies while planning the sprints will always make you catch the ideal timing. We have seen that it is not possible without feedbacks.

Stop Micro-management

Time constraint and sprint logic in general can cause team members to perform tasks jump into the work saying “let’s do it”. And there may be situations called “Micro-management”, where employees can feel insecure and even the smallest details are managed by the administrator / leader.

In this sense, Scrum methodology requires someone only to perform recommendation and reference, namely scrum-master. Though smaller organizations cannot fill a position suitable to this, insecurity that can arise in management phase must be minimized. Every member of the team must focus his/her existing task as well as the product achieved at the end of the project. Sometimes team members can forget the fact they are making a game, and thus at the end of the day the work done may be inconsistent or incompatible with the game. Thus, from the very beginning, we set all of the sprint duties as stories. Stories make sure we can see the result of what we do and not to go off track.

At the end of the Sprint, we make an evaluation meeting – that takes less than 1 day – and we focus on 2 points as below:

? Past sprint evaluation

- What should we start to do? Let’s identify our deficiencies.

- What should we continue doing? Let’s identify what we do positively.

? Team evaluation

- What kind of mistakes did I do, what were my deficiencies?

- What should the team change and how can we be more compatible?

Best way to predict and manage future, is only possible with analyzing the past accurately. Furthermore, when you adapt according to user/player tests and their feedback step-by-step, there is no chance for a surprise. Or let’s say minimize the surprises :) Life and projects are full of uncontrollable variables, the best move to make at this point, is to respond quickly. External factors, the market, the competition, crises – we know that we cannot control any of these, but responding to these quickly and making the best move is completely under our control.

Note: The next Story of Vertigo will be my 3rd and last article. In addition, I advise everyone to implement and use scrum-agile methods in cultural base. Every company will find a way that is suitable to them. Certainly, have many post-its and a big whiteboard, plus put an end to brainstorming from now on :)

Ali Say?n

Co-Founder of Vertigo Games