Experiences with solving strong inter-team dependencies

Henning van Ackeren, Friedemann Schautz Ableton AG

Since 1999 we make Ableton Live, today we make Live, Push and Link.

!

Let’s have a brief look at Ableton Live from the user’s perspective…

… and from the inside• The software represents a ‘song’.

• The Data Model is essentially a large tree.

• UI is mostly about directly manipulating this tree.

• The ‘Audio Engine’ is a different ‘view’ on this tree.

• Push is yet another view/controller on it.

• Features sometimes cut through all layers, but not always.

The challenge …• We want fast, iterative feature development in this

rather monolithic environment.

• We want independent feature teams.

• We want consistency, too.

• We want elegant workflows across (UI) components.

• In addition, there’s of course quite some legacy (good, bad, sometimes ugly)

How we deal with (technical) debt

• Continuous refactoring to re-thinking and re-doing complete parts.

• Example for the latter: Data Model renewal.

What’s so complicated about renewing the data model?

• develop it while using it

• development across several teams

• local versus global aspects, i.e. components and the whole tree often have different requirements

Our takes on it

• Take 1: Start local, then consolidate,

• Take 2: Have an experts team coordinating the effort,

• Take 3: Do the design upfront.

• Take 4: do all of this together :)

More challenges• different development speed of teams

• some changes have to made with all teams at once

• different visions, ideas

• transparency what the ‘expert group’ does

• feeling of ‘everything depends on everything’

• many technical details that pertain to the wholeneed solutions

• little experience with ‘upfront design’

Main learnings• don’t get obsessed with a particular approach

• be very clear about the current approach

• don’t be afraid of upfront design

• grow the experts group in time or it really becomes the bottleneck

• stay true to (agile) principles but be pragmatic too, and question your approach constantly

• avoid the terms ‘architecture’ and ‘architect’

Main learnings• We found Conway’s law to be true: Systems mirror the

organisation that has built them,

• It’s easy to forget being agile when it comes to organisational development,don’t over-engineer the team setup and roles.

• for both, organisational setup and software architecture the devil is in the details

• It’s not about abstract vs. concrete; it’s about what aspects are harder to change

• You can also build silos on the basis of cross-functional teams.

There’s much more we learnt, let us hear your questions …