SCRUM Gathering Balkans 2023 - Day 1

Today, as part of my learning trip to Belgrade, I attended the first day of the SCRUM Gathering Balkans 2023. The event was held in the Opera & Theatre Madlenianum

Game Development Playground – Navigating Change Through Continuous Improvement

The first presentation I attended was given by Stefan Stojković a member of Playstudios. Throughout his career he’s help positions such as Project Manager, Program Manager, Team Leader, Startup COO, Process Auditor, Scrum Master, and Agile Coach.

Having a strong team who works well together, is passionate and has the technical abilities is extremely important. You also need a strong product, who is defined by a proper vision or goal. It will help you remind where you want to go when you’re off-track.

We also talked about the predictability of the different aspects of a game dev/IT project :

• Requirements/Features : 35% (65% of features are not used)
• Processes/Tech : 50% (think of Unity who made ppl re-evaluate their tech choices)
• People : 15% (people are the most unpredictable)

When creating a new game, you need 3 main things :

• Team/composition (how many employees of each type of job, remember it can always be balanced later on)
• Tools (engine, project management, etc.)
• Playground (Space, time and environment where team can experiment and learn the tools and the game but also how to work together. In any case you need to have management on board) In a playground, each experiment either passes (:D) or doesn’t (D:). Failed experiments are then used to learn and adapt new experiments. (Inspection and Adaption)

Stefan’s Experience

Stefan then talked about his personal experience in a game dev company.

• Select and discuss work items that are important to the team. At some point they realised UI person had too much work compared to others. -> what to do? -> they measured it and saw it was true. -> they decided to hire a new UI person. -> they measured again and saw it was better -> gained experience (Inspect and Adapt, using transparent information)

When producing lots of code for a game but not easy to test it -> they produced new testing tools (level creator) to help one guy who was testing using excel -> important to help each other in a team.

Management needed to know the completion rate of the game. They saw they went from realising 10 story items to realising 5, so they split the 5 into more so management would be happy they made many. But in the end it was useful for the team (testing smaller items, etc.) and management didn’t even ask for new charts.

They also asked whole studio for feedback on game.

After some time -> animation became bottleneck, but they couldn’t find an animator. So they took someone with technical knowledge with little experience in animation and asked him to try. He did it and it worked. Very valuable person, because he has different skill sets. -> important to keep developing new skills.

Conclusion

Way Of Working :

• Transparency and metrics
• Alignment (of team) and Adaptability
• Continuous Improvement
• Parallel Development (agree on minimum design that enables people to work in parallel)
• Short Iterations

What helped

• Plan from feature to 1st iteration, to 2nd iteration, to 3rd iteration (same feature can go through multiple iterations)
• Focus on what team needs and wants, not on the specific methodology.

The Lost Art of Mastery: Reigniting Excellence in Agile Development

Presented by : Geoff Watts

What is Mastery?

Ancient China : Confuscius, being a good person, doiing the best you can

Ancient Greece : Aristotle, doing what you can to the best of your abilities

Middle Ages : Apprenticeship, Guilds, after some time you become a journeyman and if you’re good enough you can become a master craftsperson, after decades of training

Inida : Guru and Shishya, the guru is the master and the shishya is the student, the student is expected to do everything the master says, the master is expected to teach everything he knows. The shishya embodies everything the guru knows.

Japan : Discipline and Honor are just as important as sword skill. Lot of hard work over a long time

Studies have shown learning comes from 3 aspects :

• Coursework : 10%
• Actually doing stuff : 70%
• Developmental relationships : 20%

While teaching for mastery, one should :

• Tailor the instructions and mediums to the individual, this helps more people reach mastery
• Be patient, adjust the pace to be sustainable in the long term. Get 1 thing done before moving to the next
• Go deep and help them understand, not only learn
• Be practical, mek them do stuff
• Equalising, help more people reach mastery

Presentations should be about sparking curiosity in people to make them want to learn themselves

User stories should be about the problem that needs to be solved, not the solution to the problem.

Feedback should be close to the event, and should be about the event, not the person.

Relevance to Agile

Respect for agile is declining, according to Geoff, because of a lot of failed agile transformations. Not many people are actually masters of Agility. Some people get their degree in a 2-day course. These are not inherently bad, they bring attention to Agility. After such a session one should say “I’m not a master, I’m a beginner, I need to learn more”. But some people don’t do that, they think they’re masters and they go on to teach others. This is a problem. One should be aware of their own limitations.

What We Can Do ?

Learning other skills next to your field of expertise can help you become a better master of your own field, by learning how your field can interact and interface with other fields related to it. Enjoy the process of being a student. One will never be a master, there will always be something new to learn.

Sky High Peaks of Production Management in Game Development

Presented by Saša Drinić, Aleksandar Sakač, David Vesović, Nikolina Čeko from Mad Head Games.

Mad Head Games presents A Voyage of Resilience, a story like description of their journey in game development.

The Phases of Game Development

1. Demo phase. The start comes with developing a DEMO, that will be shown to publishers. TO get to the demo it is very foggy, the vision and product is quite flexible (FPS, hack’n’slash, 3rd person, …) A big challenge was to control programmers, the company needed to add new features but it would add a lot of instability to do it this quick.

You need to have the core gameplay loop before leaving this stage. Letting creative people run this phase is important but you need to set a deadline/timebox. Also important to have experienced people at this stage. Also important to start thinking about stabilising the code. Do not implement strict processes that would inhibit creative people. Finding the right time to switch from “creative” to “production” is hard but important.

1. Pre-production phase. Starts with a kickoff of 5 days of meetings 2 months of preparation to gather all necessary information that needs to be presented

Set deadlines and milestones with the deliverables. Build workflows and pipelines. Understand teams, who has what responsibilities Transparency and communication are vital. To be more stable, you need to enable feature lock. This is a set date that says “no more changes, no new functionalities, only bugfixing on this feature”. After a feature lock, there is a time that is reserved for bugfixing before starting a new feature. Several teams work on different branches (release, dev, main, etc.) At some point, because of bigger development scopes, new people were hired (lot of new people) it was necessary to adapt sprints (from 2 weeks to 4 weeks). It was also a bad idea to hire so many new people at once. For them, the max should have been 5 people, not 30. Maybe create a schedule of adding people slowly and gradually instead of all at once, even if they are already hired. This stage ends when a vertical slice happens. 1 hour of gameplay that helps reach a decision if game should go to production or is scrapped. Basically min-game/core gameplay loop.

1. Production stage. Continue on the bases that were set in pre-production, and scale up basically. Be consistent with quality, content, “fun” of the game. They at some point had to fix the core combat loop, in 3 weeks, so they created a strike team of experienced developers, artists and designers who had a very precise goal (set by directors). They used 1-day production loops with very focused goals. They also had to be isolated from the rest of the team. Their production for example didn’t have an impact on the rest of the overall project. It was almost and independent project inside the global project. It was a very intense period, but was very nice to see the fruits of their results quickly. In cinematic production, they also hadn’t taken enough time to finish the pre-production narrative. SO they arrived in production without being ready, having a clear walkthrough that told them what cinematics were needed. They should have setup all the placeholders to see globally what was needed. (Use text2speech, generic voice-over, etc.) They also had a sudden demand from publishers that needed all cinematics at once, so they worked on all simultaneously instead of one by one (in batches). The result was that they needed to produce 30 cinematics in 3 months.

This ends when all the content has been created.

1. Post-production phase. This stage can last up to 6 months. A lot of platform specific issues (controller disconnect crashes game, localisation in all languages, Sony uses gamepad terminology while Xbox uses controller terminology, problems with new engine running on older hardware, etc.) You also optimize your game at this point.

2. Release. Even after release, it’s hard to know why a game was successful or not. It could be the marketing, the game itself, the timing, the publisher, etc. It’s hard to know.