Our web development department needed to be reorganised and we wanted to try a new approach for this: self-organising teams work great, why not gather everyone and try to self-organise the whole department?

Our Situation

We had four web teams in Stockholm and two teams off-shore. The off-shore business needed to be decreased and this meant taking on the ownership of more software.  We also had a wide mix of technologies and a growing technical debt that seemed hard to deal with. Some products were the result of a group investment and not fit for us. Furthermore, business-critical legacy systems kept taking too much time to maintain. On top of this we needed to recruit new colleagues and wanted a clearer structure when onboarding them.

These were our main drivers:

• Teams having too wide an area of responsibility causing difficulty to focus
• Growing technical debt
• Too complex technical architecture
• Products developed off-shore needed to be handed over

Our Approach

We gathered a full day outside the office to work out a new organisation. This was done in smaller, well-mixed groups. Each group would get:

• a set of yellow post-its with all our systems/products/services (around 35)
• a set of green post-its with names of all co-workers (around 30)
• a set of big, blank post-its for team definitions

The exercise was to define new teams in a way that would attack our problems and result in both better/faster development and a better work environment.

New Organisation

It turned out to be fairly easy for the groups to define new team constellations and distribute the services and products two these new teams.  The next step was to distribute all the people to the different teams.  Putting your own name was pretty easy, while assigning everybody else turned out to be a bit more challenging.

We then went through and discussed the different proposals and came up with one “winner”. Everyone then got the chance to move their name to another team if they weren’t satisfied with their placement.

Result and Interesting Observations

We ended up with six teams in Stockholm plus one remaining team off-shore. Teams would own a part of the “customer journey” meaning most teams ended up having a mix of new and legacy systems. This we believed would make it easier to focus on reducing technical debt.

An example: we had three different, active CMS platforms handled by two different teams with different technology stacks and separate product owners. This shared lack of ownership led to low motivation in removing any legacy system.

In general we stuck to the organisation that was agreed that day. One interesting observation was that a team responsible for a legacy Java product attracted only .net developers: “it’s only technology”. The domain and the ideas for future development were more important.

Learnings

Overall, this experiment to self-organise an entire department was a great approach. I learned that the same principles that encourage teams to self-organise also apply in this situation.

Even if we’re part of a large enterprise, there are lots of possibilities to change how things are done.

Operation Review Two Months Later

Two months have gone by and now we gathered again for a joint operations review. Looking at the drivers we had, this is the outcome so far:

• Teams having too wide an area of responsibility causing difficulty to focus: focus has improved a lot for all teams but is still a concern
• Growing technical debt: as a result of better focus we have been able to reduce technical debt at a higher pace
• Too complex technical architecture: done for some areas and started for some
• Products developed off-shore needed to be handed over: some of the new teams decided to develop completely new products based on another technology so the handover was eliminated

Apart from these, our main discussions have been around alignment and sharing between teams. We want strong autonomous teams who own their technology, their way of working, and their legacy. But at the same time we understand that we need to part of bigger system: engaging, sharing, and helping each other every day.

“Teams with a shared product vision need separate team missions. Boundaries between teams promotes focus, not silos” – Diana Larsen

Where does a PMO fit in all of this?

The focus on services, products, and teams partly collides with the project work form. We have chosen to deal with the collision like this: epics from projects go into the respective product roadmaps. From there the product owner and the team treat them like any other epic. Controllers help divide cost in the best suited way (investment/operations).