Notes from Esther's talk + Q&A on organizing teams

Three main topics:
Coordinating across teams - today
Integrating teams output
Maintaining system integrity

Why is coordinating across teams so hard?
* Dependencies lead to fits and starts

Kinds of dependencies:
* Functional dependencies (a then b then c) - story mapping helps with that.
* Technical dependencies (need multiple architectural components working) - often can handle in the backlog but are better done in vertical slices.
* Organization dependencies (different priorities, bottlenecks)

Focusing on organizational dependencies:
* Group A is doing work needed by B, in turn needed by C
* By the time C starts working, they realize that there were issues with A and B
* But they have moved on to other work
* When common infrastructure services come up, things get worse. Usually, this is because the common services team has yet other priorities, usually non-functional.
* This is because this is how work tends to be organized around specialists
* This doesn't lend itself well to knowledge work
* Teams work better: Cross-functional teams working on a compelling, meaningful (i.e. complete) goal stated from a customer perspective. With complementary skills, agreed upon process. Typically small in size, around 5. 10 or less. Have a history together. Based on people who agree that they should be a team.
* So, how do we coordinate across multiple teams?
** Build a Feature/Architecture matrix
** This will show you what kinds of features, touch which systems
** Build teams around this that have people who can build entire features across the various related components
** You still need specialists who understands systems well. The idea is that we shouldn't *all* be specialists.
* This kind of structure allow more features to be completed with less handoffs.
** Less handoffs mean lowered coordination overhead, increased ownership.
** Improves learning
* Not just developers and testers, but also ops, product

To summarize:
* Context teams over Component teams
* Find ways to learn early rather than late
* Build T-shaped people (experts in one thing, but can understand/do a variety of other things)

How would you start:
* Start with a single project
* Form a cross functional team to do it
* Show people that there's a way to make it work

How do you handle support if the split isn't component based?
* You give one of the teams that understands the component a new priority to address the bug
* Even if they didn't build the related feature, yes! (my note: collective code ownership!)

Next talk/q&a on integrating work across teams coming up July 10