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:
- CIA — Content Ingestion and Aggregation: As DPG Media has grown due to acquisitions, not all content for all brands are stored in a single application or a similar format. To be able to have a brand-agnostic recommendation pipeline, content needs to be transformed to a universal format and enrich it with universal metadata. This was exactly the core mission of the CIA team.
- NPS — News Personalization Squad: In order to show personalized content to a user, Machine Learning Engineers step into build recommendations — up to an individual level. Because it concerns news and text, this starts with NLP — Natural Language Processing. NLP includes user understanding and ends with building (and serving out) recommendation algorithms. Because of the large scope, we even introduced subteams, which are focussing on user understanding, content understanding and ranking algorithms.
- FBI — Front-end and Back-end Integration: At DPG Media we believe in native development, hence this team was focusing on native widgets for Android, IOS and web, including one single back-end. In order to do so they were depending on the outcome of the News Personalization Squad, as well as on all teams building our digital products to integrate their widgets.
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:
- Being a team of 23 colleagues and considering perfect team sizes around 6 people — you should be able to feed them with two pizzas, no? ;-) -, it means that we should aim for 4 feature teams at a time. Because having only 2 Android Developers would mean some features never get implemented on Android…
- Having fixed teams does not allow you to fully prioritize one feature and have, say, 10 people work on it at the same time.
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:
- First 2 sprints the Android Developer works for feature 1, after which the Android impression has been finalized (at least with Apiary mocks, live connecting needs to happen later)
- The third sprint he works for feature 3 and the team dissolves afterward as the feature has been delivered
- The fourth sprint he works for feature 4, after which Android impression has been finalized (in this case with a live connection to a non-complete back-end)
- Sprint 5 he works for feature 2 (and depending on the status he will continue after that in the same team or a different one)
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
