This post is summary of the YConf 2020 talk How to create more business impact with flexible teams by Jan Hegewald (Director of Engineering at Zalando) and Rebekka Beels (Head of Engineering at Zalando)


Usually, Software Engineering teams are organized around a fixed set of components which they develop further and maintain. Such component teams gain a high level of expert knowledge about their services. However, with agile product development, it often is difficult to implement the most important initiatives with such teams. This leads to a situation where the teams do not work on the most relevant business topics but on those for the respective team. At Zalando, we introduced a new model where we shape teams flexibly around business goals to create the highest impact. How we organize these teams and which challenges especially for the software quality need to be addressed, will be explored in this talk.

How to create more business impact with flexible teams


The summary slides describes the pros and cons of stable and flexible mission teams, Zalando's mission process, pitfalls to watch out for as well as the observed effects in terms of midset shift, results and flexibility:

Stable vs flexible teams

Stability allows teams to build up knowledge, specializing in the domain and technology.

However, when multiple teams are involved in big initiatives, stable teams can be a blocker to business impact. The overall work in progress is high but throughput is low: Each team's backlog contains parallel work, contributing to various topics, small tasks block the big things. Another problem is unequal utilization: Some teams aren't busy, while others have too much work and become a bottleneck.

With missions and flexible teams, Zalando achieves
    1. Focus and avoiding distractions
    2. Moving the big blocks
    3. Overall Utilization
    4. Increased Velocity

The Mission lifecycle

Missions have a regular lifecycle of 2 weeks to 4 month and start with Pitch, Sign-up and Kickoff.

In the mission pitch, product managers explain the mission (Goals, Milestones, skills, size) and advertise the missions to the teams.

Colleagues sign up by selecting their preferred missions (#1, #2). Based on this preference, Engineering Managers do the final assignment, because they are responsible for staffing and people development.

The team organizes a mission kickoff to create the roadmap, milestones and backlog. They also decide on ceremonies and ways of working.

At the end of the mission, the team dissolves.

The authors give an example of how multiple mission of varying length and size ran in parallel in the POP department (15-30 engineers) during 2020:

Delivery Models address different types of work & product lifecycle

The following graphic explains how different types of missions exist for addressing different types of tasks or to cover different stages of the product lifecycle:
Zalando follows a 4-stage approach to product development called 4D: Discover, Define, Design, Deliver. Missions can be split across the product development cycle to support needs for each phase:
  1. First, an exploratory missions defines the business goal and customer understanding
  2. Implementation follows in a design & deliver mission

Not all work is new feature development and software systems require ongoing care. The mission model accounts for maintenance, operations and improvements in various ways:
  1. Reserved time at the end of each mission
  2. Delivery missions with the goal of technical improvement
  3. Bob missions for small and operational tasks
Incident Handling and prevention takes precedence over mission tasks

The mission approach also allows working with other departments. Innersource enable another team to contribute to our services. For closer collaboration, Mixed Delivery Mission allow teams from different departments to go on a mission together.

Challenges of mission teams

Knowledge transfer became a challenge. When reteaming regularly, colleagues require broader knowledge and less specialization.

Jan and Rebekka realized that missions led teams wanting to standardize ways of working -
Lacking ownership and degrading Quality
  • Addressed through boyscout principle
  • Plan time for cleanup at the end of the mission
Disruptions

The outcome: Increased velocity and mindset shift

  • Velocity increased
  • Mindset of ownership & engagement

Our Experience

  • like feature teams
  • Mission has a certain scope and feature to enable
  • Other teams are also part of the mission - data consumers and producers
  • Developer anarchy. Devs have freedom and are gelled
    • Devs write stories, create roadmap
  • Design phase
    • outcome solution document
  • mission kickoff -> driven by team
    • roadmap, phases,
    • ceremonies

Further Resources