As an Agile Coach, I am on a mission to make the company more agile in terms of software production and product development through my collaboration with teams and leaders. Together, we test different approaches, concepts and tools to find a set that resonates with a given product. Today, I would like to show you our vision of game development and production that is being progressively implemented in one of our products. We still have a few things left to iron out but working as a team makes everything possible.
Ten Square Games operates using the Game as a Service model, which is the gamer equivalent of SaaS. We develop products and services which are designed to be evergreens, continuously providing our customers with new experiences(and, thus value). The majority of our portfolio are games in the live phase, in which they are constantly changing and evolving. With player preferences ceaselessly transforming and with the competition keeping an ever-watchful eye, this stage is known as the Continuous Product Discovery phase.
Although it may seem like a cliché these days, we wouldn’t be able to develop our products as dynamically and be as successful as we are now without the agile approach. GaaS productions are dramatically different from AAA premium games (The Witcher, Assassin’s Creed, Elder Scrolls, etc.). Through the specificity of our sector, our direct competition does not come in the form of several or dozen or so products, but even thousands in some segments.
Moreover, we give away a large part of the game for free, which on the one hand lowers the entry threshold for new players, while on the other results in reduced loyalty of the gamers, who very quickly can swap our production for a competing one. If we fail to accurately address player preferences, they won’t devote their time to our games, and our potential to make a profit from additional services will decrease to zero. At the same time, our sales strategies must be suitable for our players, so we don’t scare them away with aggressive promotions.
AAA games sell a certain vision of the experience to gamers, build anticipation for accessing the product over a long period of time, and raise funds through preorders. Once the player has purchased a game of this type, they usually cannot return it and are under some internal pressure to make use of the product. Undoubtedly, even in AAA productions, tests and iterations are performed so as to minimize the risk of ‘slip-ups’, but these are often limited to internal tests or the Friends and Family circle. With the latter, the risk of leaks and damage to the game’s marketing image increases, and with the former, we’re testing the game on, well… a group of nerds who are making the game. If we are making a game for other nerds, then we have hit the jackpot; however, the mass audience differs from the typical game developer on several levels.
Meanwhile, in the mobile games industry, thanks to the agile approach and product dynamics, we are able to test business hypotheses directly on a select pool of customers and study their behavioral changes. This allows us to achieve a better fit with our players much faster and cheaper.
After this introduction, we can get down to the nitty-gritty of our game development and delivery processes. I will discuss it in the context of a game that is already on the market and is still being developed – I am confident that most readers are familiar with product development and maintenance.
It all begins with a vision. It provides us with an ultimate goal that we want to achieve. Our vision is ambitious, far-reaching, and focused.
Let us use Google’s vision statement as an example: “to organize the world’s information and make it universally accessible and useful.”
The following may also be considered a product vision: “We are building the largest angling community through exciting events and competitions.”
If your product vision is “We want to increase our revenue by 12% year-on-year”, then you may have to give it some extra thought. Such a definition is more of an objective that is tied to one specific indicator. Building a ‘vision’ in this manner does not provide ateam with a path to follow. A statement of this type could be paraphrased as “there should be more of the same next year.” Our colleagues won’t be inspired by such a vision, while product development will turn to chaos, with each piece of the product puzzle pulling in its own direction with a sole view of raising the ratio.
A vision unites the team and guides its actions. It’s also a certain… guard rail, which prevents us from going too far. In a nutshell, our vision tells us whether we are building a ship or an airplane.
Some organizations are known to skip this step. They build engines and other parts and only then wonder if there are vehicles where they could be used. It may sound derivative, but everyone was very productive and very busy, and we got a lot of cool parts!
If we have a vision, we can build a strategy to achieve that vision. A strategy is a certain set of principles that we follow on the way to achieving our vision. You can also think of it as a set of problems that we aim to solve.
For example: “Our strategy for getting the Little Red Riding Hood to Grandma’s house is to avoid the forest as much as possible to eliminate the risk of an encounter with the wolf. We will also avoid the swamps to keep our shoes clean and dry. To make sure that the basket is delivered while its contents are still fresh, we will invest 3 points in walking on stilts to cross the ravine and 5 points in being able to run fast to make up for avoiding the forest.”
While we know what we want to do, our strategy also reveals what we will not do. There will be no fighting or running from the wolf, and we won’t have to climb any cliffs or use our survival skills in the woods.
When mapping out the journey for the Little Red Riding Hood, our team will be able to ask “Why do we need rubber bootsif we won’t be crossing the swamps, and can we run fast in them?” This, in turn, will allow our Product Manager to consider whether they might have gone too far in their local product optimizations.
As you already know, teams at TSG influence the product and help product managers make tough decisions while keeping the direction of its development aligned with the assumed vision. Building experiences is a team sport!
Our strategy tells us about the approach we want to adopt. At the next level of planning, we discuss the specific objectives we want to accomplish. The IT community is strongly divided on what such a roadmap should be. There are two main camps: some want to see colorful bars on the timeline showing all possible details, and there are those like me who want to know what results will be expected at a particular time.
My map could look like this:
This is an example of the Outcome Based Roadmap I talked about at this year’s Digital Dragons conference. In this format, the focus is on achieving a certain effect or change within a certain period of time, rather than on the activities which need to be done.
Such a map allows for agility in activity planning because it does not assume strong dependencies between elements, and changing Day Three after discovering new things on Day Two does not result in the need to re-plan dozens of activities. Another advantage of this roadmap is that it focuses on the end result and not on the methods of achieving it, which allows the team to be creative and take ownership of the product. Thanks to a clear goal, we can steer our efforts towards one specific direction.
We have finally reached the area where we can break the work down into ‘tangible’ activities. Scoring 5 agility points is no small feat. Only one point can be earned in each discipline. The Little Red Riding Hood will have to practice:
For each of these disciplines, we will require specialist equipment that will be supplied by our other team. We deliberately start with gymnastics as this discipline does not require the use of equipment. This will give our other team time to supply the required items. Here, at the team level, we can plan how long each workout will take and when we will need specific tools.
Hang on, Łukasz! I don’t think such a plan could be referred to as agile? Doesn’t it look like a waterfall to you? Everything planned, organized in time, with dependencies identified – so where is the agility here?
The agile software development manifesto reads Response to change over following a plan. It does not say Changes instead of a plan. It would be a mistake to assume that there are no plans in the agile approach. On the contrary – they are quite numerous. They are constructed in such a way that they can be easily modified based on new information and experiences from the production process. As a result, we can start managing expectations sufficiently early and change the scope of work so that it fits the newly discovered reality.
In our case, the goal of the first iteration could be the acquisition of an agility point for the first team and the provision of roller-skating equipment for the second team.
Yes! Iterations have their objectives! No, the objective of an iteration mustn’t be to complete all scheduled tasks. We could possibly devote an entirely new article to this topic.
Coming back to our teams – if we weren’t able to deliver roller-skates in the first iteration, it would be logical to practice running in the second iteration, as we don’t need specialist equipment for this discipline either. This would buy the other team some time so that they could finish their work. Of course, such problems should be identified earlier – during daily meetings – and not at the end of an iteration.
Our assumption is that at the end of each iteration we deliver something finished, tangible and operational. At the same time, we continue to monitor the environment and the usefulness of what we have supplied. By drawing conclusions from these observations, we modify our plan for the future.
This is a brief illustration of the entire product process. We define our objective, we decide on how we are going to achieve it, we design a concrete path and plan smaller steps.
We are slowly getting to the core of this article, which is how we want to work in producing future versions of games.
Between the Roadmap and the Release Plan, I have intentionally left out one of the steps to instead weave it in right here. This step is the broadly defined Design, i.e. the transformation of the vision and definition of a challenge/problem into a certain product that will help us achieve the desired result. At this point, we simply create the shape of the features.
Let us take a look at how such work may be organized.
Just a standard Kanban board. We have one like this in Jira too!
We should make a little correction here as a proper Kanban cannot be easily implemented in Jira. But what do you mean by that? After all, we have the columns and the whole process laid out!
For Kanban to be Kanban, it should be a PULL system instead of a PUSH system. A PUSH system is one where we flip the job to the next phase of the process once we finish it. Anyone who is there must hurry to finish one’s own workload because if they dawdle, they will soon have a massive pile of work to complete, with new tasks continuing to arrive. This is how the standard ‘Kanban’ in Jira works in a nutshell.
The PULL system works in exactly the opposite way. Each column has the Work In Progress (WIP) limit, which is shown in square brackets in the table above. This limit tells us how many elements can be worked on simultaneously in a given phase of the process. The Work In Progress limit is directly correlated to the number of team members who can handle a specific phase of the process.
When the limit is not reached within a column and we have spare work capacity, we can pull a card from the previous phase of the process. This will mean that the previous phase of the process will also be able to start a new work task. The whole system is controlled from the rear by its slowest link.
The PULL system requires you to clearly separate the work completed in a specific column from that which is in progress. Unfortunately, Jira does not provide us with many convenient solutions in this regard. Both the “work in progress” and the “completed” work count toward the Work In Progress limit.
Let us look at the example – on the board above we are unable to start the idea refinement process because the limit [1] has been reached through the refinement of the green card. However, we can’t move it to the Design process, as this category has also reached its limit and the work is awaiting feedback. Only when one of the yellow sticky notes from the Feedback column is moved to Done, will we be able to place a new sticky note (in Feedback) by taking it from the Design->Done column, which will in turn mean that we will be able to start working on the Design of the green sticky note taken from the Refinement->Done column, which will ultimately mean that we will be able to take a new idea to refine from the Idea pool.
This gives us a process that delivers “goods” in a continuous and stable way, correlated with the slowest stage of the process, or – in short – working as fast as possible.
Łukasz, whatever are you talking about? Those in the first two columns are not doing anything save for wasting money!
Indeed, they don’t process the sticky notes, but at the same time they don’t produce the pile of work that the so-called someone will have to take care of, test, and integrate. The obvious question, therefore, arises – what can we do if we reach our work in progress limit? We help out. Having the so-called “free time”, we can inspect areas where the process got stuck, analyze the problem and help to unblock the bottleneck enabling the rest of the process to get moving. By reflecting on the problems solved, the team will be able to build a new and better process. We should remember that a process is something the team builds for itself rather than something that is unchangeable and imposed on the team.
To study this aspect in more detail, I recommend reading “The Goal” by E. Goldratt. It will introduce you to the theory of constraints in production systems and show you how to deal with and identify real bottlenecks (process bottlenecks).
This is how ideas are transformed into concrete functionalities that we will want to implement. Ideas, in turn, are developed in a similar, although simplified, pattern. The input is obviously the roadmap, but also player feedback, data analytics, and plentiful market research performed to tailor the product to player preferences.
At this point, we should mention that our boards also feature the so-called Backlog. This is where we assemble various ideas, prioritize them and select the most interesting ones to move them to the next phase (To Do), where they await processing.
This two-step process prevents the onset of chaos and protects the team from becoming overwhelmed, while providing another part of the team with space for creative actions. Those who deal with subsequent phases are provided with a limited number of tasks and are able to plan ahead without feeling overwhelmed.
With our Design phase, which also tends to include preliminary mockups, we can proceed to the next phase.
Once we know what is to be produced, we can break it down into individual elements to be made. We divide our design into user stories, which are small – yet functioning – elements of a larger whole. We also inventorize the graphical assets that will be necessary to make the functionality look attractive.
Quite often, there is a need to clarify the vision or requirements of specific elements. The kanban process in the graphics stream assumes that all elements it features should be properly prepared and may be carried out without further discussions. Hence, the earlier phase in the graphics stream – the so-called “upstream kanban”. It is similar to the design phase but dedicated to artistic work. The output of this process includes tasks that can be given directly to the artists.
These items will become inputs to the next phase and are 1 to 4 weeks ahead of it.
During the integration phase, the development team, using specifications and ready-made graphics, builds a new part of our game. Unlike the previous phases, here we work in two-week iterations. They have a goal to achieve, which is set during sprint planning. At the end of the iteration, we will have a new part (increment) of the product that we can launch on the market and collect feedback on its performance and methods of use. We carry out such a launch once every two weeks.
This information closes our feedback loop and feeds the product development process. Such conclusions allow us to create better and more interesting games that are tailored to our players, who twice a month receive a new version of the app featuring improvements that give the product even more value.
When developing a product, we start from its vision – a long-term target state. Next, we develop a strategy that will allow us to bring that vision to life. In the following step, we build a roadmap, thanks to which we know what hypotheses we want to analyze and which specific results we expect. We then look for our subsequent steps, define them and plan them over time.
In the production phase – in quite a similar way – we start from a vision of the next increment, we break it down and prepare the input materials so that the whole thing is ready to be executed as soon as there is sufficient space for it. Finally, we integrate all the previously acquired elements, ensure the required quality and provide the customers with the new version of the game, learning from their behavior and improving the vision of subsequent iterations.
Łukasz Szczepański, Agile Coach with 15 years of experience in mobile application and game development. He has worked for both small studios and large corporations. He steered his career towards team management, first as a Project Manager and ultimately as an expert who helps organizations transition to working in Agile. In his own words – his profession is to assist design teams in developing even better products. Łukasz is an avid fan of sustainable processes and humane management without the need for overtime. Gamedev is his conscious choice, being a player himself, but his time outside the industry has allowed him to acquire extensive experience, which he draws upon in his work. He focuses on delivering value and understanding the broader “why?”.
The article was originally published on justgeek.it, portal on 18th of October 2021.
The Argonauts are a unique team in that they’re mostly based outside of Wrocław, with…
read more
Is working as a developer in the gamedev sector different from working in other branches…
read more
Hunting Clash is one of our newer products, as it launched in 2020. It is…
read more
Have you ever wondered how mobile games are created? Which skills and what mindsets drive…
read more