“Silos are evil”. Silos are clusters of activities or people that don’t care about what’s going on elsewhere. This “hillbilly” mindset is the actual evil. Indeed, while User Stories (US) have to be INVEST [Wake 2003] [Moustier 2019-1] and tests “FIRST” [Tekguard 2018] [Moustier 2019-1] (in both cases, the “I” stands for “Isolated”), but for efficiency matters, people should communicate, as per the agile manifesto [Beck 2001], to enable collaboration and interactions.
Actually, silos form naturally because people love it, but by focusing on what you do, you don’t see problems in their context [Taylor 2017]. On the other side, silos are also useful for
Therefore, silos are not entirely bad provided that the organization has to struggle against the silo effect with a “good and frequent ventilation” [Novkov 2016].
For instance, teams may be organized component or feature wise, but if they don’t liaise strongly with other teams, they will simply derive from the overall objective. Obviously, syncing with teams that have no relationship is undoubtedly ineffective. This is why managing dependencies is crucial. Those dependencies can be easily spotted in terms of features, hence the Program Board with SAFe [SAFe 2021-32] which highlights links between US and teams.
In a Program Board, the red lines between US or Enablers represent expected interactions between teams that are triggered notably during weekly syncing meetings (SAFe names those meeting “ART Sync” [SAFe 2021-14]). Following Conway’s law, the parallel between organizations and architecture is merely inevitable [Conway 1968] this is why it is relevant to have a look at Domain-Driven Design (DDD) which states notably [Vernon 2016] [Evans 2004] [Moustier 2020]
There are some other tools that may provide a good ventilation:
Whatever the involved trick, the idea is to avoid delays and discrepancies between linked teams. This special care benefits “value streams”, that is to say the “series of steps that an organization uses to implement Solutions that provide a continuous flow of value to a customer” [SAFe 2021-18].
Using known dependencies is most useful in testing. Say you know from the Program Board Team A should deliver some US to Team B that should deliver something bigger to Team C:
This simple example highlights the social side of testability: B may not know if A did well its job if B doesn’t know how testable the US done by A or is actually well crafted.
Thinking in terms of value streams, B would not wait for A; actually, it would try to anticipate the integration to come (regarding the Context Map, A and B may also collaborate to eventually define the job to be done by A). Under this context, it becomes clear that A and B should liaise on a regular basis to sync their own evolution in regard with the other team. This is what is suggested by the Panarchy model [Gunderson 2002] with progressive levels of synchronization between teams. In this model, teams are subsystems named “ecocycles”. Each ecocycle experiences changing phases α, r, K and Ω. Those adaptations should progressively lead to integrating changes from linked ecocycles into their own ecocycle with higher rates until they are synchronized [Moustier 2020].
When it comes to many teams linked altogether, the sync can be simply resolved through a synchronized and cadenced approach [SAFe 2021-7] which is actually based on the Theory of Constraints (ToC) [Moustier 2020]. This helps to set how connections should be regulated at best to avoid the cost of delays and burning extra energy on forcing merged ecocycles.
Those connections actually provide Double Loop Learning opportunities [Argyris 1977][Smith 2001] [Moustier 2020] to guide the dependency toward its right direction. This avoids having two teams building a bridge from each side of a river with a misaligned result [Evon 2016]. Syncing can be facilitated thanks to X-Teams with some ambassadors who are sent within other teams to ensure just-in-time alignment.
Actually, the combination of
is known to build the Pantesting model, a model for agile testing at scale [Moustier 2020].
This is the responsibility of Managers to act as gardeners in order to let this dependency management by people emerge. Just like with Lean/Agile thinking, “Such a responsibility cannot be delegated” - W. E. Deming [SAFe 2021-36].
Dependency management is actually crucial when it comes to test script automation. Automating test scripts all alone is a bad habit. It’s easy to understand that it is highly recommended to liaise with other people on which your script depends upon to figure out changes that may impact your test design, should it be on
To increase script robustness, when it comes to small changes on widget, Agilitest introduces some Lean Approach mindset such as Jidoka [Monden 2011] thanks to heuristics that guess the right widget to use from predefined criteria. Nonetheless, the tool is not able to interact between people, especially people with whom dependencies exist, should they be tacit or explicit [Nonaka 1998]. This is your responsibility.