Daan Stroosnier and Mees Strooker recently held a webinar entitled ‘Felyx: Clearing the road for sustainable DataOps-driven architectures’ in which they discussed how the e-scooter rental service redesigned its data strategy and infrastructure. After the discussion, we asked these data experts about the lessons they learned from this great DataOps adventure. What can their insights teach other companies?
Lesson 1: The first step is always choosing the right people.
In our article, ‘Felyx: Clearing the road for sustainable DataOps-driven architectures’, we describe the new data infrastructure that Stroosnier, Strooker and their colleagues have built over the past seven months. ‘When you’re starting a major project like this, where you are essentially building an all-new data warehouse, you need the right people. In our industry, that’s a challenge, because there’s a shortage of skilled technicians. Of course, we knew that from the very beginning, but I think we may have underestimated it’, says Daan Stroosnier, Global Head of Data Analytics.
So, how can you tackle a problem like that? Stroosnier says, ‘You don’t necessarily have to tackle it head on, but you do need to face the facts. It’s something that you should consider in your planning and in the processes you design. This will also help you to manage people’s expectations, so you don’t wind up disappointing your stakeholders, for example. And it can definitely have an impact on your decision-making throughout the entire project. You might decide that you have to build things more gradually than you would have liked. Or you might have to devote half of your team to working on a new project while the other half works on expanding what you’ve already got in place, instead of everyone working on the new project all at once. Another option is to wait until you find the right people before you start. That way, you have a bit more critical mass.’
Lesson 2: Integration is not just for systems, it’s for people too.
Creating integrations between systems is the goal, but integrations between people are equally important, says Stroosnier. ‘We’ve got people with a wide range of skill sets, backgrounds and areas of expertise; whether they are data engineers or data analysts. How do the various solutions in our data architecture work smoothly together? How can we test to make sure things are working? How do we scale up our proofs of concept? You’ve always got to take the time to invest in having discussions like these and figuring out how everyone can work together.’
The goal is to galvanise your team, so that synergies unfold. Stroosnier says, ‘Our various teams are all quite autonomous, but it would have been great if we could have integrated them a bit more with each other.’
Lesson 3: Find the right mix of in-house employees and freelancers
Stroosnier says that Felyx hired a lot of people and trained them on their current technology stack. ‘In the early stages, we benefited from bringing a freelancer on board who had specialised expertise. He was able to share a lot of knowledge with our team. But in a case like that, it’s important to keep the freelancer on board for long enough, so that they have time to pass on their knowledge and so that you have time to continue building your team. But you can’t rely too heavily on freelancers, or else you risk losing the knowledge whenever they move on.’
Lesson 4: Scrum is good and fine, but be realistic.
Data engineer Mees Strooker estimates that around 95 percent of all DataOps teams work with Scrum or another agile method. That’s not a bad thing. But as a team, it’s important to do what’s right and not just allow the organisation to drag you in one specific direction. ‘The company wants to go one way, so you’ve got to meet specific deadlines so that other teams can then move ahead. Just be careful that you don’t fall into the trap of agreeing to a specific deadline for your team just because that’s the deadline that the company has in mind. Sometimes, that is not realistic. It’s much better to plan according to what your team is capable of delivering for each week or for each sprint. If those deadlines don’t match with the company’s deadlines, then be up-front about that.’
Strooker shared one other valuable insight related to Scrum: ‘Connect with the other teams that you’re working with, and don’t wait until the last minute to do that. That will enable them to plan ahead as well.’
Lesson 5: Make sure you can always go back.
Felyx always insisted on having the flexibility to adjust or go back if necessary. Strooker says, ‘We always started with the question: if we implement this tool, what will the consequences be? As a result, we never chose the wrong tool. We always made a sub-selection first in advance. Often, we even implemented two different things and did a proof of concept twice before making the choice. That approach has really paid off.’
It is also consistent with the modular approach that derives from the Unix philosophy, says Stroosnier. ‘We are always looking at the individual components of our architecture and trying to find the right solution. This has helped us to make the right choices and it’s given us the flexibility to take a different direction on time, if necessary. I think that’s a very useful lesson for other companies.’
Lesson 6: Choose a scalable data model.
Stroosnier says, ‘Hindsight is always 20/20, but we should have thought more from the very beginning about the data model, so that it would be more scalable for the future. As it is, we went with sort of a pragmatic route, because we saw that we hadn’t put enough thought into it in advance.’
It’s the result that counts
If you only look at the lessons learned, you might end up with a negative impression of the project. But Stroosnier and Strooker insist that the good far outweighed the bad and that the result is as solid as a rock. Strooker says, ‘I am very happy with the tool stack that we’ve got now. You can see the improvements everywhere, in the quality of the data and in the speed with which we can build things. At the end of the day, our job is to provide information and to make predictions for our own employees. Now, we can do that much faster and better than ever. And, it must be said, the reason for that is because we had the right data analysts, data engineers and data scientists.’
The project has paid off with many tangible benefits: fewer breakdowns, better data quality, the ability to work faster, allowing more people to use the same tool simultaneously, improved operations, more scooters being available for customers, more insight into the customers, better customer service and the ability to work more efficiently.
Stroosnier says, ‘Now, we are much more in control of our data warehouse. Both in terms of performance and cost management. We can see how well it’s performing—and all for an acceptable cost. It’s important to monitor both of these aspects and keep them under control, especially in a growth model like ours, in which our scooter fleet doubles in size each year.’
