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
I know that a lot of companies often build teams around technologies like databases or JavaScript or it was accidentally and nobody gave it a thought. That doesn’t scale. Teams should be build around groups of users like ‘Beginner’, ‘Large Customers’ or around themes in your software like ‘Search’ or ‘Mobile’ (like Spotify does it). We at Atlassian like the dedication of one team to a specific customer group. Each team have this target customer in mind and are directly connected to the value they’re creating. E.g. we have a team for Confluence that is building features for software development teams: Better integration between our bug tracker JIRA and Confluence, creating retrospectives or doing roadmap planning within Confluence. This requires cross functional teams with designers, web & enterprise developers, or preferable people in one team with multiple talents (e.g we encourage coders to train their designer muscles).
Team autonomy
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.
Transparency
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.
Picture Credit: Billy Metcalf Photography via Compfight cc
Sven Peters 