most companies scale teams and “territory” (namely, codebases) in an unstructured, evolutionary, ad hoc way. i once watched a talk about scaling while staying agile, and it inspired me to illustrate this with a specific hypothetical structure.
let’s say we have an
organization which can have one or more
services and one or more
product teams (called “pods” in the aforementioned talk).
product teamsare a team of developers who all work off the same backlog, and are fungible within that backlog. processes are utilized to maintain this. for instance, whenever they’re ready for work,
product teamdevelopers take the next item in the backlog. and they’re full-stack within that
organization. whenever they work on a user story (“feature”), they directly edit any necessary code from within any of the
servicesare generally defined as running binaries/processes. every service gets its own code repository. if services need to share code, they do it via versioned packages. in principle, if two
servicesshare code module X, then X could live within the repository of either service, but it’s considered cleaner to give that shared code its own repository.
servicesonly communicate via versionable APIs. they don’t directly access databases. i.e. every non-versioned storage device is owned by exactly one
- it’s fine for a
product teamto be the only one within their
organizationthat works on a given
service, serviceX. they remain in that
organizationso long as they’re free to directly modify the code of any other
organizationwhich need to interact with serviceX. if bob works on serviceX and it requires a change to serviceY, but he’s expected to put in a request to another
product teamto make that change, then serviceX and serviceY cannot exist within the same
organization. it’s expected that services will sometimes grow in scope and complexity until such API separation is desirable, at which time they’ll be broken off into a new
there are some minor caveats, but in general i believe a coherent set of organizational principles like this can be beneficial as companies scale beyond the standard two-pizza team.
an example of a caveat
a ruby on rails application will often have jobs which are part of the same codebase as the rails web application, and therefore have the same database models and access the same database. however, they run in separate job runner processes. effectively they’re separate running instances of the same “binary” (the same codebase), but they run the jobs rather than the web server.