Presented by Friedemann Schautz from Ableton AG at agile42 Connect conference in Berlin, November 2015 – After a brief introduction to the company and its products, we’ll present an ongoing challenge: a new backend is being developed based on new technology - at the same time several clients are developed from scratch in several teams. This often leads to changing and conflicting requirements towards the backend. We went for a team setup with one backend team and several client teams, instead of having truly cross-functional teams with a backend developer in each client team. In our presentation we’ll focus on the pro’s and con’s of our approach and the solutions the teams found to manage the dependencies and differing opinions and requirements regarding backend functionality. We won’t present a perfect solution but would rather like to engage in a discussion and share experiences.

1. Experiences with solving
strong inter-team
dependencies
Henning van Ackeren, Friedemann Schautz
Ableton AG

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

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

8. … 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.

9. 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)

10. How we deal with (technical)
debt
• Continuous refactoring to re-thinking and re-
doing complete parts.
• Example for the latter: Data Model renewal.

11. 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

12. 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 :)

13. 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 whole
need solutions
• little experience with ‘upfront design’

14. 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’

15. 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.

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