key to efficiency

In today’s world, the speed at which new functionality is delivered is a defining criterion for the success of IT teams. As a rule, the main negative factors here are the lack of resources (time, people) and excessive communication for coordination. Today I want to talk about a progressive approach to organizing teams, designed to speed up the delivery of new functionality.

Ideally, teams should be organized around cross-cutting functional tasks. This approach is designed to reduce the time spent on coordination. Teams organized in this way are called streaming.

A flow team is a team focused on a single, meaningful flow of work. The team is empowered to create and deliver customer or user value as quickly, securely, and independently as possible without requiring other teams to outsource some of the work to be done.. (Skelton M., Pais M. Team Topologies. — IT Revolution, 2019)

Traditional approach

The traditional approach to organizational structures involves grouping people with similar skills into one team. Such a team is easier to control. But with cross-team interaction, fragmentation arises, caused both by a mismatch of priorities within each team, and by difficulties in communication around the subject area of ​​jointly solved tasks.

The artificial division into specialization teams also deprives other developers of the opportunity to acquire in-demand skills. For example, you have a separate database team (let’s call it “DB team” for short) that is responsible for making any changes to the databases. On paper, everything looks great – responsibility is distributed. But over time, you begin to notice that developers begin to understand how databases work less and create software that works inefficiently with them. The database team, in turn, in order to relieve itself of responsibility for developers’ mistakes, as well as protect itself from inaccurately formulated requests, creates more and more regulations and administrative barriers that complicate cross-team interaction.

Rejection of the traditional approach

The reverse situation, when you eliminate the distinction of specialization, will not affect the ability of specialists to do their job. On the contrary, it will increase the bandwidth that specialists can use to solve complex problems that really require their attention. In the example above, most of the database work required to implement the designated functionality will be outsourced to the development team. The DB team will be unloaded from the daily routine. In turn, the development team will not stand idle waiting for the solution of blocking tasks on the database side, and will also learn to better understand the structure of the database and start writing more efficient software. Among other things, you will get rid of the eternal shifting of responsibility and the need to constantly synchronize the work of different teams.

Building Stream Commands

The benefits of streaming commands bundled around end-to-end functionality are compelling. How to effectively organize the work of flow teams and what problems will arise in the process? Ideally, specialists with the required competencies should be combined into a separate team. However, sometimes there may not be enough work to justify their continued presence on a particular team. In this case, specialists may well divide their working time between several teams.

The second problem often cited as the reason for the creation of specialized teams is to ensure consistency. By having a separate team responsible for its own stack, we will have guarantees that the implementations will look the same. A good example here is the user interface. In the case of separation into streaming commands, there may be a mismatch in uniformity from the design of the components to the technologies used.

The answer to the inconsistency may be the creation of support teams. Support teams – these are specialized (as a rule, on technological stacks) teams whose task is to help stream teams in their work in order to increase their self-sufficiency. Also, the support team must ensure the consistency of streaming with each other. In addition to communicating for learning purposes, the support team can create common resources that standardize the work of streaming teams across different technology stacks.

Flow teams should be self-contained, product-focused groups. The speed with which new functionality is delivered on these teams eliminates some level of inconsistency that you have to put up with. Ensuring the autonomy of flow commands is determined by the weak level of coupling with other commands.

Loosely coupled commands

The common characteristics of autonomous, loosely coupled commands, according to the authors of the book “Accelerate!”, are the possibilities:

• Make large-scale changes to your system design without the permission of anyone outside the team;

• Make large-scale changes to your system design without relying on other teams to make changes to their systems, and without creating a significant front of work for others;

• Complete their work without communicating or coordinating their actions with people who are not part of their team;

• Deploy and release your product or service on demand, regardless of other services it interacts with;

• Conduct most of your testing as needed without asking for an integrated test framework;

• Run deployments during regular business hours with minimal downtime.

A stream command must conform to this list of characteristics of loosely coupled commands. Use this list to make sure you’re on the right track.

For streaming teams to take full responsibility for their systems, centralized control must be abandoned. Including, in terms of the choice of architectural solutions. In essence, achieving loosely coupled organizational structures requires decentralization of command and control.

There are many changes to consider on the way to building streaming teams. I will highlight the following points:

• Relationship between organization and architecture;

• Team sizes;

• Types of ownership models;

• The role of the platform;

Relationship between organization and architecture

There is an empirical law that quite accurately reflects the relationship between the organizational structure and the architecture of software solutions – Conway’s law.

Any organization developing a system will inevitably create a project whose structure is a copy of the communication structure of the organization.

Conway’s law shows us that a loosely coupled organizational structure leads to a loosely coupled architecture (and vice versa). This reinforces the idea that it is problematic to reap the benefits of a loosely coupled microservice architecture without considering the company’s organizational structure.

Team Size

Small teams work faster than big ones. This statement has led to the emergence of the term teams for two pizzas. Its essence lies in the fact that the maximum size of the team should be such that it can be fed with two pizzas. This is not a very useful unit of measurement, but the point is that the optimal maximum team size is 8 people. This team should be customer focused and own the entire lifecycle of their services. A scientific study has been carried outRodriguez D., Sicilia MA, Garcia E., Harrison R. Empirical Findings on Team Size and Productivity in Software Development), the results of which showed that labor productivity has the worst indicators for teams with 9 or more people. Think Like an Amazon has a great quote from John Rossman about two pizza teams:

“Team for two pizzas” is autonomous. Interaction with other commands is limited, and when it occurs, it is well documented and interfaces are well defined. It owns and is responsible for all aspects of its systems. One of the main goals was to reduce the overhead of communications in organizations, including the number of meetings, focal points, planning, testing or releases. More independent teams work faster.

Ownership Model Types

There are two main models of code ownership – strong and collective ownership.

• Strong hold
  The team owns the microservice and decides when and what changes to make to it. If a third-party team wants to make changes to this microservice, they need to send a change request to the owning team. A team can own more than one microservice.

• Collective ownership
  Any team can change any microservice. Careful coordination is necessary so as not to interfere with other teams.

With strong ownership, the team itself makes decisions about standards and applied technologies. This ownership model increases team autonomy. The stronger the ownership model a team can adopt, the less coordination is required, and therefore the more productive the team can be.

In a shared ownership model, changes to a service are made by multiple teams. One of the main advantages of collective ownership is the ability to move people where needed. This can be useful if the bottleneck in the rate of delivery of functionality is due to a lack of people. As a disadvantage, it is worth highlighting a higher degree of consistency. Unification of technologies and deployment models will be required. Ultimately, to achieve efficiency with collective ownership, you need to make sure that working with one microservice is practically no different from working with any other. All of this undermines one of the key benefits of microservices.

Platform Role

In addition to the general concept of support teams, flow teams will need a set of self-service tools to enable them to do their job – these are platform.

The platform should implement common functions, such as the ability to manage the state of microservices (using Kubernetes as an example), log aggregation, authorization and authentication, etc. In fact, the platform should provide teams with more bandwidth so they can focus on delivering functionality to the user.

The platform also needs a team to manage its lifecycle. The platform team must find out what difficulties its users (stream team programmers) face and find solutions.

Conclusion

Today we looked at the concept of stream commands, their advantages and disadvantages. A comparison was made with the traditional approach to the formation of specialization teams. Discussed the changes that need to be taken into account when building streaming teams. Subscribe to my telegram channelwhere my publications about architecture and best practices in building teams are collected.