The team is dead, long live the team

Move to a feature focus instead of a component one

Written by Wannes Rosiers, Area Manager News Personalization & Data

A typescript Developer, a Machine Learning Engineer and an Android Developer walk into a bar…

This could be the start of an awful IT joke, yet it’s not, it is our reality. We didn’t even mention our entire diversity: IOS Developers, Web Developers, Machine Learning Engineers from a software engineering background, some from an academic background and even a DevOps Engineer.

At DPG Media we need to bring news personalization to our consumers. As a team we take ownership over our infrastructure, data processing, machine learning algorithms, back-end development and front-end widgets for all device types to be integrated across all our brands. We’re with 23 colleagues with so many different capabilities. So, what is the best organizational structure to flexibly prioritize, maintain focus, and increase oversight?

The past — Component teams

DPG Media has structured IT in so-called areas — multiple teams working on one product or platform — where every area works to solve a specific business domain. In the news personalization area, we focus on:

“How can we bring the most relevant content to every individual user?”

Initially, we started by dividing the area into three teams with a specific component focus. We call them ‘Chained components’: every team is dependant on the work from the previous one:

Those teams got some cool, fancy names and focussed on:

Not so long ago we did a retrospective about this organizational structure. The most important upside of this organization was the focus and the ownership it was bringing to people. Yet, we decided that it did not compensate for the downsides, namely too many dependencies, not enough oversight, fragmented knowledge and the lack of possibility for global prioritization.

The future — (Short-living) Feature teams

That’s why we decided to move to a feature focus instead of a component focus. A feature in our setting should always have at least one front-end impression which can be as small as “allow consumers to follow an author to get all his content recommended” or as big as “show an unlimited amount of recommended articles on a personalized section page”. We believe that this will solve most of the issues we have identified.

Yet an everlasting feature team set-up introduces some conflicts with what we want to solve as well:

Therefore, we decided to make our feature teams naturally short-lived. Once the feature is delivered, the feature team dissolves and people are assigned to new features. My team is dead, long live my new team… That’s why in every sprint your team set-up can change, you can kick-start a new one or you can be adopted by an already existing team.

At a certain point in time, feature teams can look like this (old team names included for comprehension). Every team has at least one front-end capability to make sure that whatever we build, immediately gets an impression on one device-type.

To ensure that we get to feature parity across all device types, a team typically starts with a more constant back-end and machine learning part and a fluctuating front-end part. For example, in the first sprint the team has an Android Developer who usually builds his work with Apiary mocks, in a second sprint he moves to a separate team and an IOS Developer joins, and in the final sprint the team has a Web Developer.

Over time the close-collaboration team of the Android Developer can look as follows:

This way of working introduces full flexibility regarding prioritization, keeps focus on your feature increases oversight (as we know which features we are working on and do not have any dependencies between them) and it brings a hackathon feeling: every day you actively see what you’re working on!

We know, we still have some challenges to face: because how to cope with ownership? How to bond your team? We look forward to shaping it even further to our needs. Therefore, in the next blog we will inform you gladly about this follow-up. If you want, you can join us in doing so, as we still are looking for some colleagues! :-)

More information? Contact Wannes Rosiers — wannes.rosiers@dpgmedia.be

We are the tech team behind the digital products of all DPG Media’s brands and internal apps!