How many times we hear the phrase "self-organized" teams when the discussion is about Agile?
I bet a lot. In this article I want to highlight another aspect which may be not be clear of this common phrase. The aspect is how much autonomy the team has?
What does self-organized mean?
For this I will paste a part of scrum guide:
"The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team."
I would like to focus in the following part because I believe it implies a lot.
Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.
Many confuse the cross functional part, as that the team should be composed by developers who can code in any programming language needed for the product. In short, to be full stack developers and even do the QA and automation testing. Even though this is highly desirable, only a few times it can be achieved. Usually there are back end and front end developers, QA people etc.
The part which says "without depending on others not part of the team" tells the story.
Autonomy in skills and infrastructure
Self-organized means how much autonomy the team has to achieve it's goals. This has two factors:
a) Have all necessary skills (UX/UI, back end developers, front end developers, DevOps, QA etc).
b) Have all the necessary infrastructure and tools available for continues delivery.
For bullet-point (a) ,the only comment I have is that you can achieve cross functionality by having all roles in the team, so they can write and test the software. But software doesn't mean only code. It means also pipelines, continuous Integration, continuous delivery and support. That's why DevOps people should be included in the teams.
Isolated DevOps teams are more or less like IT departments, and when you have departments, each one has it's own priorities. Priorities in agile are essential and everyone should be aligned to the next goal of the product. If DevOps teams have different priorities than the development teams then it's highly possible that they will not achieve continuous integration and delivery.
However, having DevOps people in the teams, may not be enough If a team does not really "own" the infrastructure they need in order to build CI and CD.
So you have to make sure that the people in the teams that act as DevOps, have the power to do almost anything the want with the infrastructure (machines, tools, servers etc) in order for each team to achieve their short and long term goals.
Autonomy in code
Let's face the fact that when you scale, you need multiple teams working on the same product/project. Distributing parts of the software as modules in different teams so they do not step on each other toes, does not mean that it's the most efficient way to work.
Component or Module teams may by able to secure separation of concerns and not conflicting code when merged, but they are very difficult to plan and deliver in terms of features and business perspective.
Planning a feature most of the time have to cross through multiple components. Since each on belongs to a different team, the overall planning becomes a nightmare. Dependencies between teams make their sprints fail. User stories are dragged in several sprint and no one can find an efficient solution.
To achieve autonomy in code, feature teams should be created. A feature team is capable of touching all these areas/components in order to complete a feature. You can have multiple teams doing that so there is a chance for better planning. Also knowledge is spread to almost everyone since everyone must write code almost everywhere in the system.
The risky part, is code quality and architecture. The teams must agree on code style, principles, practices and patterns in order to minimize the chaos possibility in the code.
Autonomy means achieving iteration goals
Finally, all sum up to a common purpose. Achieve the iteration goals. The more the teams are autonomous the more the chances to deliver done stuff. Dependencies in any form create risk. Risk causes unpredictability and unpredictability underpins planning and delivery.