Microservices architecture has been a popular topic for a while, but there’s no silver bullet, microservices also come with its challenge. I’m not trying to argue about technical choice in this post but look at it from the perspective of team organization.

Recently I read this article summarizing characteristics of microservices, what I found interesting is the overlap between some of the characteristics and how I think a good agile team should be.

Human communication doesn’t scale

It doesn’t matter much when the size of your team or organization is small when everyone has the time and ability to talk with everyone. It’s a luxury state to be in, direct interaction between team members is high bandwidth, information with the full context being shared consistently, ad-hoc decision being made all the time, and execution across the whole organization can happen in almost realtime.

Once your organization grows beyond this initial stage, communication across the whole organization becomes too costly and the scope tends to change to between teams. Inside a team, you can still have communication between everyone, while across the team boundary, communication only exists between certain teams and in meetings.

Now there’s a difference in how to organize your teams. One common way is to organize by team’s functionality, for example, it’s common to have “Frontend Team”, “Middleware”, “Backend”, “DBAs” all work on the same application system. To implement a certain feature, cross-team communication would need to happen across a lot if not all of the teams. And because of the inherent cost of this cross-team communication, it’s natural for a human to avoid it by making suboptimal decisions only require change inside the team.

A different team structure is to combine people from different functional groups into the same team, which organized around a certain business context. Ideally, in this structure feature requests would reside into a single team’s responsibility in a lot of cases, so it won’t require costly communication.

While for the situation cross-team collaboration is needed, if following microservice architecture, the communication between teams’ boundary has been formalized through API spec. Non-scalable human communication is replaced by scalable machine communication.

The latter option is the so-called cross-functional team.

Deliver what matters

Once you have built the cross-functional team, you might face two related questions.

  • To what extent does the “cross-functional” team span across? Should the traditional IT Operation be part of it?
  • How long is the lifetime of the team?

Traditionally, software development is organized around “projects”. There’re different flavors of project management, but what’s consistent is the assumption of projects complete with some deliverable. With the completion, the projects are going to be hand over to another team for maintenance and daily operation.

More and more people realize the large uncertainty today’s business faces, the product need to be able to respond to clients’ requirements more quickly. It’s hard to define the completion of a project, instead, the product needs to be improved constantly, and focus on delivering more value to clients.

Without the line of completion, the hand over operation model becomes harder to fit, and the centralized operational team can’t keep up with the changes being delivered constantly. Instead, the cross-functional team needs to take on the responsibility of running what’s built.

On the other hand, with the team organize around business capability and focus on value delivering, it makes more sense to keep the team as long as the lifetime of the corresponding business, instead of resolved after project completion.

Alignment without authority

Organize with multiple cross-functional teams, by nature it’ll encourage the autonomy of each team. But we still want to keep some consistency between teams. With the monolith system, the standards can be set around a small set of technology. Often teams can settle on certain standards, write it down and enforce it across the whole organization. While with cross-functional teams that work with a microservices architecture, there’ll be more diversity of technology used and less similarity between services. In this case, organization level written standards can only be set on a very high level.

The alternative approach is to distribute “standard” with shared libraries. If done right, the standard is tested in production and get adopted by more teams because of its usefulness. And since the library is adopted voluntarily, teams will build real consense comparing with rules enforced upon them.

Enable good practice by default

These characters of agile team setup are not tied to microservices, it’s possible to implement most of them without making the technical switch. But with a microservices architecture, a lot of these will happen by nature. That’s the value of a framework/process/library, it enables the good practice by default, makes it easier to do things in a certain way.

To end this post, it feels almost obligated to refer to Conway’s law in every microservices article.