Identification of Team Boundaries

Michael Plöd

Dieser Artikel ist auch auf Deutsch verfügbar

First, we will take a brief look at the key characteristics of an autonomous, cross-functional team. Then, in the main section, we will look at various techniques that can be applied to explore the boundaries of these teams. This includes: Fracture planes from team topologies, domain-driven design, and independent service heuristics.

What are autonomous, cross-functional teams

In today’s dynamic business world, autonomous, cross-functional teams have become a key tool for business success. These teams are distinguished by a variety of features that make them an effective and flexible unit.

Diverse skills and expertise: A cross-functional team is made up of members with different skills and expertise. This makes it possible to integrate different perspectives and concepts, which leads to more creative and comprehensive solutions.

Self-governance and autonomy: Autonomous teams have the power to make decisions at an operational level. They are able to set goals, prioritize, and plan workflows without constant external guidance. This leads to faster turnaround times and more agile work methods.

Quick adaptability to change: Due to their flexibility and decision-making power, autonomous teams are better at adapting to changing circumstances. They can quickly set new priorities and reallocate resources to meet new requirements.

Continuous willingness to learn: Autonomous teams are eager to evolve and improve. They are open to feedback and frequently take advantage of training opportunities to enhance their skills.

In addition to these characteristics, it is important to establish the link to stream-aligned teams from the Team Topologies concept. Stream-aligned teams are specialized in serving specific business streams. They act as enablers for fast and efficient development of microservices architectures.

The close linking of autonomous, cross-functional teams and stream-aligned teams in microservices architectures (for example) facilitates optimized utilization of the benefits of both concepts. Cross-functional teams have the diversity of skills and autonomy that are crucial for the development and maintenance of microservices. Stream-aligned teams ensure that the developed services are seamlessly integrated into the business processes.

Overall, autonomous, cross-functional stream-aligned teams are the key to boosting a company’s innovative resourcefulness and competitive edge in the era of modern software architectures. By combining diversified skills, self-governance, and clear communication structures, they create an agile work environment that can adapt quickly to changes and thus ensure long-term success.

Identification of team boundaries

The core characteristics of these teams and their benefits are usually easy to figure out. However, it is far more difficult to find suitable boundaries within which teams can: • make the majority of their design decisions without having to coordinate with other teams • learn and master the professional and technical complexity of their scope of responsibility • deliver high quality software • have the freedom to explore and test new topics

In the meantime, various concepts and techniques have been established for this purpose, which can also be combined with each other: • Fracture planes from Team Topologies • Bounded contexts from domain-driven design • Independent service heuristics

These techniques are presented below.

Team Topologies fracture planes

The book “Team Topologies” by Matthew Skelton and Manuel Pais, which has also been available in German since the end of 2023, gave rise to the idea of stream-aligned teams. In addition to introducing four fundamental team types and three basic modes of interaction between teams, the book also provides an approach for intersecting team boundaries: Fracture planes.

Fracture planes are various drivers for the intersection of teams. Team Topologies defines fracture planes as follows:

Team Topologies explicitly stipulates a combination of fracture planes and encourages observing the section of a team from the perspective of different fracture planes. In the following list of fracture planes, a connection to the second concept of this article is already apparent:

• Bounded contexts, based on domains
• Performance isolation
• User personas
• Change cadence
• Regulatory compliance
• Team location
• Risk
• Technology

Domain-driven design bounded contexts

Bounded contexts are a key element of strategic domain-driven design. The idea was described in 2003 by Eric Evans in his book “Domain-Driven Design – Tackling Complexity in Software”. A bounded context can be understood as a boundary around a (technical) model that is expressed in a consistent language and tailored to a specific purpose. Therefore, it is a modularization strategy for complex software systems that breaks with traditional, reuse-based system design at a crucial point: The focus for modelling bounded contexts is on specializing models that are intended to represent a specific thing (the purpose) in the best possible way. If this model can then be reused, nobody in the DDD community would have anything against it. But it would also be justifiable without restrictions if the model were not reusable. Bounded contexts are the preferred way of identifying boundaries for teams in the team topology environment. It is advisable to start with bounded contexts and then use the other fracture planes to refine the boundaries.

The procedures for the design of bounded contexts are generally intertwined and are usually applied together. Heuristics from the following methods/ideas are very common:

• Big picture event storming
• Bounded Context Design Canvas
• Ubiquitous language

Big picture event storming is a method of collaborative modeling that was invented by Alberto Brandolini and described in a book. The workshop method is about exploring a domain with the help of domain-specific events. These events are called “domain events” and are recorded on orange sticky notes. A domain event always contains a verb in the past tense. These events are compiled on a wall and then sorted. In the end, so-called “pivotal events” and swimlanes are identified. Pivotal events are particularly notable events that are important and represent changes. For example, in construction financing for private customers, “application submitted” or “loan decision approved” would be candidates for pivotal events. They are typically marked by vertical lines, usually with artist tape. Swimlanes, on the other hand, are areas with which parallel processes or branches are marked. After identifying pivotal events and swimlanes, the modeling area should look something like this:

Based on this model, you can now work with two questions and heuristics:

• A pivotal event lies at the boundary of a bounded context (or a subdomain)
• Swimlanes can be drivers for splitting bounded context candidates

For the next step, you should ask yourself which of the previously marked areas belong together. Which areas belong together can be determined by considering linguistic facets or by looking at technical rules. With regard to the linguistic facets, it is about terminology and the meaning of terms. We should ask ourselves whether a word has the same or a different meaning in areas A and B. The same applies to abbreviations. In banking, for example, there is the term FX. This term can refer to foreign exchange trading (i.e. trading in currencies) or fixed interest rates. To avoid ambiguity in this case, it is probably better to separate these departments.

Furthermore, swimlanes often do not fulfill a technical purpose conducive to the domain or they play a rather subordinate role. In this case, it is advisable to search the event storming board for other events that depend on such a swimlane but represent the actual purpose. Each bounded context should have a clearly identifiable technical purpose.

The “Bounded Context Design Canvas” invented by Nick Tune and now updated by the DDD crew on GitHub under a Creative Commons license is a good tool to overcome the issues surrounding the design of bounded contexts. The canvas looks like this:

This technique ensures that you have all relevant questions on your screen at all times during the bounded context design. Furthermore, a fully completed canvas is very good documentation.

As mentioned above, bounded contexts are the favorite fracture plane for designing team boundaries. However, you should not stop here. Check the current design against the other fracture planes and make adjustments, if necessary.

The other fracture planes

Another interesting fracture plane in the Team Topologies book is called Performance Isolation. The objective here is to identify whether there are areas in the overall system that have special requirements for runtime performance and scalability. However, I recommend interpreting this fracture plane holistically and expanding the focus to include quality requirements. In addition to runtime performance and scalability, the analysis also includes topics like availability, UX, or security. For example, a form for recording loans must be available 24/7, while processes in the back office usually only need to be available during normal business hours on work days (12/5).

The User Personas fracture plane can provide valuable insights, particularly with regard to UX and availability. Different user groups have different needs when it comes to the usability of a system. For example, experts prefer to work with more complex screens that they operate with keyboard shortcuts, while inexperienced users favor simple wizards that navigate them through an application. Therefore, it makes sense to split off subsystems for specific user personas in situations like these.

Another perspective for refining the team interface can be the change cadence. Every larger system will have sub-areas that change frequently and others that rarely or never need to be adapted. A separation may seem sensible in these cases too. However, it is advisable to expand this fracture plane to include a consideration of the release speed. How quickly and in which production areas must new requirements be delivered?

The risk fracture plane addresses the hypothesis that there are different areas with divergent risks within a complex system. The risk relates to facets such as probability of default, risk of change, number of users, or the influence of a sub-area on the conclusion of transactions.

Regulatory compliance represents a particular risk, which is why it was identified as a separate fracture plane in Team Topologies. This fracture plane is of particular interest in highly regulated industries such as banking or insurance. Regulators require companies to have mechanisms in place for auditing, documenting, testing, and delivering software that falls within the scope of these regulations, be it for credit card payments, transaction reporting, or closing deals. Conversely, regulatory compliance should not be applied to parts of the system that are not as critical. Splitting off sub-areas within a monolith that fall within the scope of regulations is a suitable fracture plane.

The physical location of the team members also represents a fracture plane. Teams that are geographically dispersed and work in different time zones are obviously not in the same location. However, teams whose members work on different floors or in different rooms in the same office building can also be considered geographically separated. If it is not possible for a team to either work completely remotely or in a shared location, it can be useful to divide the system so that the teams have clearly assigned locations.

The last, and in my opinion most critical, fracture plane is technology. With this option, teams and sub-areas of a system are split into groups based on the applied technologies and corresponding skills. However, I strongly advise only using this fracture plane in very justified exceptional cases, as a division by technology cannot achieve true end-to-end functional responsibility.

Independent Service Heuristics

When we design organizations for fast workflow, we need to find effective boundaries between the different streams. Techniques such as domain-driven design (DDD) are very powerful for this task, but can be quite complex and difficult to learn. A simple intermediate approach is the question: “Could this thing be run as a cloud-hosted (SaaS) service or product?

Independent Service Heuristics (ISH for short) cover many typical situations in modern software, but not all. It is intended to stimulate conversation and provide a framework for thinking, but it should not be considered a magic bullet.

You can use Independent Service Heuristics by taking your findings from the previous steps and collaboratively answering the following questions as a team with yes, no, or maybe:

Sense check: Would it make logical sense to offer this object “as a service”?

Brand: Could you imagine marketing this object as a public cloud service (like MopsBankRetailBaufi.com)?

Revenue/customers: Could this object be managed as a profitable cloud service in terms of revenue and customers?

Cost tracking: Could the company currently track costs and investments in this object separately from similar objects?

Data: Is it possible to clearly define the input data (from other sources) that this object requires?

User personas: Could this object have a small/well-defined group of user types or customers (user personas)?

Teams: Could a team or set of teams effectively build and run a service based on this object?

Dependencies: Would this team be able to operate independently of other teams most of the time to accomplish its goals?

Impact/value creation: Would the scope of this task be an impactful and interesting challenge for a team?

Product decisions: Would the team working on this object be able to determine its own product roadmap and product direction?

It is highly recommended that each person in an ISH workshop answers these questions for themselves. Unequivocal agreement will only rarely happen. Instead, experience has shown that a tendency is more likely to emerge. Here is an anonymized picture of the application of Independent Service Heuristics from a workshop: