When SAFe refers to agility, it is the term "lean-agile" that appears throughout its documentation [SAFe 2021-21]. Indeed, agility has its roots in Lean, the term of which was popularised by [Womack 1990], which traces the success of Toyota [Poppendieck 2002].
Jeff Sutherland, the co-daddy of Scrum, based this framework on his study of Lean [Sutherland 2007] and even found the name of the framework [Sutherland 2011] from an article by the founder of Lean Management entitled "The New New Product Development Game" [Takeuchi 1986].
Also, Lean practices are a great source of inspiration to enrich agile practices because they are better understood and limit the "Cargo Cult" effect [Moustier 2019-1] [Wikipedia 2021] which consists in a team thinking it is agile simply because it has Jira or post-its stuck on a wall.
Among the Lean practices found in industry that can be transposed to software development are [Moustier 2019-1] :
- eliminating waste with the 3Ms (Muda, Mura, Muri) [Monden 2011].
- software life cycle flow optimisation with Value Stream Mapping (VSM) [Poppendieck 2006].
- the speed of adaptation of a tool to a change in need with SMED [Shingo 1985], which agility translates into a rapid adaptation of the team to changes [Beck 2001]
- the principle of timing work with Takt Time [Monden 2011], which the practice of timeboxing facilitates [Schwaber 2020].
- Kanban [Monden 2011] [Poppendieck 200]
- Work in Progress (WIP) [Monden 2011]
- Just-in-Time (JIT) [Monden 2011], which consists for example of filling the backlog only at the right moment
- Poka Yoke [Monden 2011] by putting in place mechanisms that prevent errors from occurring
- the 5S [Monden 2011] to remove the unnecessary, systematise, sparkle/clean, locate/tag and track any type of item such as a backlog, source code, bugs, etc.
- Andon [Monden 2011] to raise and manage alerts such as at scrum time or alert management in SRE [Beyer 2016].
- Jidoka [Monden 2011] to automatically handle incidents encountered in scripts [Moustier 2020].
- regular practice of the Gemba [Womack 2011] to improve the transparency dear to Scrum [Schwaber 2020].
- PDCA [Moen 2010] to continuously improve the system
There are also other derived practices commonly used in industry such as [Moustier 2020]:
- Theory of Constraints to eliminate bottlenecks with a systemic approach
- Hoshin Kanri [Cudney 2009], which can be found in Google's OKRs
- Kaizen [Medinilla 2014] and Kaikaku [Yamamoto 2013].
Application to test maturity
The testing activity needs to be industrialised to cope with the large amount of testing that needs to be done in a short period of time that is the sprint. Lean practices from industry are, with a little imagination, perfectly transferable to this activity, as long as one understands these practices and what is behind them:
- 3M: regular testing, without excess (over-quality or too much testing) and with good added value
- VSM: duration of test activities in the production flow [Moustier 2020].
- SMED: quickly adapt its test strategy to the deliverables to be verified - exploratory testing is particularly relevant in this context
- Takt Time: timing of test activities within a limited timeframe
- Kanban: test-related activities are in the team's kanban, either in each User Story or in the form of Quality Stories [Bach 2019] (what SAFe calls "Enablers" [SAFe 2021-23])
- WIP: testing should take place without delay and be supported by all
- JIT: tests occur on time
- Poka Yoke: automatic tests intervene to quickly indicate the appearance of anomalies [Moustier 2019-1].
- 5S: test assets must be regularly purged [Moustier 2019-1].
- Andon: as soon as an anomaly is detected by the tests, an alert is raised [Moustier 2019-1]
- Jidoka: automated test scripts must adapt to try to deal with apparent anomalies and avoid false positives [Moustier 2020]
- Gemba: the tester must be the voice of the customer in the team and the implementation of X-Team [Ancona 2002] is of high added value to try to synchronise the external ecocycles to his team [Moustier 2020]
- PDCA: the test activity must be continuously improved
Agilitest's position on this practice
The #nocode strategy [Forsyth 2021] adopted by Agilitest allows for very rapid adaptation of test scripts and favours most of the Lean practices mentioned above; moreover, this strategy reduces the sense of loss aversion [Moustier 2019-1] linked to the deletion of a script, which facilitates 5S.
In a Continuous Testing approach where test script automation is abundant, the issue of Jidoka is critical because handling false positives slows down the development cycle flow [Moustier 2020]. To this end, #nocode allows the generation of few errors in scripts, which considerably reduces the presence of script-related errors.
An essential area of improvement to facilitate Jidoka is the testability of the application and its underlying components so that an error detected at one level can be verified at a lower layer of the product architecture.