Wargaming: Restructuring a Warship at full steam
•Als PPTX, PDF herunterladen•
0 gefällt mir•1,252 views
Sometimes you think that if only you could have more people on your team you could deliver your project faster, but in reality the more people you bring on board the more problems you face. Most of the time it’s not about how many people you have but how they work together as a team, how the work is structured and how well they can communicate and talk to each other. In this session I would like to share my experience on how we grew from 50 to 250 people in 3 years, and what steps have we made to build a productive team.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Wargaming: Restructuring a Warship at full steam
Ähnlich wie Wargaming: Restructuring a Warship at full steam (20)
Mehr von DevGAMM Conference
Mehr von DevGAMM Conference (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Wargaming: Restructuring a Warship at full steam
- 1. RESTRUCTURING A WARSHIP (WHILE AT FULL STEAM) WARGAMING ST. PETE, DANNY VOLKOV
- 2. WHO IS THIS GUY? Warships Development Director 10 years in game development Producer, Game designer
- 3. WHAT IS WOWS? 240 people – development team 400+ people – involved in the process 16 – offices around the world
- 4. Team growth Growth pain How we didn’t die? WHAT THIS IS ALL ABOUT?
- 5. HOW IT ALL STARTED?
- 6. Small team Very simple structure THE BEGINNING
- 7. PM ENGINEERS ART DESIGN QA THE BEGINNING
- 8. PM ENGINEERS ART DESIGN QA Everything went well! THE BEGINNING
- 9. Large scope Excitement! THE GROWTH
- 10. DESIGNARTENGINEERS THE GROWTH DIRECTOR ENGINEERS TECH DESIGN QAENGINEERS GAME UI GAME LOGIC RENDER TOOLS CLINET CORE SERVER CORE 3D ART SHIPS PROPS PIPELINE LEVEL ART 2D ART UI CONCEPT ART UX FEATURES BALANCE LEVEL DESIGN PM QA ART
- 11. THE GROWTH DIRECTOR ENGINEERS TECH DESIGN QA ENGINEERS GAME UI GAME LOGIC RENDER TOOLS CLINET CORE SERVER CORE 3D ART SHIPS PROPS PIPELINE LEVEL ART 2D ART UI CONCEPT ART UX FEATURES BALANCE LEVEL DESIGN PM ART FEATURE QA TECH QA PERF QA CONTENT QA AUTO QA DEPLOY BI BUILDS RELEASE MNGMNT
- 14. MANAGERS TEAM LEADS THE COMLEXITY Managers & Team Leads
- 15. One thing before we move forward… THE COMLEXITY
- 16. manages those who have reports manages those who don’t have reports THE COMLEXITY MANAGER TEAM LEAD
- 17. INVESTIGATION Let’s take “Chat” feature as an example
- 18. Who do you need to make a Chat? SERVER ENGINEERS UI CLIENT ENGINNERS UI ARTIST UX DESIGNER QA ENGINEER INVESTIGATION
- 19. 22345678910111213141516171819INVESTIGATION DIRECTOR ENGINEERS TECH DESIGN QA ENGINEERS GAME UI GAME LOGIC RENDER TOOLS CLINET CORE SERVER CORE 3D ART SHIPS PROPS PIPELINE LEVEL ART 2D ART UI CONCEPT ART UX FEATURES BALANCE LEVEL DESIGN PM ART FEATURE QA TECH QA PERF QA CONTENT QA AUTO QA DEPLOY BI BUILDS RELEASE MNGMNT PEOPLE METER BE HERE
- 20. INVESTIGATION
- 25. DIRECTOR ENGINEERS TECH DESIGN QA ENGINEERS GAME UI GAME LOGIC RENDER TOOLS CLINET CORE SERVER CORE 3D ART SHIPS PROPS PIPELINE LEVEL ART 2D ART UI CONCEPT ART UX FEATURES BALANCE LEVEL DESIGN PM ART FEATURE QA TECH QA PERF QA CONTENT QA AUTO QA DEPLOY BI BUILDS RELEASE MNGMNT INVESTIGATION
- 27. UNDERSTANDING THE PROBLEM Specialization creates complexity
- 30. The beatings will continue until the moral improves UNDERSTANDING THE PROBLEM
- 31. It was scary UNDERSTANDING THE PROBLEM
- 32. CHANGE Change
- 33. CHANGE So we started with a pilot
- 34. CHANGE DIRECTOR ENGINEERS TECH DESIGN QA ENGINEERS GAME UI GAME LOGIC RENDER TOOLS CLINET CORE SERVER CORE 3D ART SHIPS PROPS PIPELINE LEVEL ART 2D ART UI CONCEPT ART UX FEATURES BALANCE LEVEL DESIGN PM ART FEATURE QA TECH QA PERF QA CONTENT QA AUTO QA DEPLOY BI BUILDS RELEASE MNGMNT
- 35. CHANGE DIRECTOR DESIGN QA ENGINEERS GAME UI GAME LOGIC 3D ART SHIPS PROPS PIPELINE LEVEL ART 2D ART UI CONCEPT ART UX FEATURES BALANCE LEVEL DESIGN PM ART FEATURE QA TECH QA PERF QA CONTENT QA AUTO QA
- 36. UI QA FEATURE QA CHANGE DIRECTOR DESIGN QA ENGINEERS GAME UI GAME LOGIC 3D ART SHIPS PROPS PIPELINE LEVEL ART 2D ART UI CONCEPT ART FEATURES BALANCE LEVEL DESIGN PM ART TECH QA PERF QA CONTENT QA AUTO QA UI UX
- 37. UI QA FEATURE QA CHANGE DIRECTOR DESIGN QA ENGINEERS GAME UI CODE GAME LOGIC 3D ART SHIPS PROPS PIPELINE LEVEL ART 2D ART UI ART CONCEPT ART FEATURES BALANCE LEVEL DESIGN PM ART TECH QA PERF QA CONTENT QA AUTO QA UI UX UI QA
- 39. And fortunately we had to upgrade the Chat… CHANGE
- 40. UI QA FEATURE QA DIRECTOR DESIGN QA ENGINEERS GAME UI CODE GAME LOGIC 3D ART SHIPS PROPS PIPELINE LEVEL ART 2D ART UI ART CONCEPT ART FEATURES BALANCE LEVEL DESIGN PM ART TECH QA PERF QA CONTENT QA AUTO QA UI UX UI QA ENGINEERS TECH RENDER TOOLS CLINET CORE SERVER CORE CHANGE SERVER ENGINEER SERVER ENGINEER
- 41. CHANGE
- 44. Less fear CHANGE
- 45. FEATURE QA DIRECTOR DESIGN QA ENGINEERS GAME UI CODE GAME LOGIC 3D ART SHIPS PROPS PIPELINE LEVEL ART 2D ART UI ART CONCEPT ART FEATURES BALANCE LEVEL DESIGN PM ART TECH QA PERF QA CONTENT QA AUTO QA UI UX UI QA CHANGE
- 46. CHANGE
- 47. CHANGE
- 48. FEATURE QA DIRECTOR QAFEATURE TEAM #1 UI CODE 3D ART SHIPS PIPELINE 2D ART UI ART CONCEPT ART DESIGN CODE QA PM ART TECH QA PERF QA CONTENT QA AUTO QA UI UX UI QA FEATURE TEAM #2 FEATURE TEAM #3 FEATURE TEAM #4 DESIGN CODE QAQAQA DESIGN DESIGN CODECODE CHANGE
- 49. LESS COMPLEXITY WHAT WE’VE GOT?
- 51. LEADS NOW HAVE TIME TO WORK WHAT WE’VE GOT?
- 53. MORAL IMPROVED WHAT WE’VE GOT?
- 54. A FEW WORDS ON MOTIVATION WHAT WE’VE GOT?
- 55. WHAT WE’VE GOT?
- 57. And it was contagious WHAT WE’VE GOT?
- 58. Not a silver bullet PERFECT SOLUTION?
- 59. Difficult to keep the vision (both creative and technical) PERFECT SOLUTION?
- 60. Some disciplines are hard to implement into feature teams concept PERFECT SOLUTION?
- 61. There are still some silos… PERFECT SOLUTION?
- 62. Difficult to scale PERFECT SOLUTION?
- 63. Could be hard to implement PERFECT SOLUTION?
- 65. Before hiring make sure you structure is ready TAKE AWAYS
- 66. Engagement is way more important then process TAKE AWAYS
- 67. The performance of a system is not the sum of its parts. It’s the product of its interactions TAKE AWAYS
- 68. Find a way to let people influence the result TAKE AWAYS
- 70. Focus on interaction and not individual parts TAKE AWAYS
- 71. UNDERSTANDING THE PROBLEM Finding the weakest link
- 73. By trying to reduce the hands-off problem we created MORE work: More documentation More reviews of different sort Even greater management oversight UNDERSTANDING THE PROBLEM
- 74. The performance of a system is not the sum of its parts. It’s the product of its interactions. - Russel Ackoff UNDERSTANDING THE PROBLEM
Hinweis der Redaktion
- - как-то по композиции получше нужно сделать... A few words about myself. My name is Danny and I am the Development Director of World of Warships, developed by Wargaming St. Petersburg. Before joining Game development I wirked in Films industry, supervising production of TV commercials, documentary films, post production and stuff like that. And I work in game development for about 10 years and before World of Warships I worked on relatively small projects and had a chance to try myself in many different disciplines. I’ve done downloadable titles for consles, PSN, XBLA, Wii, I’ve also done a few very successful PC downloadable games for such companies like BigFish, Intenium, Real Arcade and so on. The major disciplines were always management and game design, but I’ve done animation, particles effects, a little bit of scripting and programming, localization, QA and all the remaining things everybody does while working in a small team.
- What’s World of Warships? That’s a large scale MMO, we’ve launched around 8 months ago and we are doing really well. We’ve got 6 clusters around the world CIS, EU, NA, KR, SEA, CN. We’ve got very healthy and loyal audience, and we are very optimistic about the future of this title. Our development team consists of around 240 people and also around 300+ people are involved in the process if we are talking about the global operation. And as with other Wargaming titles we’ve got around 16 offices around the world who contribute to development nod operation of the game.
- Before we proceed further I would like to give a quick overview of what this talk will be about. I will mostly talk about the team growth, how we grew over initial years of development, what problems we have encountered and how we fixed them. I’ve started this talk on purpose with the fact that before I joined Warships my background was in leading small teams, and that’s important to know because I believe one of the major accomplishments that we had over those years is that we managed to get the feel of a tightly knit, small development team while working on such a huge behemoth. And I am going to share how we’ve done it.
- So at some point in time when Wargaming released World of Tanks and it was (and still is) a huge success, they started to look for other teams who could develop next parts of the franchise because Tanks team was extremely busy with supporting and improving the original game and there was definitely no resources to work on other projects. That’s when they came to us, as we had a very good reputation on the market and we had required experience both in Online titles development and development of history based wargames. The negation process went really fast, we’ve done a very quick prototype that showed how we wanted to approach the game proved that we had skilled engineers and designers and the entire team was super excited and super motivated to work on something really big and really meaningful. And we all loved World of Tanks. So the paper work was done and we jumped in into production really fast.
- By that time we had a relatively small team, the studio size was about 50 people and initial WoWs team was something like 35 people.
- The structure was very simple, tech engineers, game engineers, artists, game designers, and QA, a pretty regular set up for a small team.
- That was all we needed to deliver projects that we worked on in the past, and It worked wonderfully. We couldn’t accomplish a really big scope, but if you managed scope correctly it was easy. Planning was easy, execution was easy, delivery was easy. Well you know… easy in game development standards.
- Though the scope of Warships was extremely large. Since day one we knew that we will need to grow and bring more people on board. And we were exited! Back in the days of smaller projects every new hire was such a big thing, such a huge event! Every new person opened up enormous opportunities for the team to do more stuff: do more things, more features, improve tools, refactor some old code that slowed down everybody, and so on. So this time we were like: Awesome! We will have way more people and we could make the best project ever and it’s going to be so much easier compared to the old days, as we will never be short on work hands any more! Hurray!
- So we started to grow. And as there were so many specific things that needed to be addressed we started to implement alot of specialization. Engineers got split into technology and game engineers with different specialized teams inside, art department started to consist of many different teams, as well as designers. And at the beginning people were very happy that they don’t need to work on some random things anymore and could really concentrate on what they do best, programmers write specific code of their proffered domain, concentrating on rendering or on tools or on game logic, game designers don’t need to help with QAing the game any more and could concentrate on writing documents and working on balance sheets, artists don’t need to tear themselves apart and work on different assets every day and could concentrate on something specific. As we moved further and further we needed more and more people to cover different disciplines, with every milestone we encountered new roles and areas that we were not familiar with and the best solution we had – was to hire more people.
- The team got bigger and bigger, the hierarchy became more and more complex with every day. And we were always over flooded with problems and issues that we needed to solve, the amount of work that we discovered moving forward increased everyday and every time we encountered something the easiest and most reasonable solution was always: “We need a new guy to solve this, everybody else is overloaded”. Every day brought more people and more specialization.
- At some point we were not as excited as before. The planning became tremendously difficult, delivery started to suffer and predictability decreased greatly due to complexity.
- And what do you do with complexity? According to the general rule managing complexity is one of the key responsibilities of a certain group of people…
- And this group is - Managers. And team leads. In order to show how big the complexity was we are going to do an exercise. This is something really interesting; in case you haven’t done something like this at your work place I recommend doing this as it might show some interesting findings. We are going to map a workflow on the organizational chart, this exercise was very eye opening for us, and actually helped us to understand where we are having problems and made us think about possible solutions.
- Before we rush into the exercise I’d like to state a few definitions so it would be easier for you to follow.
- Different studios and different companies call different positions differently. For the purpose of this exact exercise. When I say Manager I mean a person who has several reports and they do have reports as well. So this is a manager of managers. Team lead is a person who manages people who actually do work. For example Art Department Manager is a manager because he has 6 team leads who report to him. And each of those team leads have several artists who report to him or her.
- For the purpose of this exercise we are going to examine a workflow of a feature. And to make it easier for you to follow I’ve decided that I will go with Chat. I believe some of you worked on a Chats before so it might be a bit easier for you to follow or even if you haven’t worked on Chat before it is relatively easy to understand it’s components.
- If we look at this feature from a small team’s perspective, it’s relatively straight forward and there’s little complexity. Depending on the chat’s difficulty you’ll want to have either one or two server engineers to do the backend work, some in-game work is required for client engineers, you’ll need to design the layout and make some art, depending on how big or small is your team it’s going to be either one or two people, and there should be a QA engineer to verify the result (some may choose to go without the QA due to constraints). So depending on the complexity of the system and the size of your team you could expect to have something like 4 – 7 people total. But let’s see how it works in a bigger team where people are highly specialized and work in different departments.
- Imagine, a feature Chat is pulled from Backlog and assigned to the game design department manager to come up with a concept. As we go through this exercise we are going to count people involved into the process. So at this stage we have two people involved, two managers – the PM and Game Design Manager. So game designer manager assigns work to his reports who are responsible fort UX design and Feature design. They do their part of work, approve it with game designer manager and after that the concept could go to people responsible for execution. So it goes to Engineering managers and Art manager who evaluate the design, they maybe do rough estimates, understand which teams need to do work on this feature, maybe there are few iterations going back and forth making sure that the design is clear enough, there’s no ambiguity and it is ready for work. Department leads distribute work between their guys. Then leads distribute it to their guys taking into account their availability, other tasks in progress, dependencies and so on. Eventually the feature gets done and it goes to QA where more work is generated in form of bugs for people who worked on that feature.
- 19 people are involved in the process of making a small feature.
- If we look at the number of developers we see the same amount of people we though about at the beginning of this example. And after carefully going through the process we can clearly see a huge management overhead. Of course all those team leads and managers are not working full time on each feature, but they get stuck in coordination because they need to plan all the resources, track dependencies, resolve conflicts, and actually become a huge bottle neck. If you are coming from a small team you could wonder, why do you need all this? These managers are slowing everything down! Big teams are not efficient! Yes you are right, and wrong at the same time. Big team allows you to do something that small team can not achieve, you can work on many things simultaneously. That Chat feature would prevent a smaller team from doing anything else while it is in development. A bigger team can work on many things simultaneously.
- And we should remember that we are talking about an online title that requires a very stable release cadence. Frequent releases, releases rich with features and content and high quality releases.
- In our case we operate with at least three versions at the same time. One version is running on production, and there’s always something with it. Somebody is not happy, somebody’s PC configuration is not running the game, bugs are found, balance issues are found etc. And you need to deal with it, and you need to deal with it fast and release frequent updates on production that fixes immediate issues and player’s pains to keep them happy. The second version is in stabilization, where there are tons of last minute changes, bug fixes, preparations for release, communication with publishing team and so on, which also generate tons of action items. And of course there’s also a version in development where major work is done, features are shaped, design changes, prototypes tested and so on.
- Then toss in another e3 build that needs to be done with something special. It’s a lot of communication. So… remember that last slide that showed how complex the information flow is on a single feature?
- -=Animations will be added here=- And imagine what happens when we have around 30 - 40 features in development at the same time and 3 versions in operation.
- Sometimes your mind could really explode. Взрыв мозга
- So in order to deal with that challenges our initial decision was to go with specialization, which is a rather common approach, and it looks absolutely viable when you think of it. However though specialization potentially improves productivity of one particular person \ department it slows down large teams productivity as a whole by creating dependencies and complexity. And there was something else that troubled us greatly at that point. This specialization also had some very bad side effect that was way worse then complexity.
- Silo is a business term that has been passed around and discussed at many board room tables over the last 30 years. Unlike many other trendy management terms this is one issue that has not disappeared over the years. Departmental silos are seen as a growing pain for most organizations of all sizes. Ownership is very difficult here, because you as a feature owner can’t really affect the outcomes of all departments due to conflict of interests. In the department based structure people are evaluated and incentivized by what they do for their team and for their department, not for how they help the product’s overall efficiency, productivity, or success. At some point it was a very common situation when all tasks on a feature were complete, but there was nothing we could ship to players. And this led to….
- Wargaming titles are based on an assumption that the life time of players in our games is very very long. Months and months and preferably years. And that means that there is a strong need to update the game effectively to keep those players engaged. WE need to proved a high quality service that evolve and improves very rapidly, otherwise we are going to loose players. And at some point we ended up in a situation where we released several versions in a row with an extremely blank patchnotes, there was nothing big in it, nothing meaningfull to the players because everything took so long to develop and we kept missing our deadlines. WE would move features from an update to an update and not delivering. And this caused players rage.
- We started seeing negative comments that the game is not developing fast enough, that players' concerns are not addressed and so on. And this automatically affects the team in many different ways. They read players’ feedback and see that their work is not appreciated and that players don’t like it, and it’s painful. You all as game developer know that there’s nothing worse for our kin to read bad things about your game. And that’s where the blame starts to appear, teams start to blame each other, we missed that feature because of that department or because of that department, this was not good enough, we’ve done our part and they haven’t done their part. Us and Them became a very common thing. And of course there’s pressure coming from upper management, they get reports form community guys see that players are not happy and push for results. The team crunches like hell but there’s still not enough improvement and the deliveries are still not big and not meaningful enough. And of course as a developer you are loosing motivation when you see that things are not coming together and you also see that the work you do is not bringing any impact, because it’s all small bits and pieces, you’ve got a never-ending queue of tasks that you need to resolve and they are all minor and you don’t understand the purpose of the work you do. Hopefully this situation happened when we were still in Alpha stage, so the community size was not big, but it was a very clear signal that something was very wrong.
- We knew that with current approach we would never deliver something good.
- We knew we needed a change. We knew that we not only needed a process change we also needed a change in how people think about their work, how they are involved and how they communicate with each other. We needed a change in mindset. However everybody is afraid of change, especially when you try to change something fundamental, like the way people work with each other…
- I will simplify this a little bit for the purpose of this example so it is easier for you to follow.
- We took the most spread discipline across the team – the UI. Identified everybody who was involved into making UI related work across the studio.
- And united them into a single team.
- One lead to rule them all. Colocation. We made sure that they all sat together, next to each other. One plan. They were all unified by one goal and one plan.
- And fortunately around that time we needed to improve the Chat system, this time there was supposed to be way more work as by that time we needed a more complicated system
- So let’s go through the same thing one more time very quickly. This time we are skipping the design deportment and the task get’s straight to the new team’s lead. He will be the feature owner. He and his guys are coming up with the design, and this time these are not teams there are just artists and designers without a separate layer of management. This is a cross functional team, but they are still lacking a core function required for that feature, they don’t usually need a server engineer on their team. So now, instead of adding additional communications, the feature owner talks to Engineering manager and the Server team lead, and…. We have a guest start! For the duration of that fuature we are relocating one person to a different group. So the work begins! A very important thing is that the new team accumulated people from 4 different departments. Before that they would most likely do their work one by one; now since they all were in one room they could do their work simultaneously, thus completing it way faster, completely removing handoff issues and reducing the amount of mistakes made due to communication failures. Remember how bad things were after QA submission? Now since there was a dedicated QA in the same room who is aware of the design and the solutions used for that feature, the team would submit a way better and higher quality code / assets. The team would ensure that the fuature they develop is up to stadarts it’s good enough, it’s performant enaught and it’s bug free. So they submit the feature for final integration QA and that’s it, in majority of cases it’s good enough for integration and there’s no tons of random work generated.
- And this time the majority are developpers.
- By simplifying the structure we removed 8 unnecessary communication links and it greatly improved the cycle time of the test features. Things got much better. Planning of features developed with that approach got more predictable. Communication improved.
- But the most importantly the success story reduced Fear of change in the Team. And leadership now had a proof that this approach could work.
- So we decided to go all in, and in just one week we did the following with the team:
- картинка
- картинка
- No more design departments, engineering departments, all teams have their dedicated person of main functions. Each team owns their feature. Work is very well isolated. Teams have everything they need to do their part of the job.
- Productivity increased by a huge margin. Our releases got way better. Planning became much more reliable.
- Ownership became possible. Each feature is now owned by a team and an exact team lead. Old approach: - Pick a backlog item, divide work into needed amount of pieces. Manage dependencies, and hope for the best. New approach: - Backlog item is given to a team, and they drive it until completion, making sure it has everything it needs.
- Because complexity decreased it actually speared tons of time for the most valued and experienced people the team leads. They are not spending entire days in meeting rooms anymore, they are not juggling jira tickets all day long or writing meeting minutes on who agreed on what. They now have time to sit down, talk with their people, educate them, and actually do parts of work. After all they all are very experienced in their domain and can do magic.
- Because different disciplines got united they can now all experience first hand how everybody works, artists learn from programmers, programmers from QA, everybody understands pipelines of each other much better and it helps in getting stuff done more quickly, it helps in self education. People become better professionals if they have a more wide understanding of how things work and how exactly other domains contribute to the final result.
- Output became very transparent. The team is either delivers a feature or not. Output became much bigger, we started to release rich updates. People can now clearly understand what they are working on and how their work impacts the game. Players loved the increase of speed and quality and there was a lot of praise. And teams were happy that players are happy. And that increased motivation greatly.
- Motivation has always been a hot topic, and it is always a huge question how to motivate people, how to engage them, what do I do?
- Surprisingly this change in the structure and in the approach to how we started to work is very well described in the highly recommended book by Daniel Pink “Drive”. In this book he says that Carrots and Sticks approach to employees motivation is not working in the 21st century. Carrot and Sticks only applies to straight forward tasks, mechanical tasks, tasks that does not require creativity. And to what I’ve experienced during my career is that in companies that have departmental structure this is the most common approach how people are incentivized, you do your part of the job fast and good enough you are getting a bonus or at least a tap on the shoulder. Because that’s what you are supposed to do right? You are given a task you complete it that’s it. The more tasks you complete the better employee you are. But Pink’s research shows that this approach is actually causes negative consequences for people who do creative jobs. We game developers are in a very interesting position, our work is highly creative, not because we make games about elves and orcs - no. We are constantly in a position of solving issues that no one ever solved before. Even if you are working on a game clone or have a very good reference, most likely you will encounter problems original team didn’t have. Most likely you are making it with a different technology stack, with people of different mindset and cultural background, you don’t know which parts of the game you are cloning work or do not work, are you improving parts that don’t work in the original or are you skipping a crucial part that is working? You never know. And this is why our job is highly creative. We are solving unique issues on daily basis.
- And in his book he says that are three things that affect people’s motivation when the are doing creative work. Autonomy. Mastery. And Purpose. And feature teams are exactly the environment that nature those things. Teams are autonomous as they are working on a relatively isolated piece of the game. There are not many people representing one discipline in one team, so all disciplines in the team are autonomous as well. If there’s a need in programming work, there is a specific programmer the entire team relies on. Mastery. There’s less specialization and one team member may need to do more thing and learn more and become better faster. Teams are not resolving tasks, they are shaping up game features together and you are always learning much faster when doing something more complex. There’s a constant rapid learning process going on. Purpose. You are responsible for entire solution. Without you the team is not going to deliver something. Without your work, the game will not improve.
- Feature teams were organically organized across the studio. People wanted to get closer to those who affect their work. Ideally in the same room, or at least on the same floor. They didn’t need a structure change for that, they just wanted to work together. This got beyond development and such departments like HR started to create their own “strike teams” to work on complex projects.
- It may sound like we have solved every issue, and this is the perfect approach. No it is not. I believe each case is different for every studio, but were we happy with the change? Yes we were! Is there room for improvement? Of course! And I would like to also talk a little bit about the major issues which we are having with this approach as of now.
- As features now being developed faster and the preparation period is much shorter, sometimes it’s difficult to make sure that everybody in the team aware of all the changes that are coming. Also as teams got more freedom and there is now way less control on what exactly each individual does there are sometime de-syncs between teams both in technology and in design. Though sometimes it causes conflicts, I would choose this over slower development, and there is definitely room for improvement here.
- Not all disciplines fit into this concept. For example you might have guessed why we haven’t split UI into feature teams, because UI has some unique specialties that you would need to duplicate in case you want all teams to be completely cross functional. Such as UX designers or tech artists or animators. And it could be quite expensive. Also there are some things like massive content production that could not be united into feature teams and it might cause some conflicts in the team when some people work one way and other people work the other way, it potentially could cause some split in the big team where some people are “better” then others, or work through “advanced” methodologies which could also be very dangerous and needs explanation.
- This time team silos, not department silos. Some time after the change we saw the return of silos, but this time it was team silos, not department silos. So this should also be very well monitored and taken care of. The good thing is that in case of teams the conflicts that we saw was more on the challenge side. Teams that underperformed was grown upon and trolled by performing teams, it could sound healthy but the best option is when performing teams are helping underperforming teams and not blaming them, so this is also a danger that should be monitored carefully.
- When we were designing the system we though it would be easy to scale that way, just build another team and you are ready to go. In reality it was not. Due to issues with vision that we talked about before you should really expect members of these teams be very proactive, professional, and engaged and entire team should have a very good understanding of the product they work on. Feature team also imply that all members of such teams are autonomous and high skilled, and you need to trust them as you are giving them the freedom to come up with solutions they seem fit. After switching to that approach hiring got more difficult. When you want to get a new programmer on the team he needs to go through a very lengthy training process as he will be required to make decisions by himself and if he doesn’t understand the tech, if he doesn’t understand the architecture good enough he could cause more problems then profit.
- In majority of cases when you are switching from departments to teams your managers and team leads will most likely be not very hap[y as in fact they receive a demotion and moving from a manager position to a team lead position. For some people titles sound very big and it could be an issues. When we were switching to teams approach, we had to let several people go, who didn’t see the benefit of the change and worried about their title more then about the benefit to organization.
- So… I believe it is time to sum up what we’ve been talking about in this presentation and identify some take aways that I hope could help you when you are in a situation when you need to ramp up with people on your team or have problems with delivery and communication.
- Bringing more people for your project is always a good thing as you have more people to deliver result, but it is very dangerous as it could completely cripple your project, as it almost happened to our team. Look at your structure and try to map how the communication and work flow will look like. If there are too many red arrows it should be a good idea to think about how to reduce them.
- Process comes second. First thing is how your people are motivated if they are not motivated and if they are not talking to each other process will not help. Fix people issues first and they will establish process for you.
- Value is what players see, they don’t care how performant are your teams. When you are thinking about how to improve your performance don’t think about individual teams, think about your organization as a whole, what block your team from delivering result? How you can deliver faster? In majority of cases proper communication and car is way more important then anything else. A programmer who pokes across an artist’s shoulder and sees a terrible and repetitive routine an artist is busy with the majority of his time, and the programmer can reduce the amount of work of that artist by a large margin just coming up with a script will increase your team’s productivity, writing reports and following a strict process will not.
- And they will surprise you!
- According to Goldratt’s Theroy of Constrains, organizational performance is dictated by constraints. These are restrictions that prevent an organization from maximizing its performance and reaching its goals. The theory says that every system, no matter how well it performs, has at least one constraint that limits its performance – this is the system's "weakest link." The theory also says that a system can have only one constraint at a time, and that other areas of weakness are "non-constraints" until they become the weakest link. You use the theory by identifying your constraint and changing the way that you work so that you can overcome it.
- We very sure that the problems that we have are hidden in flaws of our process. I can do an entire talk about how we experimented with process, or how different methdologies work at scale, but since we are really short on time I will just say that
- The main mistake that we made there was that we tried to strengthen different parts of the system. If we saw a problem in one department or another we tried our best to eliminate the problem there and strengthen this department. Because our idea was is that if we remove the bottleneck we would start to deliver things faster. But in reality we created MORE work for the most overloaded people on the project.
- I understood Goldrat’s Theory of constrains too literally. I was looking for almost physical bottlenecks, but the true bottleneck was not the problem of people or of departments it’s the problem of communication and the way we structured our development as a whole.
- We thought that by applying Kanban we could identify bottlenecks in our workflow and eliminate them. But then something interesting happened... We very quickly understood that the main problem we have is the hand-offs problem. Items we worked on would keep going back through the flow, and in order to solve this we implemented more and more in-between stages, in order to reduce the chance of failures later in the development process.
- (We had even a longer board at some point I wish I had taken a picture of it ) A feature got back to engineers for improvements? We need prepare a more precise documentation up front. The UI engineers encountered issues with logic code architecture? We need to come up with more strict coding standards, introduce an engineering feature kick off process and agree on architecture before hand, maybe even document it… Too many bugs in a feature? We need to implement a more strict code review process.