On the Road to Full Stack Responsibility

Learnings from a team's journey to making their product foolproof, regardless of team switches or roles.

photo of Team Alpha
Team Alpha

Delivery Team – Pre-Season Management

Posted on Oct 04, 2017

Programming is hard, and being part of an engineering team is even harder. Depending on requirements, cross-functional teams are not equally formed with frontend and backend engineers in most organizations. Also, they are neither stable nor do people have an equal amount of experience. People come and go but software stays on, so we need to buckle up and maintain it.


One year ago we started a new project within Zalando Category Management, which is the branch of Zalando that looks after all of our fashionable apparel and accessories. We had to implement a new system to support the reorganization of Zalando Buyers into new, more autonomous teams, to enable them to work more effectively.

When we developed a Minimal Viable Product (MVP), neither one of our backend developers could support or add new features to our frontend. Due to project workload, our backend developers couldn’t collaborate with our frontend developers, nor had any visibility regarding progress. Therefore, to address these concerns we decided to introduce full-stack responsibility – and we failed! We failed because of several factors:

  • The frontend stack was too sophisticated for the tasks we had to complete (Angular 2 Beta + Angular CLI + ngrx store);
  • User stories were not feature-focused, but instead role-focused (separate backend and frontend stories);
  • It was hard to dive into frontend development on a daily basis.

Once again, we face the issue that some frontend engineers switch teams or roles, but the original team is still responsible for all the products that have been developed. We have since decided to become responsible end-to-end as a team, independent from team members or engineering roles.

What has changed since?

We learned from our previous experience that we have to decide on the instrument we use as a team, as well as share knowledge early and often. This is why we took a two-week sprint to evaluate two popular frameworks (Angular and React) which allowed us to make an informed decision this time around.

We also challenged our Product Specialist to provide us with feature-oriented user stories so we can break them down into smaller subtasks containing frontend and backend parts. It allows us to truly have full-stack user stories, including both frontend and backend, which leads us to working together and sharing the knowledge. All in all, this leads to a better product.

Finally, we introduced a “health check” in our sprint planning to track if we still work as one team. Every two weeks during sprint planning we ask ourselves: “Are we still one team?” We check our backlog and ask if the whole team is satisfied with the scope for the next sprint. Then, based on our criterias, we define the status of the health check and see if any immediate action is needed or if we are progressing towards our goal. It reminds us of issues we have as a team and keeps our commitment high in order to solve them.

It’s getting personal

When taking on the task of introducing end-to-end responsibility, we surveyed the whole team and looked for answers to a specific question:

What is the single most important thing YOU wish to take care of to make our full-stack initiative a success, and why is it so important?

Check out some of our answers below. Do you agree?

"That no one is afraid of changing code anywhere in our stack. Which also means we don't have single points of failure."

"Having good documentation about 'Where to start?' and 'What architecture, tools?' are we using. I think most of the time developers of one domain are just overwhelmed with where to start when you want to write code, do a bug fix or add a small feature. For example, if you want to contribute to a Play-Scala project as a frontend developer you don't know where to change things, what the structure of the project is, which things you have to keep in mind if you do an API change etc. It is the same when you ask a Java backend developer to add a new component to an AngularJS application. I think what could help the most is something that good open source projects are doing:

  • Provide a great README as an overview to the project
  • Provide Checklists and Guidelines for Contributors to describe shortly what a user would need to do if he/she wants to add a new component, a new API endpoint etc."

"Understanding that cross-functional teams are equally responsible members for each part of their system. While there might be only frontend expertise or backend expertise in the team, from the responsibility aspect it doesn't have any impact. Decisions, discussions and changes should be discussed independently from the roles of a frontend developer or backend developer. Increase the expertise of backend developers in the frontend and vice versa to make them more impactful in discussions. They would feel more responsible and feel a stronger ownership if they could bring up valuable arguments in the discussions. In collaboration with product, we should send at least one backend developer also to product-related discussions to avoid knowledge silos."

“To make sure that people with different backgrounds actually work together and practice pair programming. In my opinion, this is crucial to succeed and also to understand other ways of working.”

We’re just starting on this full stack journey. If you’re interested in how we progress, follow us to know more! The official Zalando Tech Twitter account is here.