Do everything at the same time

The origins of Agility

In 1986, Ikujiro Nonaka & Hirotaka Takeuchi, two academics who observed companies such as Toyota, defined three categories of companies [Nonaka 1986][Moustier 2019-1] :

• Type A companies, such as NASA, which divide work into well-defined phases and do not move on to the next phase until the previous one has been completed.
• Type B companies, where the phases overlap slightly, based on the observation that it is conceivable, for example, to start the architecture when 80% of the specifications have been completed.
• and type C companies where everything is done at the same time, like in a rugby scrum.

‍

It turns out that Jeff Sutherland claimed to have read this article in the early 1990s [Sutherland 2007][Moustier 2019-1] before he and Ken Schwaber created the "Scrum" framework.

Thus, the "C-type Scrum" proposes to try to do everything at the same time.

In fact, when you look at it closely, when you work in agile mode, you do specification, design, code and test, just like in Waterfall; what comes to change is that the cycle related to these steps is so short that you can no longer differentiate when you are doing which activity [Rainsberger 2014].

It is this time constraint that has progressively driven the emergence of agile practices to find solutions that allow several things to be done at the same time.

Application to test maturity

Among the practices that agilists have shaken up, we obviously find testing. Not only is there a tendency to do it all the time (this is the concept of Continuous Testing [Moustier 2020]) or even to start with it, but also to mix this activity with others.

Thus, we find in particular :

• TDD, which consists of doing the code in parallel with unit tests, which allows a certain level of design [Moustier 2020].
• ATDD, which are neither more nor less than executable specifications [Ambler 2005], they are like a Moebius strip, sometimes specifications, sometimes tests [Moustier 2020] and the execution of automated scripts provides both the acceptance conditions for a User Story (US) and the regression tests for past US
• Pair programming during which the code review is done at the same time as the code production, this work mode also allows a transfer of competence [Moustier 2019-1] which is particularly formidable at the level of a team when it practices Mob programming
• the "3 Amigos" or "Example Mapping" make it possible to review a US and generate acceptance tests [Hage Chahine 2020] [Moustier 2019-1].
• "Living Documentation" allows the code to be generated at the same time as the documentation and the code structure tests [Martraire 2015][Moustier 2020].
  exploratory testing consists of writing test scenarios at the same time as executing them [Moustier 2019-1].

‍

‍

Agilitest's position on this practice

Agilitest allows regression tests to be performed using the ATDD practice.

‍

To discover the whole set of practices, click here.

‍