How We Work: Client-Side SDK Dev

How We Work is a blog series dedicated to sharing some of the work processes here at Intowow.

Here’s a snapshot of how the client-side development team at Intowow approaches and executes each sprint to maintain the world’s leading mobile SSP SDK to support monetization for app publishers. Publishers have their own update schedules, so our goal is to continuously optimize our SDK releases with new features and bug fixes so that we are always ready when a publisher wants to upgrade to the latest version of our SDK. To achieve this permanent state of readiness, our sprint interval is set at two weeks. Each sprint starts with a planning meeting in which the objective is to determine the goals for the upcoming sprint and assign roles. In this kickoff meeting, the product management team delivers a brief and the team walks through the backlog to produce a list of features and bugs to be included. We then scope out and prioritize the list of issues, removing any that we don’t have enough resources to accommodate. Once everyone has full understanding of the sprint, the team leads (Android, iOS, test) assign tasks and we get to work.

We buck the scrum trend of short meetings and meet every day during the sprint for up to a full hour, which allows everyone to give an update of progress and challenges. Meeting leadership rotates to a different team member for each sprint, requiring each teammate to learn to lead and project manage efficiently. Unit testing and code review are essential to the efficiency of our approach. We conduct these tests and reviews in a couple of different ways.

First, each developer must write unit tests as part of the coding process. Additionally, Android and iOS developers review one another’s work to achieve mutual understanding and reduce late-stage corrections. The architecture of our SDK is similar enough to allow for iOS and Android engineers pair up to work on features. When a pull request (PR) is created on Github, at least one Android developer, one iOS developer, and an engineering manager will review the PR. As part of our continuous integration (CI), testing on a new PR begins simultaneously to keep things running smoothly. Once approved, it is merged into the development branch where the Test Team will check out new features and bug fixes.

Finally, we move on to the release stage for final testing and approval. When all tests are verified by the Test Team, the release branch will be merged back into the master branch and CI will be triggered to create the official release version, making the updated SDK available to all publishers. Workflows differ from company to company, and this one works for us. It’s an ever-evolving process as we are constantly in pursuit of providing feature rich SDK on a reliable release schedule. If you’ve got feedback or questions, we’d love to hear from you!