I was born in Dallas, TX and have lived here most of my life. I grew up playing sports and eventually went to college in California to play volleyball for the University of the Pacific. While I was there I pursued my Bachelors in Computer Science and my Masters in Engineering Science. I am currently studying at the Guildhall at SMU as a production student. Graduation is in May, and I am available to work June 1st.
I'm a huge sports fan. As someone who played D1 volleyball, sports is very important to the way I approach my life. I learned many lessons from being a part of sports teams over the years. I enjoy watching sports of all kinds, but specifically hockey and volleyball. I'm a huge Dallas Stars fan and I love watching the team learn and grow together from week to week.
I also love games of all sorts, but my favorites pit players against one another. From competitive online games to card games like Munchkin, I enjoy the spirit of competition between people. I spend plenty of time playing RPGs, but I always manage to find my way back to competing with others.
My greatest assets as a producer are my soft skills. I use my abilities to coach and guide teammates through learning production practices and development of team culture and identity. I'm practiced at one-on-one communication with developers be it for performance evaluation or accountability. By following team culture statements and exercising good production and team fundamentals I am able to lead by example to positively influence the team around me to produce results.
The following are some of my views about production philosophy. I have worked on waterfall projects before and was trained in agile methodologies at school. Agile specifically has greatly influenced my mentality towards production, but I would consider myself more than capable of moving between different production methods in the same way one can not coach two sports teams in the same way. Each team has its own identity, and needs to be managed to fit that identity. Here are some of my production points that I believe need to be on every team.
Whether on stickies or on some sort of project management software like Jira or Hansoft, tasks need to be public so that each team member is aware of the work being done across the team. Tasks that are public give team members the ability to check those around them against what they're doing, helping them to hold one another accountable to the work they are committing to completing.
Set Short Deadlines
Setting short deadlines allows the team to complete work in incremental bursts. An old programming adage is that there are no big problems, just combinations of smaller problems. If your team is breaking down their problems to small bite-sized chunks, then they can tackle one at a time in rapid succession. If something goes wrong, it becomes easier to pivot at your deadline since they are closer together. Typically these short deadlines are somewhere from two to three weeks, but could change depending on the scope of the project.
Get something working quickly
When a project is beginning, the best thing the team can do is get something on the screen as soon as possible. The team then understands the game they're making and can be more easily unified in a single direction. Getting something working quickly also gives the team as much time as possible to test, iterate, and make the game better.
This ties in to getting something working quickly. The benefit of all the extra time is that your team can find all of the avenues that don't work, and move away from them to make something awesome. This means trying out all manner of changes to validate whether something works, and tossing it out when it doesn't. To keep the speed of development up, the team needs to agree that they won't get attached to their projects. If something is not working, and has been given due diligence, it's best to cut it and move on to something different. This cycle of trying something, failing, and moving to something else is the same as the iterative cycle, or something like the spiral method of development.
Have clear team standards
To me, team standards are the guidebook to how the team will interact with one another. It describes the team's totems and taboos, which are things they hold valuable, and things deserving of reprimand. It also sets the standard for how the team holds one another accountable. For instance, having a designated way to tell someone their work needs to be improved. During a team game project I was on, we all agreed that the phrase "I think you could do better" was how we would tell someone their work was not up to snuff. These standards become the user manual and allow the team to hold one another accountable.
Follow through on Commitments
Agile game development is designed to fit a creative team environment. As opposed to something like waterfall methodology, the team should be deciding what work they plan to do over the course of a sprint. When a team chooses the work they want to complete during a sprint, they are committing to completing that work. Part of a healthy team culture is making sure members of your own scrum group are completing the work they said they would, and doing the same for other scrum groups. Following good scrum hygiene and setting deadlines can help the team stay honest with the work they commit to.
Have Explicit expectations of one another
Both sides of a team relationship need to be explicit in their expectations of the other. Good documentation of pipelines and job descriptions can aid in communicating expectations between teammates. I find it important to stop a discussion or argument if it appears there is a mismatch in the understanding of expectations between two team members. Correcting these through simple and candid discussion lets the team get back to working productively as soon as possible.
Gather daily with the team
This often takes place in the morning as a scrum meeting. These daily interactions between the team are very important to developing team culture. Accountability is easier to achieve if everyone is more comfortable speaking to each other and talking about the tasks they need to complete or have completed. The max size for a scrum group or a small team is around twelve people. Past that there become too many people for the process to work smoothly and efficiently.