Agility and Subsidiarity: Autonomous Decisions?—?Shared Responsibility

Agile organizations rely on the principle of subsidiarity. Decisions are always made as decentralized as possible. The next higher or next larger unit only takes action if the smaller unit is not able to solve the task alone. But even then, the objective is still to help people to help themselves. However, this only works if autonomy is given a common orientation towards a higher purpose. Constant work on and with this purpose as a guideline is thus one of the most important leadership tasks in an agile organization. And actively assuming responsibility in the sense of a common mission is the most important task of the decentralized units, by which their autonomy is legitimized.

Agile Teams Don’t Have Roles

Agile teams avoid sharing responsibility between roles. In Scrum, for example, there are no explicit roles in the development team. Rather the team assumes joint responsibility for the user stories it commits per sprint. Obviously, delivering those stories requires a wide range of skills in the team, from user interface design and backend programming to user documentation. Dedicated roles are not required for this and would be detrimental to the responsibility for the common goal (and detrimental to the team’s flexibility).

Break down barriers between departments. People in research, design, sales, and production must work as a team.

W. Edwards Deming

Feature Teams Take Joint Responsibility for Their Product

Leaving the level of the individual team as the smallest unit of an agile organization, one comes to the question of scaling, i.e. how several teams work together on a single product. LeSS and SAFe, the two best-known scaling frameworks, agree that so-called feature teams are best suited for this.

What already applies on the small scale of a team is repeated on a large scale here: In contrast to component teams, feature teams are not responsible for a specific part of the product (e.g. for a module or a component), but implement requirements (features) all across the product. Feature teams thus inherently assume more responsibility than component teams. Therefore they are the better choice (besides the higher flexibility they offer).

Objectives & Key Results Provide a Common Direction for the Agile Organization

Yet another level higher the question arises how to align a product portfolio (if one happens to have more than one product) as an agile organization. Here, the shared understanding of purpose and mission is the decisive framework for agility. As a link between this long-term guideline and the daily work, Objectives & Key-Results (OKR) can be used as a method for setting goals in an agile way and thus provide a common direction for the products.

At first OKR — like so many other things — are deceptively simple: Ambitious goals are equipped with a few key results with which the attainment of these goals is measured. All this is newly agreed in short cycles (e.g. quarterly) (see also this tutorial at Google re:Work). What is decisive here is that a significant part of these objectives are developed from the bottom up, i.e. subsidiarity clearly applies here as well. Equally important is that all OKRs on all levels are completely open and present at all times. Ideally, the key results are chosen in such a way that they are not only measured once at the end of the quarter, but are constantly updated. In this way, the individual teams can immediately recognize the impact of their work on their common goals.

Discipline is achieved through self-organization and personal responsibility, by disciplining one only gets obedience.

Gerald Hüther

Originally published at fuehrung-erfahren.de on October 11, 2018.