I have acted beyond my original scope of responsibilities to fix a situation that was hurting the project.
I helped the team to identify problems in our cooperation, and figure out best practices and guidelines to alleviate the most serious.
I was involved in assessments of cost and effort and enforced that features are properly specified and validated before we make our decisions.
I always had a passion for game development, and in 2018 I joined a small indie development team to work together again with former college.
At the time the team was working on a local-multiplayer party game, a project of typical scope for fresh indie studio. I have joined the project at about half time of it’s planned development cycle.
As the team was small, all members had to wear many hats. I had two roles: introduce UX practices to the team in general and to implement new features for the game as one of the programmers.
Upon joining I offered to implement an easy to extend computer opponent that is capable to stand in for human players. This has brought me in contact with all parts of the codebase, making me realize that a major problem was brewing...
Coders liked to work independently, each feature being assigned to a single person with minimal oversight. This was viewed as an easier way to work “together.”
Without an established common ground, the codebase became fragmented, with as many different coding styles, practices, and levels of quality as there were developers on the team.
All this time the team has been operating with a pre-production mindset. They had a high-level roadmap, but features were not well defined and design decisions were made and changed on the fly.
This led to deadlines being routinely missed or displaced, to the point that the team have begun counting on it.
Artists and coders were working on the same features at the same time. Almost everything was built to production quality right away, giving the impression that progress was happening at a high pace.
This practice however increased the overhead of any change that would need to be made down the line, solidifying some architectural decisions early in the project and slowing down future development.
As a result of the these mistakes, progress was slowing down. Each new feature added ran the risk of breaking something else, and developers were often unwilling to make changes in each other’s black boxes.
Over the course of 4 months, we have implemented the following principles to help us develop as a team.
People were encouraged to challenge and to frankly communicate if they weren’t onboard with a decision. We organized fireside chats where the team could push for or against standing practices.
At the cost of some stress, we began to uncover and solve long standing issues, and build a culture of honesty that lead to better decisions and time estimations.
Designer were required to produce written specification of requests, even if the feature looked simple and straightforward.
Writing down requests in detail helped designers and developers to recognize more edge cases and resolve them before they became bugs.
Developers were required to involve at least one other member of the team, but preferably more, when preparing to develop new features.
Architectural decisions became more thorough and the team became more aware of how each system operated.
Leaders were asked to communicate more clearly about WHY we are pursuing each business and development goal.
Understanding the underlying reasons for management requests, the team was prompted to get more involved in decision making and propose new solutions and risks that were not apparent before.
We have allocated much more time to planning than before, even if it required to sacrifice or postpone something to make it happen.
Enforcing more time for careful planning helped us to lose less time to miscommunication and hitting unforeseen roadblocks.
I already had some experience with conflicts on interest on larger projects, but facing similar problems in a very close knit team helped me to gain a more hands-on experience and confidence in handling issues like this in the future.
As some old privileges get removed and new responsibilities added, people may feel challenged or punished. It's easier to get everyone onboard if they can express their concerns.
Don't be afraid to have conflicts. It may be an uncomfortable situation, but not tackling those will just make things worse in the long run.
