3 min read
The Analytics Engineer and Scrum
In my previous blog in the series about the Analytics Engineer, I described what this role involves and how low-code solutions such as TimeXtender make this way of working possible. In this new installment I'll discuss how the Analytics Engineer fits within the Scrum way of working.
In software development, Scrum has replaced the waterfall method, but what does this mean for the information analyst? And how does this work in data development? In this blog I discuss what possibilities the Analytics Engineer offers!
From waterfall to Scrum
Traditionally, software was developed according to a waterfall project method. The steps followed each other literally, the way a waterfall can consist of different levels. First the information analysis was done, then the technical design, then the actual development, then testing, and finally putting it into production.
All of this took far too long, and often people didn't know exactly what they wanted beforehand. Scrum solved this by developing a small piece at a time in short development cycles, checking each delivery with the client: are we on the right track? What's the next step? This delivers results faster and gives the client more opportunity to make adjustments.
Scrum brought the team back together: everyone became a developer. That was a reaction against specialized roles within the waterfall method. There, every step had its own specialist, meaning everyone had to wait for each other and information constantly had to be handed off.
Scrum also started working with user stories, which were literally conversation starters: not first a detailed elaboration of requirements by an analyst, but a team of developers who go straight into conversation with the client. What do you need? How does this help you move forward? This way the whole team did information analysis, no longer just one person in one role.
The translation to data
Data engineers and front-end developers can also work in Scrum teams to jointly develop information products, such as reports or dashboards. They start with a user story, talk to the client, and work on solutions in short cycles, after which they gather feedback. Besides engineering and development, they also do analysis. This is how the Analytics Engineer comes about.
- gathering the question from the business
- building the data structures
- and delivering the dashboards.
A separate information analyst is no longer needed. Information analysis has become a capability.
If we compare the waterfall method with Scrum:
Information analysis has become a capability of the Scrum team; separate analysts are no longer needed. The developers (front-end and back-end) become Analytics Engineers.
The Analytics Engineer as the solution
At E-mergo we see this working well in practice. In this way of working, Analytics Engineers are directly involved in the end product. This results in more engagement and better outcomes. Engineers are no longer just a link in a long chain.
Not every engineer aspires to this combination of skills. At large organizations there's a lot of room for specialization, but for data teams of 3 to 10 people in particular, the Analytics Engineer combined with Scrum is a perfect solution
Curious how your data team can get started with Scrum? We're happy to tell you how we approached this and what lessons we learned along the way. Feel free to get in touch with our colleagues, we're happy to share our experiences.
Written by Stefan Timmerman
BI Consultant