Norway’s fluxLoop and Helmes have had a successful remote work relationship for many years. We’ve been busy creating different web-based and data analytics solutions for fluxLoop, which is a leading provider of analytics for the mobility and retail sectors.
The people at fluxLoop analyze signals from smartphones and sensors to create an accurate and verified picture of the physical flows of individuals, allowing clients to gain actionable insights and efficiencies to drive revenue while protecting end-user privacy. Helmes supports their team with everything that has to do with end-users.
Our remote working strategy has worked wonders for everyone. This is how the process goes…
Before a significant project, we always have a preliminary analysis phase. fluxLoop gives us a general description of the obstacles that need to be overcome. We work through their information, ask additional questions, and find a development scope. It means finding out what the costs are and splitting the project into phases.
In most cases, the project phases are only the essential parts that we certainly need to go live (“MVP”), what we need immediately after going live, and finally, the “nice to haves” that we strive to include at later stages.
The preliminary analysis team usually consists of fluxLoop’s representative from the business side and one to two key people from the technical side. From Helmes, an analyst, a team leader, and a lead developer are involved. The joint team puts together the preliminary scope, the development roadmap, and the budget. There are daily meetings between the teams via modern communication tools like Microsoft Teams or Google Hangouts.
The analysis phase takes anywhere from a couple of hours to two weeks, depending on the complexity of the development.
After the preliminary phase, we start to set weekly goals. Our analyst and fluxLoop’s business-side representative meet one to two times a week. We use the list of tasks we put together during the analysis phase and start to add detail to them. We need to make these tasks so explicit that our analyst can produce development assignments for our team.
There are usually three to five people working for a project at Helmes and a business development person and a few technical people from fluxLoop.
The method we mainly use with fluxLoop is called “Kanban”. While Scrum, another popular agile method, is focused on 1-2-week sprints, Kanban focuses on limiting the amount of work in any stage at any given time.
We review our Kanban board once or twice a week in our regular meetings. We add new tasks to fill our Kanban capacity for the analysts, developers, and testers. In the same meeting, we analyze new tasks and review completed functionalities. While with some other customers we have regular demos at certain intervals, then for fluxLoop we use the same meetings.
Regularity is a key success factor. Having certain timeslots ensures the rhythm of the project for both Helmes and fluxLoop. We generally meet online twice a week at the start of a project, then less so as the project nears completion. To point out something else, it is the importance of always creating and sharing meeting notes – a typical responsibility for Helmes analysts. We’ve learned the lesson that one should not overly rely on one’s subjective memory.
During the first phase, we want to achieve an “MVP” or the “minimum viable product.” This is the product with a minimum number of features to be usable by the end customer. What constitutes an MVP is up to a considerable amount of debate and decided in the analysis phase. We usually agree on the budget to achieve the MVP and Helmes is responsible for keeping it while achieving the result.
After MVP we usually take a more iterative approach, as we can add features as needed to our already usable product.
When the project is completed, we have a “lessons learned” workshop where we discuss what went well and what could have been done better. We also do our best to meet face to face once in a while (bi-annually); either we visit them in Norway, or they come to Estonia.
As with all different areas, the same applies when we are looking at the cooperation with fluxLoop from our data team perspective. While there are similarities between software development and data, the majority of the work is still different.
SEE ALSO: Unlock the power of your data
Our data projects start with an onsite meeting where we build an understanding of the project, agree on the deliverables, and set a rough timeline for both: the overall project and an MVP. We also agree on a model for communication and updates. As we’ve been long-term partners, there is trust between the two sides, so when it comes to meetings, we’ve agreed that less is more. On occasions, we might not have a touchpoint for weeks, but at the same time, this time is being used to bring value to the customer through completely focusing on the ongoing sprint.
Deliverables are shown in an iterative way. For smaller solutions, we might just hand-over a solution to them as long as they are familiar with the inner workings of it. For bigger deliverables, we usually agree to a meeting with the fluxLoop team to take them through the solution. This includes giving them a working demo, talking through the methodology and logic, and agreeing to the next steps.
Cooperation between fluxLoop and Helmes has worked out well. There is trust between the two parties, and our collaboration seems to be developing positively. We are both comfortable with remote working as our standard in our partnership.