Our space adventure: self-forming teams @ SDA SE

This article was happily co-created by Verena & Peter.

Nothing is as crucial and fragile as the team setup in an organization. The SDA SE has come a long way from traditional backend/frontend teams, cross-functional teams, top-down decisions, frequent changes, and long-lasting teams to self-forming teams.
Our recent episode started when product (Philipp), tech (Karsten), agile (Verena) and people lead (Peter) got together on a dark Corona winter day after one of those rare in-person meetings and had the idea that we should try something new for this important topic.
This article is about our space shuttle launch, what went well, how we almost crashed, what our duck tape was, and the questions that are still unanswered today.

How we failed to build a spaceship that stayed in the air long enough — our history of teams

While being a quite young company, we already tried out quite a few different team setups and approaches to form the teams. Every time we thought we had found the perfect setup only to realize then that we need to go to the next step in evolution.

Shortly after being founded, we started with THE traditional approach of developing software, namely having a backend and frontend team. This brought us two highly efficient and capable teams with fast progress in our first days. But over time, two disadvantages became obvious: The first one was that Conway’s law hit us hard and we started creating technical architectures that followed the team setup and not what we actually believed was the best technical approach. Second, scaling was hard when additional customers required more people to work together. This setup also required us to frequently change the composition of the teams to react to changing demands.
Analyzing this and seeing how we had trapped into Conway’s law, the consequence was to change to cross-functional teams following pre-defined domains (using DDD) for the team boundaries with the additional goal to have stable teams. Management and some key players sat together and defined the new teams, which were then communicated to everyone. Now we had the perfect team setup with big team autonomy and clearly defined boundaries. Going forward, new team members were added wherever required while new topics were added to the best matching domain avoiding (bigger) changes for the teams. Even though this may sound like the perfect solution, it caused the domains/teams to become fuzzy as not every topic matched the core domains. The loss of focus and the growing team sizes started to cause more frustration than the benefit of long-lasting stable teams could provide.

So what to do? Did we try everything — or was there another solution? We did not know yet. Per coincidence (?) around the same time, we started to rework our company goal process. As similar people were involved in both processes, we had the glimpse that maybe we could join forces and solve the problem with a combined solution.

Co-creation for our new spaceship — our motivation

As described above, we were used to others deciding the team setup for us. Being part of the system ourselves, we also remembered our feelings when those decisions were communicated. And maybe we had other thoughts and ideas in mind back then that never got a chance to make it into the process.

Do we think we can decide best for the people who are affected and do the job every day? Does this fit our company where we expect and value self-organization and ownership? And are we not missing out on great chances for development, individually and as an organization?

Some few people can surely come up with one solution — one of many. But we started to believe that together we could come up with an even better one.

“We choose to go to the Moon[…], not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills […].” — John F. Kennedy

We were thrilled by the idea of finding a solution approach that would integrate:

• The goal of creating focus and best addressing the company’s business needs
• The active participation and shaping through the people involved
• The possibility for everyone to reflect on personal and business needs as well as development opportunities

We hoped that this could only lead to increased acceptance and satisfaction and thus to a better working mode and performance.

That is how we came up with the idea of “giving power to the people” and having the teams form themselves, based on only a few guiding barriers.

Learning from other spaceship builders — our approach

At this point, we knew what we wanted to achieve and why we were doing it, but we only had a brief idea of how we would get there. Some of us have had experiences with hackathons where groups were formed spontaneously but it was obvious that when touching the day-to-day experience of pretty much every employee within the organization, we needed to be rock solid in our preparation.

As a first step, we sought to learn from others who had gone through this exercise. The blog articles from Moia, Ahmad Fahmy, and the video — How Self-Selection Lets People Excel — from Sandy Mamoli were a good start for a better understanding of the overall topic and different approaches. With that in mind, we started to draft our first agenda and defined our goals. Finally, we had the great opportunity to ask Tobias from Draeger about his experiences with such an endeavor and all the nitty-gritty details. This helped a lot because it allowed us to address the points where we had the most uncertainty. But another outcome was also that self-forming your teams will not magically solve all problems and one has to live with some level of uncertainty before, during, and after the “event”.

We started to lay out our construction plans. Besides the overall agenda, we also restructured the scope for each (newly) defined team to achieve the goal of more focused teams. This turned out to be much more difficult and time-consuming than we thought — but finally, we agreed on a structure with the Product Owners. Around the same time, we also challenged our refined ideas of product cut, agenda of the day, and any other open questions with a smaller group of developers. This proved to be especially valuable since it allowed us to find out early in the process what the greatest concerns of the developers were and what kind of wishes we should keep in mind. For example, there was the wish to announce the scopes of the new product teams beforehand and not directly on the day of the event.

Through this process, we — as the organizing team — started to realize what was at stake. That self-forming team day could be a success, but a completely chaotic outcome and disoriented teams were also possible. That uncertainty combined with the fact that we would touch the daily working life of so many people caused some sleepless nights for us. Together with the freshly adapted product scope, we now had two moving targets.

With a process like this, you need to have trust in the group because similar to a rocket launch you can set the course before the start, but once launched only limited corrections are possible and have to be executed by the crew. By combining our preparations with the trust in the people, we felt confident enough to make the launch and got ready to kick off the actual “self-forming team” day.

The spaceship launch — the actual event

Although mainly centered around self-forming product development teams, we had also invited our sales, marketing, and business development colleagues to the event, as it was also crucial for them to know what was going on, how the new product dev cosmos would look like, and to eventually join the spaceship crews.

The event itself took place remotely (due to Corona) and was scheduled for a whole day. In terms of tools, we were meeting in MS Teams for joint parts, working on a Miro whiteboard (including impulses and elements from Miroverse templates like this Multiverse Toolkit by Tini Studio), and spreading out to wonder for interactive discussions in smaller, self-forming groups.

And in addition to our conscious preparations and communication previous to the event, the participants also had been assigned a little bit of “homework“ beforehand:

• All participants completed a little “avatar card” in Miro with their name, role, pic (if wanted), some fun facts, and “things I would like to do more /learn”. The latter was especially important to us, as we knew what our peeps could do well, but we strove to make also the perhaps unknown development areas transparent.
• Our Product Owners prepared some product cards in Miro, listing the product(s) they were owning with information like maturity level, features, size, (assumed) priority, and skills required.

The agenda and approach for the actual day looked as follows:

What did we give in as constraints? On purpose, we did not give too many constraints.

The key element of the event were the self-forming iterations. Each iteration consisted of:

• 15min time where everyone could stroll around in the prepared wonder space and get on a chosen topic(s) (aka wonder areas). This was mirrored by moving one’s avatar in Miro at the same time or latest at the end of each iteration.
• At the end of each iteration, those groups noted down what was already cool and what they still missed.
• We then came back to MS Teams for a 10min review altogether, in which each potential team pitched their current setup in 1 minute and got the chance for questions, feedback, and sharing open challenges & needs.

We went through three iterations with the people present, adding in the 3rd iteration the chance to also take into account the freelancers as well as new hires that were about to start. After those three iterations, the new self-formed product dev cosmos already looked very promising — although of course not every open question had been answered yet.

Our biggest open end at that point was one lonely satellite — a very mature and important product of ours, however not attractive enough that a proper team was self-formed around it. This posed quite a navigation conflict, as we did not want to force anyone on it but needed a solution. After our 3rd iteration and with all other products taken care of, we took some extra time with the whole group to understand the issues and needs here better and to discuss solutions that ranged from splitting it into smaller pieces to having it rotate through the teams. Although a bit frustrating, we did not make a decision straight away but took this new insight with us. Spoiler alarm: In the follow-ups on this topic together with the respective Product Owner, we managed to build a rocket pod that is in the air and flying — however, we are all aware that the duck tape should be restored by some fitting shell in the future.

Still, we felt ready enough to be proud of what we had achieved together as a group, and to continue our journey in a new shiny space shuttle together!

Of all the things we had thought about when preparing for the spaceship launch event, the following proved especially valuable throughout the day:

• The prepared “avatar cards” had stirred some self-reflection beforehand
• The short cycles of the iterations
• Giving trust to the group — plus a space for the facilitating team where we could share our insecurities and calm each other down
• Maintaining a “parking lot” area in Miro plus a place for gathering feedback
• Time for pausing, reflecting, and committing together throughout the event
• And we made sure that this had the nature of a joint experiment, allowing adjustments and learnings along the way.

Now that our ship had managed to start and was in the air, we knew we had to follow up quickly with the next steps to keep it flying. So shortly after the actual event, we came back together for naming the new teams and setting team goals for the upcoming quarter. We also agreed on a joint transition moment and arranged knowledge sharing as well as handovers. Unexpectedly, the moment to transition into the new teams was found almost naturally and set to one month after our launch event.

What occupied us more — in addition to our duck-taped rocket pod mentioned above — were organizational issues, such as rearranging our communication channels, allocating joint resources like our agile coaches to now more teams, and establishing new working modes partly also switching between Scrum and Kanban.

During and after these ignition efforts, we kept collecting feedback on how the journey was turning out.

Looking back at the earth and heading to Mars — our learnings

Mission accomplished? As the teams started working in their new setup, the biggest question for us was: Would we do it again? And if yes when?

What worked great was that everyone got the opportunity to re-think his/her current team and product setup. This led to some people staying with their existing team and others making use of the opportunity to jump into a new context — and both were happy with being able to make that choice.

Happy our team is still the same — Person A

Dynamic, new team members, new tasks, change — Person B

Having the possibility for such a process and exercise was perceived positively. While people also saw problems, it caused a very positive dynamic around the topic of “team changes” and took away the aura of mystery that usually goes along with it.

felt super good to be involved in the process rather than “being handed” a new team structure

It felt empowering to contribute to the changes that were made. No decision was handed down on how the new structure would look but it was created by everyone concerned. Big appreciation for that.

One other outcome was that a different process does not solve all problems of an organization. But just like working in an agile manner, it makes problems more visible — which can help to fix them. In our case, for example, the problem that we were working on too many topics became much more transparent with the smaller teams since the number of teams just exploded with the new setup.

Quite a lot of topics — are we (as a company) focussed enough?

do we have too many teams?

The biggest problem, however, were our “unpopular” products. We had one team that contained products that were not as “sexy” as the rest for most developers. Since we did not force anyone into that team anymore, we ended up with a situation where we did not have enough developers for that topic — despite the importance of the topic for our organization. On the upside, this problem was now also seen by more people:

I am not happy with the solution, maybe we need more guidance here because these two products are so important to us.

shortcomings were made visible

This leads to a bigger feedback item around the preconditions we should give to such a process. We kept the process very open without providing concrete business priority, team sizes, or anything in that direction. This is probably something we would change for the next iteration, as there was also quite some feedback that asked for more guidance.

unsure if results take obligations into account enough

I missed a weighting of the topics.

Weighting the topics and accordingly adjusting the team size.

Still allow self-selection, but maybe say:
5 Devs needed in Team A, 3 Devs needed in Team B, …

Looking at our two main goals:

• Give the opportunity for each team and person to find his/her favorite team/product
• Establish teams with more focus

and the feedback we received we concluded that we definitely want to do this again. Of course “inspect & adapt” is part of our DNA and we will try to implement our two main learnings:

• Give more guidance for the process, especially around business priorities and team sizes
• Ensure that “unloved” products are not left alone

With these changes in mind and motivated by the feedback, we scheduled our next self-forming team day after six months — allowing continuity but still providing the opportunity for change if desired.

The biggest learning is that with a self-forming team approach, you will not be able to predict the outcome and a certain level of uncertainty has to be accepted. But comparable to agile development, the trust in people will be rewarded if you empower them:

Amazing how we as a group solved almost everything

And with such a crew on board, we are looking forward to our next rocket launch!