The autonomy of teams is a core value in DevOps. A team can fulfill that responsibility and conduct everything necessary only by defining certain boundaries to limit responsibility. Some of the dimensions that you should consider while defining boundaries are:
Dimension 1: Determining in what ways services or (parts of) the system are manageable for a small group can be looked at from the following perspectives:
- Technology point of view, forming a team around a (set of) component(s)
- Business point of view, forming a team around the business Service
Dimension 2: It is effective to adjust IT and business so that clear business ownership is achieved.
Dimension 3: The role of architecture is important as well. For example, a monolith can make it hard to keep the team small and nimble enough to respond quickly to business needs.
Dimension 4: An ideal infrastructure is Cloud-based that enables the creation and dismantlement of the necessary environments whenever required. Such an ideal situation is not always (directly) possible for the DevOps team. In its most extreme form, the focus can be entirely on the business services without having to worry about the infrastructure.
The autonomy of teams in established or large IT organizations relates to systems or services that interact with each other. Consequently, the changes in any system depend on other systems and teams that interact with the system of change. Therefore, it is essential to balance team size and its autonomy while defining it. Avoid making overly large teams while enabling it to work as autonomous as possible.
Source: DASA DevOps Product Owner coursebook.
DASA DevOps Product Owner
Help realise maximum business value, engage with stakeholders, and deal with future requirements as well as operational challenges.
