At Battlefy, every day is exciting and challenging from an engineering perspective. We have a lot of fun tackling difficult problems from writing high performance seeding and score reporting code to building infrastructure that can scale to millions of users on a day-to-day basis. In addition to the incredible challenges, we always strive to improve and have fun.

In the morning we have scrum at 10:30am where we write on Confluence what we accomplished yesterday, what we’re going to accomplish today, as well as, note any issues that are blocking your progress, such as, a dependency on a mockup. This wiki page is created on a day-to-day basis so we have a historical log that we can quickly sift through and ensure we don’t lose any important information. On the wiki page, we ensure that we list out the projects in flight and we determine if they are on track, behind, or ahead. Based on this information, we’re able to discuss how we can get things back on track or if we need to re-adjust teams to ensure a feature lands on time. Subsequently, we try to keep our notes super small and concise so that anyone can quickly scan through it. After about 5–10 minutes of reading the daily scrum page, we go around and see if anyone has important questions after reading the daily scrum notes. Consistently, we’ve been keeping our scrums to less than 15 minutes for the past few weeks!

After scrum, we distribute into our teams. For a more detailed explanation of our software delivery process, check out How We Ship!

We currently have 4 strike teams focusing on different company objectives which includes quality of life, growth and experimentation, business intelligence and infrastructure, and core platform features. Each strike team can have 2–3 engineers, 1 designer, and 1 business analyst. Even though we have many teams, engineers are encouraged to share knowledge whether its patterns they’ve used to solve a particular problem or new tech that they think would be valuable to the company. We have weekly dev huddles where we do much of the knowledge sharing, as well as, identifying key points in our infrastructure that need attention, specifically, technical debt.

Each strike team is responsible for end-to-end delivery of their features, which include

• defining user stories: find out exactly which problems you want to solve, measure the ROI of a user story, and sort by the highest impact on user acquisition
• sketching out wireframes: how would a user interact with a feature to get value out of the platform

• defining technical architecture, performance concerns, and scope: based on the wireframes, we break down the user stories into more tasks so they are easily digestible by any engineer on the team and we document everything on Slack (feature-specific channels) and Confluence to easily communicate how the feature works
• doing daily demos within the team: progress, progress, progress!
• releasing several times a day: depending if the feature is already on production, we practice measuring and iterating quickly based on the metrics being collected on a feature

Based on the above and if the feature is brand new, it usually takes a day to go through the user stories, investigate, sketch, estimate, and list out performance concerns/technical architecture before writing any code — we like to practice “start with the customer and work backwards”. We’re continually improving our process and as we start to have more teams, each team will start to evolve their own processes that make them more effective at delivering value for our customers. Even now that we’ve been practicing this process for a month, we’re starting to see a few teams adapt their processes based on customer feedback.

As passionate gamers and as enthusiastic as we are about eSports, at the end of the day, there’s always a teammate that will want to get a team together to play League of Legends or Hearthstone or Counter-Strike: Global Offensive.

Work hard, play hard! Good luck and have fun!