Team topologies: Nov 22: Chapter 6

[elle]

Book: Team Topologies: Organizing business and technology teams for fast flow by Matthew Skelton and Manuel Pais. Link: https://teamtopologies.com/

Aiming to read:

Chapter 6: Choose team-first boundaries

MC: @elle Notes: @kunzmann

See you all at 12pm AEST, November 22nd @ https://blackmill.co/meet

As always, if you'd like a calendar invite and/or access to Slack beforehand, get in touch via gday@blackmill.co.

[elle]

6: Choose team-first boundaries

Key takeaways

• Choose software boundaries using a team-first approach.
• Beware of hidden monoliths and coupling in the software-delivery chain.
• Use software boundaries defined by business-domain bounded contexts.
• Consider alternative software boundaries when necessary and suitable.

--

• Fast flow of change requires removing hands-off and aligning teams to main streams of change
• Single team with defined boundaries -> ownership
• How to define boundaries? using domain-driven design and fracture planes
• Monoliths are high-coupled. By definition highly coupled software architecture are monoliths.
• Tightly-coupled monoliths make it difficult to define clear boundaries of responsibilities
• We can also have distributed monoliths
• Objective: service independence

Types of monoliths (hidden monoliths and coupling)

• Application monolith
• Joined at the database monolith
• Monolithic builds
• Monolithic (coupled) releases
• Monolithic model (single view of the world)
• Monolithic thinking (standartisation)
• Monolithic workplace (open plan office)

"One size fits all" and too much standardisation -> removing freedom to choose tech stacks, enforcing a single tech stack or tooling -> reducing motivation, experimentation and innovation -> leading to poorer choices

Software boundaries or "fracture planes"

A fracture plane is a natural seam in the software system that allows the system to be split easily into two or more parts.

• Business domain bounded context - DDD

In summary, the business domain fracture plane aligns technology with business and reduces mismatches in terminology and “lost in translation” issues, improving the flow of changes and reducing rework.

• Regulatory compliance - for example PCI
• Change cadence - change in different prequencies
• Team location - makes it hard to ship software quickly
• Risk - once again loosely coupled systems decrease risk of deploying small changes frequently
• Performance isolation - for example yearly activities such as tax returns
• Technology - back/front-end, integrating with older technologies, web/mobile
• User personas

Natural fracture planes for your specific organisation or technologies

Mobile / cloud/web / IoT

Summary

When optimizing for flow, stream-aligned teams should be responsible for a single domain. This is a challenge when domains are hidden in monolithic systems that include many different responsibilities and are mostly driven by technology choices, providing functionalities across multiple areas of business.

• Need to look for natural ways to break down the system -> to make the individual parts evolve as independently as possible -> autonomy and ownership
• Main aim is to find software fracture planes that align to business domain bounded contexts - because it will map to streams of change that are natural for the organisation -> result is business domain boundaries will match teams boundaries

[kunzmann]

Discussion notes

SRE according to google - software developers running ops.

More nuanced - based on people who have interviewed at Google - might get into low level stuff (e.g. how does the linux kernel work)

Team topologies might have a different definition to Google.

Lots of examples of how to think about breaking up teams in this chapter

17 devs - 17 microservices - how many services becomes too much vs team size?

microservices can introduce a lot of toil

Reusable service objects ftw - not the 'Rails way'

There is no fracture planes in a module based code structure - a composition based system is easier to separate.

Marketing has different goals to engineers - maybe it makes sense to be quite separate. But there can be blurred boundaries when you get into the actual implementation. Where is the fracture plane?

Analytics platform layer can connect dots.

Account based marketing - customised pitches - building things for that kind of customisation might require a lot of changes.

DDD handles that - marketing personalisation is a domain - it might take input from other domains

Can still be hard to capture edge cases.

Monolithic thinking and standardisation - makes some big leaps in logic about why it is bad. There were a few examples like that in the arguments against monolithic things.

Starting with the tech stack question for every new project can be a big waste of time.

"Too much" freedom

The level you choose to constrain choices & what you are constraining can make a big difference depending on context - small team choosing new tech stack all the time is

Decide what you are optimising for before standardising.

Team topologies fans == microservices / DDD fans.

We don't need to agree with everything in the book, but it is a struggle to see what context they are writing from. Hard to answer: Why do they hate monoliths?

Splitting on performance fracture plane - might be odd to split a team off purely because of a performance characteristic. Can make sense if there is also a persona difference.

Do you have a permanent 'Black Friday' team? Most places set up temp teams - 6 months.

We have a lot of examples collectively of different company contexts - Black Friday team at Shopify might make sense to be a permanent team. We point out exceptions, but there may be rules that can apply to almost everybody.

Overall, this is a great chapter.

Value stream that has backend / web / android / ios - web & backend continuous delivery. Mobile apps release less frequently. Difficult to solve the urge for cramming in when releases are less frequent. But releases to mobile need to be high quality - a tension.

There can be a higher QA expectation for mobile app releases, which affects cadence (slows it down).

Time to recovery is a big consideration when shaping teams and processes.

Similar to performance fracture plane in that it is a limitation not necessarily based on anything to do with a business domain.

Agree with the chapter summary. The problems we often have with reorgs is people haven't spent enough time answering the question of 'why' for a change. Wait for pain points before deciding on what to change. Similar to refactoring code - wait for the pattern to come up three times before you make the change.

Is one of the reason reorgs are doomed to fail because nobody talks about them before they land?