Method

Introduction

Through trial and error and small iterations each sprint we have the latest years transformed from Scrum to what we internally today call the SportAdmin Method.

This is our attempt of describing how we do product development at SportAdmin.

It is still heavily Scrum-inspired, but we have also taken inspiration from others (like Shape Up). Most importantly though, we have tried to adapt it to fit our environment and needs, and not just do it “because someone else is doing it”.

It is far from perfect, but it is right now our best guess of how we can deliver the most user value possible. Give it another year and it might be different, and that is absolutely fine because it is a natural part of the process.

Feel free to head straight to the introduction of our 9-week cycle our just keep scrolling for some more context and background.

Background

To better understand where we are today and what shaped us, let's dive into the different phases we have been through, starting in 2016.

The Google Doc-era

In 2016 it was simply two developers and one from product. All that was necessary was a Kanban-style Google Doc to get the job done. The alignment was crystal-clear as there only were three people involved. With a small team and limited resources, the prioritization also had to be ruthless. We could not simply afford to waste a significant amount of time on initiatives that did not create value for a large segment of our users and our business as a whole.

With only three people we were forced to balance between improving the product and taking care of bugs. Although altering between proactive and reactive tasks was not optimal, it had some positive factors: the understanding of our users and the closeness to other departments.

The Scrum and Trello-era

Another developer and a consultant joined the team, and for the first time, we were about to launch a second product (MedlemsAppen) as a complement to our main product. This was a consumer-app and within an area that we previously had limited experience from. We implemented Scrum and started using Trello to be able to visualize the progress and better structure our work.

The JIRA-era

Both the development and product team continued to grow in the coming years, and it was natural that the next step was to switch to JIRA to take advantage of more integrations. Making the switch to JIRA also concluded the journey from maybe the purest simplicity, just a list in a Google Doc, to a little bit more processes with both Scrum and JIRA.

Although we had our main product (serving several verticals) and two apps, we worked with one single team, which meant that both product and developers were altering between completely different parts of our product and technical frameworks each sprint. The advantage of this was of course getting a good general grasp of our entire product portfolio and minimized person-dependency, but it also meant that the startup time was longer and the ownership diminished. Another challenge we faced (which is definitely not unique for us) was balancing product versus technical improvements.

The start of SportAdmin Method

As we both grew and at the same time broadened our product portfolio we realized in the beginning of 2020 that we started to drift away a litte bit from focus, speed and ownershup (the why), which had been vital factors early on. We struggled to balance improvements to our core product, bugs, technical debt, and new initiatives. We wanted to be agile and fast, but still, be able to focus. We did not want to have person-dependency, but we still wanted to allow groups to take larger ownership of a specific area. We wanted to improve our core, but still be able to bet on new initiatives.

Some processes and frameworks are definitely necessary and justified, but it is easy to get trapped in that it is the framework that governs us, rather than the people involved and what we as a group aims to achieve.

So we started to iterate on our Scrum method with the following questions in mind:

• How do we create an environment that can be both proactive and reactive when necessary?
• How do we allow focus but still have room for agility?
• How do we balance product and technical improvements?
• How do we deal with risk in terms of product and technical improvements?
• How do we balance the discovery versus the delivery phase?