gap intelligence’s Product Development department is small but mighty, and supports about a dozen software applications on a daily basis. We employ developers in multiple US timezones as well as on the other side of the world in Uzbekistan. How do we do it? In the Product Development department, our distributed team members are split into two teams, Roadmap and Prod Support. Each team has a unique purpose, and without both, it would be much harder for us to collect and maintain gap intelligence’s GFD (great freakin’ data).
The Roadmap team is primarily responsible for new feature development. At any given time, their focus is on one “epic”, a large feature set that is developed and deployed incrementally, but may be released to our customers (or internal users) all at one time. The epic can vary in size but typically involves many stories of varying complexity. Epics can span from the length of just one or two 2-week sprints to many months. The Roadmap team drives gap intelligence’s products forward by creating new tooling and functionality from scratch. On Roadmap, they collaborate heavily because all of their work is closely related, and one person’s work often depends on the feature another person is working on. Right now, our Roadmap team is a little more than half of our department, since we are working hard to wrap up our current epic before the end of the year.
Let There Be Light
The Prod Support team, on the other hand, exists primarily to support existing products (hence the name). Prod Support’s motto is “keep the lights on”—they make sure everything is working properly, so that the rest of the company can do their jobs! While the Roadmap team works primarily on one or two applications at a time, Prod Support works on pretty much all of them, and the backlog is much more varied, with stories that are typically unrelated to each other. Prod Support is largely responsible for resolving bugs reported by users, most of which come up as a result of constantly changing external APIs that our systems are connected with.
The Prod Support team also tackles a majority of the tech debt. When you have software systems that have been around for years using open source software, upgrading packages and dependencies is a constant responsibility, because old stale code is prone to security vulnerabilities and may stop being supported at any time. When the Prod Support backlog is lean, the team also works on feature development, pushing forward the products that aren’t the Roadmap team’s top priority. Smaller scale, one-off feature requests, which often come from internal stakeholders, usually get tackled by the Prod Support team—otherwise, these requests might sit in the backlog for months before the Roadmap team has the bandwidth to implement them.
Both Prod Support and Roadmap are anchored by a Product Owner, who sets the backlog priority by ordering stories. Each Product Owner partners with gap intelligence’s stakeholders to write stories with clear Acceptance Criteria, and once a developer has implemented the code for that story, the Product Owner tests the implementation on both the QA and Production servers, to ensure everything functions as expected. They collaborate heavily with our Scrum Master, who runs the scrum ceremonies on both teams, as well as our Senior Product Manager, who looks ahead to scope and plan future epics. Together, this group guides the strategy of our department and remove roadblocks, while the developers are responsible for the implementation.
The Coder Shuffle
Although every developer at gap intelligence ultimately needs to have some level of comfort in all of our software systems, we each have our strengths and preferences when it comes to the technology we build with the best. And as the priorities shift, the developers periodically move from one team to the other. Developers who are especially proficient at system architecture might work on Roadmap at the beginning of an epic, as the groundwork for a new feature is laid, the models written, the database schemas created, the code conventions established.
As the work becomes more design heavy, developers comfortable in React and CSS might get moved to Roadmap, to ensure a new customer-facing front end is implemented in a clean and performant way. And when an old legacy system needs to be upgraded or migrated to a new server, the developers who love Dev Ops and refactoring might get moved to Prod Support, to create a test plan, create server backups, and then incrementally upgrade the legacy code, all the while making sure the impact to end users is minimized. When we move developers, it’s also important that on each team, a few developers stay the same, so that they can catch up the new team members on the technical decisions that have recently been made.
Moving developers from team to team has a number of benefits. First of all, it helps to prevent knowledge silos, where only one or a few people have knowledge or comfort working on a specific task or in a specific system. When more developers are able to work on the same system comfortably, it creates protective redundancy, so that if someone is out sick, goes on vacation, has a baby, or decides to leave the team entirely, the system can still be maintained. Companies that rely on individual “rockstar developers” to keep their software afloat can be dead in the water when their rockstars aren’t able to work. Instead, we share information readily and give our developers every opportunity to practice on codebases they’re less familiar with.
When we shuffle team members, they also usually bring new ideas to a project. Someone who’s unfamiliar with an epic might understand the code differently, and ask valuable questions or make suggestions that help us come to better solutions and avoid groupthink. Our team collaborates by pairing, especially when team members have recently moved, to get everyone up to speed and enjoy the benefits of fresh eyes. As previously mentioned, rotating developers allows us to take advantage of each individual’s technical skills in different areas. Not to mention, working on different systems from time to time is good for our professional development and keeps the job interesting.
We have a satellite product development office in Uzbekistan and we integrate those developers into both teams, rather than having them work in isolation on a separate backlog of features or bugs. This allows both Prod Support and Roadmap to get the benefit of basically round-the-clock development, since their day is our night. Both teams hand off code to our Uzbek counterparts at the end of the day, and we have morning or evening meetings a couple times a week for real-time team discussion with our international coworkers.
Two Teams are Better Than One
Though our approach is bit unconventional, after numerous experiments in team configuration, we’ve landed on something that we feel works really well. As our team grows, we’ll always remain open to adjustment. For now though, Prod Support will keep the lights on, and Roadmap will keep driving gap intelligence’s software forward.
For more than 17 years, gap intelligence has served manufacturers and sellers by providing world-class services monitoring, reporting, and analyzing the 4Ps: prices, promotions, placements, and products. Email us at firstname.lastname@example.org or call us at 619-574-1100 to learn more.