Decentralize decision making

Description

The validation of decisions by the hierarchy introduces waiting times that are detrimental to the fluidity of production, and the use of escalation decreases the quality of decision making because of the loss of context and the potential changes inherent in waiting times [SAFe 2021-9].

This is why agility proposes a decentralisation of decision making according to context.

The basic principle is that of subsidiarity, which implies that everyone can do things as they wish, unless it is demonstrated that the higher-ranking decision is more effective [Delavallée 2011].

In this line, SAFe proposes to decentralise everything except when [SAFe 2021-9]

• it rarely happens
• the decision is unlikely to change in the short term
• savings can be made with a scale factor

‍
The customer-centred organisation will organise to create added value and the hierarchy, created by the need for organisational rationalisation, and the two organisational modes generally come into conflict but the hierarchy always wins [SAFe 2021-17]. This principle of decentralisation allows a kind of middle ground between these two organisations.

Thus, Management 3.0 integrates the hierarchical dimension necessary for the company, especially on aspects related to authorisations [Appelo 2010]. It provides for a workshop called "Delegation Poker" [Appelo 2014], which enables a workshop to define the level of delegation expected between "You do exactly as I tell you" and "I delegate to you completely" for each type of action.

Application to test maturity

When a test strategy has been decided by a Test Manager or is defined too far in advance, only the people facing the actual context of the product to be tested are best able to decide on the best approach to take to the field, either in terms of tools or in terms of how to approach the test, unless the predefined delegation criteria are violated.

For example, in a Scrum team, the tester must synchronise with the Product Owner (PO) to have the PO decide on the added value of a choice on the time allocated to testing because the Scrum rules indicate that the PO is responsible for the return on investment [Schwaber 2020]. In other words, Scrum introduces governance on what is delegable and what is not, the PO estimates the added value of the testing activity based on sound advice while the tester defines the approach that seems most relevant to him according to the time allocated; this policy is similar on the part allocated to refactoring in the Sprint. In this respect, the SRE approach, Google's vision of DevOps, proposes the management of an error budget which is managed by the PO [Beyer 2016].

Agilitest's position on this practice

Agilitest offers a test script automation tool. The choice of adopting agilitest or another framework can be seen from the point of view of subsidiarity because, depending on the profiles and needs, agilitest can be adapted (particularly in the case of testers with a non-technical background) or unsuitable (in the case of teams of developers who prefer to manage test automation while remaining in their favourite IDE).

It is not uncommon for an organisation to want to adopt the same tool for the whole company in order to massify purchases and benefit from lower prices; however, the licensing costs associated with Agilitest only represent a few days of an engineer's time and the gain from the commercial reduction does not really compensate for the losses due to the loss of motivation of a productive team.

‍

To discover the whole set of practices, click here.

‍