Scaling product development through collaboration

A Joint mission and pooled know-how

A product is built by one team – this is a rock-hard truth for many people. But what if a large software product requires more than 20 colleagues to achieve the desired outcome within a given window of opportunity? Does it make sense for one team to be exclusively responsible for the new product while another sticks to the existing one? These considerations resulted in discussions on which initial steps to take by the end of 2019. 

We were worried about our meeting culture and wondered whether and how software development could succeed within such a large team. How was Sprint Planning supposed to work with over 20 people involved? Which architecture would the teams choose – and how were we to tackle the decision-making process itself?

This joint responsibility leads to considering the needs of our stakeholders on an overarching domain level. They could be fulfilled in both products – depending on their ROI (Return of Investment) and needed time-to-market. We first of all jointly prepared a one-pager, noting the current state and pointing out how we intended to improve from a customer, user, and stakeholder perspective. We held a series of workshops to foster alignment.

Moreover, we jointly discussed our mission and the product vision, refining both iteratively together with our stakeholders. We naturally found the first joint workshops quite demanding, as the whole undertaking resembled a mammoth task in unknown territory for us. What’s more, most capabilities constituting the existing product needed to be integrated into the new one somehow - increasing process complexity even further. 

In the long run it really helped to have many of these difficult discussions early on, and jointly aligning with regard to some cornerstones helped everyone on our shared journey.

We agreed to start with two teams: One exclusively focussed on the new product, while the other was in charge of also running and developing the existing product, which also used a different tech-stack. To foster know-how transfer on business domain level, two colleagues switched from the existing product to the new one. Our long-term plan was to have both teams develop the new product together.

Frameworks, experience, and adjustments

Since we wanted to work with two or more teams on our new product, we looked to orientate ourselves towards the LeSS Framework (Large Scale Scrum): this provides a lean structure with a manageable number of meetings and seemed a suitable starting point for our journey. LeSS nicely extends the known Scrum Guide and its principles and enables scaling with multiple teams. As both teams already had experience with Scrum, we were happy to work on existing knowledge. 

We started with a two-week sprint, synching it for both teams. This short sprint duration allowed to have many retrospectives to reflect on and adjust our approach in the initial phase. Each team carried out its own retrospective, followed by a joint one. 

In the reflection phases it became clear that this setup was not particularly productive. There was no point in more than 20 people participating in one retrospective meeting. Instead, both teams established a system of rotating representatives for the joint meeting, thus contributing important team topics and taking any actions back to their team. This is just one example of an adjustment; the teams' own enthusiasm and experimentation spirit and the wish to gain experience were constantly placed centre-stage.

We were continuously reflecting and adapting, which sometimes was very exhausting for all of us. We had assumed that necessary changes would take place more slowly with two teams involved, but in fact the opposite was true. It felt like the rhythm of change was so intense that after a two-week holiday, appointments were staffed differently or no longer existed at all and new coding guidelines or additional communication channels had been created. This demanded a lot from everyone involved – we all had to stay constantly on the ball. 

From our perspective, however, both our shared effort and our will to examine and change everything at any moment proved to be an absolute win for the teams and the joint product development process.

A successful experiment in new collaboration

Every introduction of new processes first needs time and space for experimentation and learning. In the case of a joint product responsibility in a scaled product development process, it makes sense to let teams learn iteratively about new structures and processes, allowing them to figure out for themselves which approach works best. At the same time, it’s important to establish a firm foundation for team spirit and purpose. With our mission and product vision, each team was able to contribute to the new product at an early stage regardless of the current skill set and to consolidate, thus helping to shape the new product.