Helsinki-based startup Ovelin has developed two wildly successful guitar-learning games – becoming #1 music game in 34 countries with their games WildChords, GuitarBots, and guitar tuner app GuitarTuna. We are talking to their CEO Christoph Thür on how they organize their development process.
Tell us about yourself. What does your company do and what is your role?
I am the co-founder and CEO of Ovelin. We are making learning to play the guitar fun and motivating with computer games. You can play our games with a real guitar on your laptop, and you do not need any kind of special guitar or special equipment. The microphone on your device listens to what you play and then the game gives you real-time feedback if you do well or not – just like a guitar teacher would. The game is packaged in a fun way, so it is easy to approach, simple and step-by-step – and if you do well, you unlock harder levels.
How big is your development team? And how is it organized?
We are eight people on the development side. We have a visual artist, a 3D artist, an audio signal-processing expert, the lead programmer, and two additional programmers – one of which works on the game side and the other one – on the server side. We also have one person who is making the game content – the exercises, the tutorial material and the music. And we have a musician.
The team is based in Helsinki, except the audio signal-processing and the music guys, who are based in Tampere. They are coming here every week for one or two days, and then we have the whole team together.
Can you tell us about the development process?
For much of the time we have had two-weeks sprints. We plan the work almost with everyone individually – the developers, the visual artists and the management side. Then we would work in two week sprints, after which we would have a demo day, and the retrospective – and then plan the next sprint based on that.
For the last two months, however, we have stopped doing the sprints. We still have the retrospective, but instead of the sprints, we decided to use a priority document – that had to be alive and include all bigger features or tasks, with a person responsible for each. The development is then being done according to priorities – for example, if you have something that you are responsible for, but someone is coming and asking you to make visuals, and their item is higher in priority, then you have to actually help them on their request first before you finish your own work. So our process in a way is more similar to Kanban than Scrum now.
Do you have regular meetings for the development team?
We have one big office for everyone and we have 10am stand-up meetings, where we quickly go through everyone’s two most important things from yesterday and two most important things for today. Then, as I said, we have the retrospectives and the demo day every two weeks. Once in a while, when we meet major milestones, such as beta release or the full release, we agree on a feature freeze and put certain more flexible targets. We agree on things, and then about halfway through we see are we on track, because very often we realize that many things had come up that we did not plan, and a few things had gone away that we did plan, and that seems to work better for us.
Do you plan any changes to your process in the future?
It is hard to say, but we are trying to go more into the lean startup methodology. We are fairly happy with the priority document, but we would like to have a bit more determined task acceptance or approval criteria. Right now, it is often planned by the people themselves, or in certain cases by me, and we would like to have a bit more emphasis on the metric side – by looking at the data and A/B testing. That is one of the major updates we would like to bring to our process, now that we have the users and we can track what they are doing.
What other challenges do you have when it comes to development?
For us it is a bit difficult, because we do not have a product owner in the company. The product owner is basically me, but I do not want to be the only one, so we try to keep it open to the whole team. But often we end up with these overarching discussions – and it would be nice to have another product owner who is different than me.
Do you have any advice for other start-ups and their CTOs?
I think it is really good to take time, design, and go through the plan with the team. There is a big temptation to just say let’s work, so we do not waste time on planning, but very soon it starts costing much more. I also think it is good to learn what other companies are doing, but right now we have a bit unique game process case, so not everything that works for others would actually work for us. You have to learn from others – but you have also remember to actually think through it yourself, whether it makes sense for your specific case or not.