Skip to main content

Cross-Functional Teams

Context​

Microservices are being adopted. Each microservice is managed by exactly one team. The team is responsible for the whole life cycle of their microservice(s). Potentially, you are coming from a horizontal team distribution into a development team, a test/quality assurance team, an operation team, and so on.

Problem​

  • The current teams lack knowledge from different roles to accompany the whole development life cycle of a microservice (development, testing, operation, ...)

Solution​

Align the organizational structure to the cut of microservices by building vertical cross-functional teams. The combination of different roles into one team ensures the knowledge to support the microservice through its full life cycle is given.

Taking this one step further, other roles like security experts (SecDevOps) and domain experts can be part of the team as well. Mixing roles in one team leads to a reduced chance of "we against them" situations and simplifies spreading knowledge between roles. Cross-functional teams serve reducing the communication overhead between multiple horizontal teams. Thus, cross-functional teams to foster faster release frequency.

Maturity​

Proposed, requires evaluation.

Sources of Evidence​

L3:

  • Traditional: horizontal division into dev team, QS team, ops team,...
    • Delays dev life cycle due to the transitions between teams and their reaction frequency.
    • Can't benefit from increased comprehensibility of code and easier assimilation of new team members that microservice system decomposition offers.
  • DevOps: divide vertically into cross-functional teams: each teams with people with different skills (dev, ops)
  • create more value for the particular service's end users
  • more frequent releases (since no transition)
  • Focus of teams leads to higher maintainability, comprehensibility, add members with lower learning curve

L5:

  • Organizational alignment as quality attribute of microservices
    • equals cross-functional team
    • equals reduce the conflict between developers and testers

L6:

  • Microservices motivate to build teams around business capabilities instead of traditionally on tech layers
  • Results in cross-functional teams with each team full range of skills required for specific business layer
  • prevents the "logic everywhere" siloed architectures.

L8:

  • Cross-functional teams were highly influential on the microservice architectural style

L14:

  • enables scaling development capacities according to changing business requirements
  • teams should be highly independent, having memebrs of all roles and skills to build and maintain their microservices

L27:

  • Microservice paradigm suggests cross-functional teams
  • Reduce communication overhead to external teams, but maximise internal communication and cohesion
  • Mechanism how to build coming from a monolith, grouping files by their authors.

L32:

  • Handoffs between different groups makes management of microservices difficult
    • e.g. requirement engineers, devs, testers, ops
  • Remove handoffs and build autonomous teams => full responsibility

L38:

  • Article presents the need to collaborate if you have different dev, test, ... teams
    • Scenarios as documentation and means of communication
    • Cross-functional teams are not presented here
  • Often for big enterprise apps: separate dev and tester teams => need to collaborate (also with analysts)
  • Mono-repo: collaboration becomes easier
    • vs. dedicated AAT repo: avoid conflict between devs and testers
  • Scenarios emerging from BDD: powerful means of communication between devs, testers, analysts

L42:

  • organizational challenges like cross-functional teams need to be faced before fully benefitting from microservices

L45:

  • Cross-functional team for building and operating their product

L61:

  • Not many studies take the lifecycle phase perspective
  • DevOps with goal to have dev and op teams work closely together in one paper

LN42:

  • DevOps is framework for developing, deploying, and managing microservice container ecosystem
  • With refactored SOA => DevOps can ensure fast delivery cycles
    • by integrating the previous silo-style business processes of development and operations
    • Interpretation: this integration connotes putting dev and ops into one team
  • Start with a DevOps tailored strategy for microservices
    • better integration across lifecycle and gradually evolve microservices

LN43:

  • Microservices require composition of teams to change
  • Monolithic => dev, qa, ops as separate teams
  • Microservices => horizontal borders need to be broken and align vertically
    • every team consist of people from dev, qa, and operation
  • in order to take full responsibility of microservice lifecycle => requires skills to deploy and fix problems in production
    • => adopt DevOps mentality
    • CI aims to shorten release cycles by making devs and ops work together
    • Every team needs to handle deployments
    • There might be not enough people with corresponding skills => team members need to lear new skills and enhance deployment process
    • when ops and devs work together in same team, they have similar goals
    • but education and adaption takes time and patience

LM43:

  • Context: SLR findings about microservices in DevOps
  • Organizational problems related to culture, peopls, cost, organization, and team structure
  • Among others, introducing small cross-functional teams

LM45:

  • Context: interviews and insights from multiple cases on technologies and sw quality in MSA
  • C9-S13: teams organized in cross-functinoal squads following the Spotify modul
    • but limited autonomy

Interview A:

  • Organizational challenge: migrate to cross-functionality, especially for older companies used to the traditional silos (db op, middleware op, webserver op)

Interview B:

  • Take it one step further: domain knowledge into teams

Interview C:

  • In the past: hard to describe quality attributes and QoS of components => dependent on how deployed
  • Microservices: teams control how deployed ==> define scalability, elasticity, availability, ...
  • Leads to serious QoS without parameters
    • Within some boundaries, we can guarantee you...
  • Increased maintainability
    • better document and pass on knowledge
    • since maintaining within the cross-functional team
    • there is at least one person who operates the component => reduced possibility for knowledge loss
  • Pull other roles into teams:
    • Ops
    • Business
    • Testers
    • Security => SecDevOps
  • Cross-functionality aligns with goal to reduce communication overhead between teams
    • Learn from each other: terms, domains, ...

Interview D:

  • What is even possible with team structures?
    • DevOps => Capability teams end-to-end
    • or is it just a dream what you would want to do?
  • Organizational constraints
    • If test team, no on-demand test environment, even if introduced SAFE to centralize processes => one release train
    • Do you really want to pay the prize without reaping the benefits of microservices?
  • Typical consulting situation: they want to do DevOps
    • "CAP Theorem for managers": reaction speed vs. cost efficiency vs. high quality
      • DevOps = reaction speed + high quality, no cost efficiency
      • otherwise => not DevOps, not microservices, but industrial software production (maximize output against costs)
      • more lightweight than DevOps: Site Reliability Engineering
  • Start with goals, then see what organization constraints let you do
    • when doing DevOps => end with microservices or at least some capability-oriented modularization of teams
      • otherwise they can't move independently
      • => microservices is an answer, not a question

Interview E:

  • Vouches for vertical teams if possible
    • he often can't influence that since he joins a project as a consultant and org structures are how they are
    • doesn't mean every dev has to be full-stack
    • but know-how for a vertical should be within the team
    • everyone should have sympathy for the others
    • agrees that vertical teams solve problem "how do interfaces emerge" with frontend by locating it within one team => short communication pathways
  • Observation if there is a horizontal cut: one or multiple backend teams, frontend team
    • often problems lead to "we against them" situation
    • Who drives interface between frontend and backend?
      • most often the backend team
      • but letting frontend team drive API makes sense if UX should be optimized
      • => depends on application domain