Organizing a Game Development Team Project — Nova Star 1.0
After completing two to six weeks of course work, a team of six ACI/GDHQ game developer interns completed their first team project in 14 days and delivered their MVP on time!
Here is a recap of the how we conducted the team team for Nova Star 1.0, plus a few golden nuggets along the way. The goal was form a team of top performing interns and provide a professional grade experience of working together to publish a video game utilizing the industry standard Agile/SCRUM techniques and best practices. Emphasis is on the operative word — delivery. These principles are not limited to game development and did not originate there, and are applicable to project teams in general. The goal was to ensure every participant would be able to integrate into a professional team setting in their professional lives as software developers. If they happened upon a team with lesser degrees of organization, then they would have had the experience and be equipped with the information to be able to lead an effort to bring that team to more functional level.
Let’s just address the elephant in the room: “I love working by myself, so why are teams so important?” Yes, most developers tend toward introversion, and go as far as to avoid interaction with others at all cost, I put myself in that category, as well. Writing a text or email really stretches my horizons on some days. Take a look around, and you will see millions of developers out there doing really amazing things, many going unappreciated due to an overwhelming number of options the world audience has to choose from. The time it takes for a lone developer to get something polished and successfully marketed and sold may often be met with someone else beating them to it with a better twist on it, with better marketing and advertising, and perhaps altogether bigger and better. The bottom line is that teams done well have the potential to deliver applications to scale and quickly to meet the rapidly growing demand for greater sophistication and content. If you want to work at a Fortune 500 or other company as a developer, you’ll sooner than later end up on a team of some kind. Caveat: there are many variations to how one can structure their work and off times, and certainly, many individuals have found ways to create wild success going solo and we will leave that for another day’s blog. The benefit, I shared with this team, is that they had six great minds working together to learn at least five+ other amazing things multiple times every day whether they wanted to or not but absorbed those experiences anyway, plus the shoulders of three professional mentors to stand on when needed (they were resourceful to figure out most challenges, so did not do so often). Their learning was amplified and brilliant ideas enhanced in their final MVP product. If there were problems to solve, the cooperation at that level left none unconquered. On the flip side, if, metaphorically sitting in a room by themselves, how far would they have gotten? Would they even finish what they started? In teams also comes consistent drive and inspiration to reach the finish line. Folks, this team has published their first game less than two months into their internships, in two weeks, with less than two months of learning, and on time!
I will add another relevant point that the members of this team worked really well together, and in my mind and experience, culture fit is the most important ingredient for successful delivery. As you’ve seen, what beginners were able to learn in less than two months, you could teach someone lacking in skills but works well with others to do as well with good support. But, “you can’t teach someone to not be a jerk,” as Jonathan often says. A prima donna writing terse code with big attitude and even bigger ego will more often break the magic, and jeopardize the delivery, if you even manage to work around them to have one. The energy spent on such a distraction from even a single team member is not sustainable and is a sure formula for attrition. No team is perfect, but this team hit the jackpot for compatibility.
Agile/SCRUM teams are most efficient with about three to seven members. It is a formal process, so anything below three makes extra work for people (may have diminishing returns). Certainly good to take the tools that make the most sense, and streamline a process for one or two people. A team larger than seven would create unnecessary relationship and tracking complexity and is not recommended. In mass scale projects, sub teams would be created in context to be optimal.
Project scale must also be considered. The Nova Star team consisted of six members, and circumstances and limited resources in this internship required this experience to be implemented on a single team in two weeks. A project of this size would normally be completed anywhere from a few hours to a few days by a single developer. This team of developers ranged from being new to programming to professional developers in other fields, such as web development, and two former university level members. Note that game development was new to everyone, and their experience level was at most, six weeks doing GameDev HQ’s Unity game development with C# course work, accelerated by a cooperative learning and teaching to learn environment, with an emphasis on learning to become your own best resource (strengthening one’s Google-foo!).
The baseline requirement was to show proficiency in the GameDev HQ’s 2D Game Development course, the first one in the series, including the Phase I and Phase II challenges to create additional functionality from a list of tasks that required additional research and problem solving (debugging) skills. The potential as a game developer opens up after conquering these challenges, and outside of this internship, earns them a certification with GameDev HQ. Once identified, all six of these interns then successfully passed an intensive C# interview and coding challenge with GDHQ founder Jonathan Weinberger.
At this point, this experience had crossed over into a real-world professional experience. Culture fit was also a consideration for maturity level and whether these interns had demonstrated the ability to work well with others, or showed promise to do so. There were unlimited opportunities to help other interns in the open forum, so we were able to get a good feel for each member’s level of voluntary participation and skill levels during the learning phase in addition to also interacting directly with each intern. They were all impressive throughout the process.
This following may be terse at times to provide a rough idea of the overall organization and flow of this project. Here we go!
Minimum Viable Product Delivery Formula:
Good team culture fit + Organization + Inspiration => MVP!
[1] Team Members — Great game development skills + Good culture fit
We hit the jackpot with members bringing the 4C’s of their power skills (formerly soft skills) together: Communication, Collaboration, and Critical Thinking, and Creativity!
[2] Organization
Now the mechanics…
- Google Workspace — Virtual workspace: Groups, Meet, Mail, Shared Documents (Sheets, Docs, Presentation)
- Slack for communications organized in channels, by topic, direct messaging, sub group meeting spaces
Day 0: Pre Project — Introduction of Team Projects, asset kits review, read the design document, and asset kit selection
etc., …
Day 1: Kickoff Meeting — Overview of the project, objectives, organization, tasking and schedule
etc., …
etc., …
etc., …
[3] Planning
The main objective here is to understand the requirements as individuals and across the team (understanding the objectives should be the same, take nothing for granted) per the design document.
Tip: Good time to meet with whoever met with the client for clarification. In this case, we had Al Heck, the creator of the fabulous asset kits and design document.
The team transferred all the requirements to a spreadsheet and brainstormed out the features and required tasks and divided them into subtasks as necessary .
Tips: Everyone needs to be on the same page. Not that only individuals understand, but that every member of the team understands the requirements in the same way. When acclimating to a new project, this is a great time to do that. Only then proceed to a design phase and prioritization of the tasks for MVP or first sprint, and subsequently, per sprint. Return to this spreadsheet to do that.
[4] Source Control Manager: Git
Create the Github Primary Repository — Decide who will be the boss of the primary repository. The Project Maintainer, or PM, will facilitate the issues, pull requests, and lead the team in merging and insuring the integrity of the code baselines.
Note: Git and GitHub and the topic of team code merging session in the beginning can generate an entire dissertation, so just keeping this brief and saving the specifics of that for another dev blog.
Devs fork the primary repository, to become their own personal remote repository (to later submit pull requests from, when their task has been completed and pushed from their local repositories).
Each dev then clones their repository onto their local machine (local repository), creates a dev branch, and then a feature or topic branch, according to the naming convention, below, to start developing on.
To align tasks with GitHub issues, it is recommend using something like Sprint#_Issue# Brief Description , where Issue# is auto-assigned by GitHub, specify a very brief and descriptive title, and state a clear and specific objective to be met in the description. Assign a member to each task.
Ex. S1.1 Create Player on the primary GithHub repository
This should correlate to a feature branch on local repository (dev’s machine)
Ex. s1_1_create_player
Note: If your team ever needs to track down a specific feature across design and organization tools, this convention creates consistency and a common language to speak in.
Note: After each dev completes their assigned task, they submit a Pull Request and complete their Issue with final comments. The PM facilitates the merge into the current development code base with the team, and can then close out the issue. Clients or external developers can also open and resolve issues here.
[5] Trello Kanban Progress Tracker
Set up real-time progress tracking on a Trello Kanban for team and leadership to see where the project is at at any moment.*
Intuitive workflow by priority is left to right across the board, and top to bottom in each column. Headers are:…
Note: Shifted from team spreadsheet so team only needs to refer back to the spreadsheet when organizing next sprint or phase in the project.
Tip: The Kanban is most effective if updated regularly. If you give leadership what they want ahead of time, they will stay out of your hair. Newsflash — they don’t actually like coming after you. That makes more work for them, and puts them in a challenging position. Give each other a break, and update your Kanban asap as part of your personal routine.
Tip: About status updates… “Bad news doesn’t age well” — a former lead once shared with our team. Let your team and leadership know when you have a blocker. They can’t help you and provide the resources you need if you don’t, and it puts the entire project and perhaps your career in jeopardy. You want your name spread around and going up the management chain in a more positive light. Reporting a problem in a timely manner is a good thing! There is a comment area on each card to post updates, so go ahead and post the good and not so good updates.
Q: How do I report a problem?
A: Silence. Let’s wait and see what’s going to happen, I don’t want to get involved with this…[right answer if you want to collect unemployment]
Let’s try again…
A: Want to impress your leadership and clients? Blow them away with this as soon as the problem becomes apparent (and after composing your points, below — be brief and to the point):
— 1) State the problem BRIEFLY, and what is the impact on functionality and scheduling.
— 2) Tell them what you think needs to be done, and especially if you need additional resources.
— 3) Give an estimate of how long it will take to resolve the problem(s), and take into account the time it will take to wait on resources, if needed.
— 4) If there is something you can work on in the meantime to help, offer that information. If you are at a complete work stoppage, offer what you can do to help others. If no one needs help, work on something else valuable and let them know you will be doing that.
Being proactive with a response in this format will save you from hearing all the questions ahead of time, and give your leadership a break from having to ask each question — remember, leaders prefer not to have to go down this road.
Daily Standups (roughly a minute or two per person, no longer than 15 min total — remember, you are all, by design, standing up, which should inspire the meeting to go quickly…unless you are virtually meeting and in the learning stages, but ultimately strive for this time limit once the team is acclimated to the project. A meeting is a separate thing, so be sure to establish that difference and stick to it!).
Here’s a recommended standup arrangement:
- Update your Kanban cards before attending the meeting to prepare and provide status
- Everyone be on time (everyone is waiting and standing and everyone needs to be aware of what everyone else is reporting)
- Stand and in a circle (perhaps virtually these days)
- Lead opens of with quick news, updates, announcements.
- Go around the room and each team member reports the following in 1 to 2 minutes:
1) What did you accomplish (or work on) since the last standup?
2) Did you encounter any blockers? Share how did you resolve them or if you require any assistance or resources, now is the time to ask for it. If someone can provide an answer, quickly acknowledge and agree to meet after to discuss, and move on if it is complicated.
3) What you plan to accomplish (or work on) until the next standup
- Lead takes notes and compares to Kanban, and arranges to get resources requested, if needed.
Any elaboration should be continued in a meeting outside of the standup
Note & Tip: In the beginning, it will be very difficult to not jump into extensive discussion or work, especially when working virtually when everyone is sitting. Try standing, anyway, and get to this format as soon as possible.
[6] Design
Beginning devs can’t wait to jump into a project without thought or consideration to good design design, if this concept is at all on their realm of consciousness. Until you crash and burn, this might not sink in. As devs mature, it will become apparent that this is a necessary step in conjunction between the spreadsheet and Kanban phases. This team figured this out quickly, and now have the desire to dedicate some time up front to do some design going forward. So, here is the easily accessible resources I recommended.
draw.io templates (collaborate simultaneously and integrates with Google Drive):
- UML Diagrams for inheritance, including abstract and interface classes
- Software diagram
- Flowcharts for logic flow
- Wireframe for gameplay flow
- Scratchpad
- Others!
Tip: Should be able to reconstruct the project based on the diagram and design document.
Note: In more professional environments, a specific design will be provided and included in the design document.
Tip: During the design process, be sure to address the issue of naming conventions for classes, methods, variables, etc.— agree on this and follow them.
Tip: Agree on the organization of your Project View structure (generally folders under Assets, with a pluralized name)
Tip: If no Unity friendly SCM (Plastic, Git LFS < 1GB, etc.) is available, take time to determine as much as possible ahead of time what assets, prefabs, etc. will be used, and distribute them up front. If changes later are anticipated, assign dedicated members make additional changes so they do not overlap and break, later. GitHub is great for text code, but very challenging when it comes to non-code assets.
[7] Retrospective
It is beneficial to replace the standup (the only one everyone can sit down for) with a sprint or project retrospective session, after the end of each sprint or project. Which brings me to our next topic.
The team did an excellent job sharing their project retrospective in their presentation!
Highly encourage creating a reference document and reviewing it at the beginning of each sprint and next project, only if it is relevant:
1) What went well? What do you want to take forward? What do you want to improve on and how would we do that?
2) What did not go well? What do you definitely not want to take forward What should we never do again?
Do a retrospective after each sprint and at the end of each project, even if its just yourself! Document it, save it, review it to improve your process as well as others.
The goal of all this is to, over time, create more dev time (what you love!) and minimize distractions. Getting more organized and efficient is the key to achieving that. The wonderful side effects are that your product has a greater chance of getting delivered, and your relationship with your leaders will improve as you make their lives so much easier. You’ll want them to spend time to find more projects and funding for you, not having to track and chasing after everyone.
Note & Tip: This organization system keeps development in check, and helps to eliminate scope-creep or feature-creep. A developer left alone might work on their project for months without ever finishing because they are so busy chasing shinny pennies (every new and irrelevant idea) around! The are great ideas, of course, but put them in their place in a Niceties column (all the rest are Necessities).
[8] Sprint Iteration
Run through and iterate over the sprint cycle(s). Generally every week or two in a typical project. In this case, the team ran about a sprint per day, and as needed peer coding and merge sessions.
After completing each sprint or project, merge your development branch (which has all the latest tested fixes and features for that sprint) into the main branch to create the new code baseline. Reconcile all non-code assets. Distribute to the team and get everyone on the same page for the next phase.
[9] Refactor
Although it would be optimal to refactor after each sprint (or ahead of time as you develop, is the best practice, but it is challenging in the rush to finish), but there is rarely time to do so.
Refactoring is done for several reasons:
- Bring your code to and comments to professional standards
- Optimize functionality
- Prepare for next phase in development
This could be challenging because it may break things in the process. Decide as a team what is necessary to do, and if even at all. On an experienced team, dev often already have done all the refactoring before merging their code.
If you have included this as part of your workflow, merged the final (tested and working) code into your main branch and distribute as noted in the previous step.
Find inspiration for code refactoring in The Zen of Python Easter Egg. You may also find it for quick reference at any python prompt
>>> import this
[10] Disconnect
Over time, refining this process should accommodate a healthy work-life balance. As the Agile Manifesto states,
“Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.”
In the beginning, it may not be balanced at all, as in the case of this project. Once MVP is delivered or published, celebrate the team’s success! Release the team early to disconnect and get some rest and distance from the project for a few days. Reconvene for next phase refreshed!
Resources:
Topic: Design Patterns for game developers
The C# Survival Guide is your best friend — at least be aware of each one does. Very useful constructs if you want to do up front design/planning, and if you walk into a project already in progress, you will likely see these patterns in the project and it will look very strange if you don’t recognize them. You will likely get asked about them for a job interview. as well
Twelve Principles of the Agile Manifesto — Only scratched the surface, there are certifications! There are certifications for professional and software developer
SCRUM: The Art of Doing Twice the Work in Half the Time
The Zen of Python also an Easter Egg (“import this” in a Python command prompt for quick access) — Relevant to software in general, useful when refactoring.
Quiet: The Power of Introverts in a World That Can’t Stop Talking— Many developers are introverts. It is not wrong to be one, so to help remove this mental blocker, check this out:
- Most CEOs in the top companies are introverts, and have learned to maneuver in the world designed for extroverts
- This is a research backed book
The Power of When-Are you a night owl or early bird?
- Many developers are night owls, learn how to operate effectively in a world run by early birds
- This is a research backed book
Topic: Imposter Syndrome
- Many sources, find one that appeals to you to remove this mental blocker
- Every developer goes through this, and sometimes over and over throughout their career
Remedies:
- Rubber Duckie topics you are interested in and want to learn about. Make videos of yourself (you don’t have to do anything with them).
- Keep a collection of your successes handy and look over them to see how far you’ve come since your day 1
- Find or create a good team that works openly and well together, even if you don’t actually work together, form a support system
- Accepts failure and learns from them - adopt a beginners mind and get comfortable failing fast!
- Compound and accelerate your learning on teams or in a mastermind group you feel safe in
- Remind yourself frequently, set an alarm if you have to, about how awesome you are, and your progress is measured by comparing yourself to you and not other people!
Additional topics
Innovation — Unity is a tool!
- Mandalorian High Tech Storyboarding, Scene Prototyping
- Machine learning
- Imagination — Nova Star agent
Rapid Prototyping
https://xd.adobe.com/ideas/process/prototyping/rapid-prototyping-efficient-way-communicate-ideas/
Give a lightning talk (quick 5 to 10 minute talk on a topic that interests you) whenever you get a chance in front of whoever will listen. Dogs love it!
Check out the new VR Virtual Stand apps, where you can actually stand up in a circle long distance!
Career — Where do you want your career to go?
- Now or decide later?
- Developer all the way?
- Team lead?
- Designer/Architect?
- Management (MBA — Finance required)?
Starting out, you may have an economic drive to accept whatever work comes your way to get your foot in the door. Figure out what your goals are and when you are able to, accept work in alignment with your goals.
Getting really good at something you don’t like doing will make you better and better at what you don’t like doing and get you more and more work doing what you really don’t like doing.
Teamwork 201:
- Rotate responsibilities leading, documenting, etc.
- Designs with design patterns in mind
- Implement additional organization tools and techniques, only if they save time or have significant benefit
Remove Mental Barriers:
- Fail Fast
- Introversion
- Sleep type
- Imposter Syndrome
Flexibility: Adapt to the circumstances in front of you, try out the phrase, “it depends…” and adjust, accordingly.
