Focus on the entire solution

The importance to focus on the entire solution

A customer does not buy a part of a solution but a whole, and as long as a team's development is not integrated into the product, it has no value. With this in mind, the DoD should therefore include integration and not just the realisation of the code for a given User Story (US) [LeSS 2021-1].

Furthermore, an improvement of a part of the product must be seen in the whole solution and even if a choice is made between a local optimisation of the system and a global improvement, LeSS proposes the whole product instead.

Indeed, a new, more efficient version of a business process that is inconsistent with other processes is unlikely to be perceived positively by customers. It is therefore important to involve the teams in a process where all are aligned with this objective.

This systemic aspect is all the more reinforced if the product is the result of collaboration between different engineering sectors, such as the medical or automotive sector, which brings together software development, electronics, mechanics, etc. In agility, this multi-domain approach is possible thanks to the Model-Based System Engineering (MBSE) approach [Moustier 2020] and clearly shows the need to grow the product as a whole and not just a part of it: if the code does not allow an innovation linked to the hardware to be piloted, nobody will be able to use it.

Thus, to address this underlying systems approach, Peter W. Senge proposes eleven laws [Senge 1994]:

1. Today's problems come from yesterday's 'solutions'.
2. The harder you push, the harder the system will push you back.
3. Behaviour gets better before it gets worse.
4. The easy way out usually brings you back to the office.
5. The cure can be worse than the disease.
6. Wanting to move faster slows you down.
7. Cause and effect are not closely related in time and space.
8. Small changes can produce big results... but the areas where the leverage is highest are often the least obvious.
9. You can have your cake and eat it too, but not immediately.
10. Splitting an elephant in half does not produce two little elephants.
11. Do not throw stones.

In this perspective, there are tools that facilitate the systemic approach to product engineering and align business, management and technology, including :

• Impact Mapping [Adzic 2013].
• Event Storming [Brandolini 2019]
• Story Mapping [Patton 2014]

Application to test maturity

To support the systemic view of the solution, the testing effort will inevitably need to integrate the four quadrants of agile testing [Marick 2003][Bach 2014][Crispin 2021] so as to address many aspects of testing including non-functional requirements [Hage Chahine 2018].

However, in order to address the full range of aspects expected by the system, the incremental, paced and synchronised approach sometimes implies being able to test a partially completed product without wanting to impact all of its customers. For this, practices such as Dark Launch or Canary Releasing can be used.

If we want to have a systemic vision of testing, PanTesting [Moustier 2020] allows us to address a holistic approach to agile testing at scale by introducing the concepts of:

• Double learning loop
• Theory of constraints
• Panarchy

which are combined with testability.

Agilitest's position on this practice

Agilitest is a tool for automating test scripts and in this systemic vision of the product, it is of high added value to combine the use of this tool with the practice of ubiquitous language to reflect the parts of the domain that are tested automatically.

Furthermore, to facilitate the provision of an expected part, Agilitest's #nocode approach [Forsyth 2021] allows for simple and quick test automation.

‍

To discover the whole set of practices, click here.

‍