|Simulated Annealing for a Travelling Salesman|
We've all seen it. The larger a game team, the more dependencies between developers and teams emerge to slow development down to a crawl.
The problem of dependencies is a complex one. They are called NP-complete" problems, usually only solved by time-consuming brute force approaches. So forget about an easily managed solution.
The best approach has its analogy in computer science called "simulated annealing," a technique where you start with an approximate solution and add a bit of change from time to time and see if it improves the solution. The GiF above shows simulated annealing as applied to the classic Travelling Salesman Problem. Instead of thinking of cities (groups of dots), and paths between (lines), think of developers(dots), teams(groups) and dependencies (lines). Over time, as teams and individuals within teams experiment with ways to reduce dependencies, you see those inter-team dependencies reduce.
For large teams, those changes are often to team makeup and the formation of the Product Backlog. The goal isn't to eliminate inter-team dependencies, but to move as many as you can within the individual cross-functional teams (Scrum-sized, 5-9 developers). Within those teams, they build accountability and better practices to address debt and reduce the cost of dependencies.
By experimenting with more self-contained teams and organizing the Product Backlog to reflect those teams and to depend on fewer "future integrations" and build development practices, dependencies will slowly diminish over time.
Practices to Try
- Instead of creating a detailed release plan every few months, just define the major epics and let teams reform around the epics they'll take on and refine the release plan themselves.
- Identify dependent specialties in the release plan between each team instead of tasking out dependencies. Often this indicates where you don't have enough specialists or where there is an opportunity to cross-train someone and spread some skill.
- Talk about them in retrospectives. Encourage the team to come up with solutions.
- Measure inter-team dependencies. If you don't measure it, it's harder to improve it.
- Find ways to visualize dependencies. Program boards that use strings to identify inter-team dependencies are useful. A board that looks like the one below should horrify anyone.
This is not a good "after" shot IMO