This is part of the Summer Of Culture blog series.
Coordinating work across teams is a real big challenge. Each product and organization is different and so have different needs in how they scale. I’ve seen a lot of companies struggle with scaling teams and being agile. Here are some problems when more than one team works on a software product:
- coordination of work tasks – teams have different goals and therefor it’s harder to plan bigger pieces of work
- dedication to a specific field – front end, database or performance teams are often not dedicated to customer benefit anymore
We know that these problems doesn’t appear when just one small team is responsible for the whole product development, but what can we do when the products and team grows? How should we scale the work efficiently?
Building teams around themes
This way teams can work autonomous giving them the freedom how to solve problems and how to work together. They are responsible to make their specific customer group happy. Not every team does daily stand ups, some do it every two days and others just meet when necessary. Teams can pick the tools that makes them most productive: Using a post-it task wall, working daily with JIRA Agile, estimating in story point, not doing estimates… it’s important that they get their tasks done, because people are different and teams are different.
Trusting the team
There is no code ownership. Spotify is calling this ‘internal open source’. Sure, some teams have written most of the code in specific packages. If another team wants to change that code we trust them, that they’re doing the right thing. Also the management need to trust the teams that they’re doing their best to make the customer awesome and that teams are able to coordinate their own tasks.
Trust & autonomy comes with a lot of responsibility for the single teams and developers. But also if you size your team around customer groups, give them trust & autonomy you’ll need some coordination of tasks: The different product manager & dev teams have to collaborate when designing a new feature, because it can have impact on other teams work or existing features. Also you can create side effects when changing code that another team have thoroughly designed.
A DOmocracy doesn’t work without transparency. We use code reviews where we invite original code creators & contributors to review the changed code (we actually have written an add-on for identifying theses persons). We use our collaboration platform Confluence to share & discuss new features we’re currently planning or developing. We gather feedback from everyone in the company, sometimes a designer has a better idea how to solve a problem, legal has some input for a disclaimer dialog or the support raises a few issues. Transparency gives us feedback for requirements, feature design or coding standards from the whole organization and it is essential for a DOmocracy.