Major League Pickleball, one of the prominent pickleball leagues in the US, approached us with a variety of engineering challenges.
We took them through a two-week architecture sprint to help them understand their current codebase, engineering process, and how to achieve their future goals.
Leveraging the growing popularity of Pickleball
Major League Pickleball had two goals they wanted to achieve before their competitors.
First, they wanted to continue increasing player awareness, participation, and celebration of the sport as they established themselves as the dominant national Pickleball league.
Second, they sought to greatly enhance their app’s general feature offerings and data integrity on MyDUPR, which offers its users an advanced algorithm to rank players nationwide.
The application grew quickly. It was essential that it could scale, both in size and feature-richness—while also running smoothly and providing players with timely league updates. They needed a strong technical foundation and operational team to pull this off.
Offshore challenges
Major League Pickleball was working with another software development vendor, but they were lacking in strategy, engineering velocity, and a clear path to achieving their goals. This vendor was offshore without a strong technical project manager, so the communication between developers and owners was lacking.
We advised against hastily switching from one agency relationship to another, considering the client’s previous experience. Instead, we proposed a two-week sprint to assess their backlog, conduct a code audit, and evaluate infrastructure and engineering processes.
From this sprint, we objectively assessed their current state, addressing concerns about code quality, infrastructure, and engineering velocity.
What we found during the sprint
Mostly good news. We found that the code was in fine condition, eliminating the need for a complete overhaul. However, their processes were non-existent. Our go-forward recommendations involved implementing effective engineering practices, including these three core initiatives:
Refine the sprint structure
A major aspect of a successful sprint is collaboration and iteration across the entire team. We guided them on sprint structure best practices, which included:
- Daily 15-minute standup meetings where each team member gives a brief overview of what they worked on the previous day, what they’re working on that day, and if there are any blockers or immediate needs from other team members.
- A dedicated backlog grooming and/or sprint planning meeting where Product works with the team to make tickets actionable for the upcoming sprint e.g., asking questions to gain clarity around the task and its acceptance criteria.
- A dedicated demo where team members present new progress to key leadership and stakeholders for visibility.
- At the least, one release should happen every sprint. Ideally, this would happen quickly, as each bug is fixed or feature is completed. Releases should be painless and streamlined. This is what makes the CI/CD process so valuable.
- A retro meeting (at least one every couple of sprints) to evaluate what went well versus what could have gone better.
Improve code reviews
The peer-review process of a PR (pull request) is important and valuable.
It gives the involved team members the opportunity to provide feedback with a fresh set of eyes, which often reveals bugs before they’re deployed. It also provides visibility to the greater team to better understand different aspects of the application and how patterns are used. For Pickleball League, we gave them this set of instructions and a PR template.
When work is ready to be reviewed (either in progress as a draft, or complete), a PR (pull request) should be opened in GitHub and relevant team members can be assigned for peer-review.
In addition to doing the actual work, the engineer might also need to add documentation, write a migration, or write tests. We recommend using a PR template that contains a checklist for these items as a reminder that PRs can’t simply be merged ad-hoc.
Optimizing backlog management
Backlog management could be improved if the software development team could:
- Ask questions to gain clarity around the task and its acceptance criteria
- Help to fill in details on technical requirements or general tags/metadata
- Evaluate the level of effort (pointing/sizing)
- Depending on engineering workflow, pre-assign the tickets
These changes would enhance collaboration, increase development speed, and provide a clearer path toward achieving their objectives.
Acting on these recommendations
The client chose to work with us to implement these changes, resulting in improved collaboration, enhanced development speed, and realizing their objectives.
We quickly got a new operational team up and running to improve their cloud infrastructure, patch security holes, automate data pipelines, and add major enhancements — including a new API that allows third parties to consume up-to-date ranking data of players across the nation.
Learn more about architecture sprints.
Questions on your product’s architecture?
Software Architect
Jake Rainis
Discover more