Teams and Requirements

Forming teams

Software development teams often deal with an overhead of communication, conflict of interests, shared codebases, shared production releases, etc. It is easy to notice that the cost comes into the picture when one team has to share something with another. On the other extreme, an independent group has the luxury of moving as fast as they want without worrying about dependencies on outside counterparts.

How can we maximize the number of autonomous efforts in an organization that has multiple teams? As it turns out, the solution is easy to explain after having learned about context maps and bounded contexts.

The trick is to form teams around bounded contexts. Allow a group to own one (which is ideal) or more bounded contexts, but do not allow more than one group to hold ownership of any given bounded context. Help team members understand bounded contexts and subdomains that they own and with which they interact. Ensure that people integrate bounded contexts according to their connections on the context map. Otherwise, the context map needs to change to express necessary knowledge.

When teams arrange around bounded contexts, there are little or no shared resources by the design of the bounded context, which allows a great deal of autonomy and acceleration over time. There is nothing more empowering than an ability to make independent decisions and to go as fast or as slow as a group needs. There isn’t a necessity to wait for other teams or to fit into the bigger picture. This freedom results in better software systems that scale in isolation and form a sound part of an overall enterprise-wide ecosystem. Teams composed in such a way also demonstrate better scalability from a process standpoint.

You can create problems for yourself if you form groups ...