Dependency management

Planning

Dependencies will help testability

Planning

Description

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 

  • it’s easy to manage
  • it creates belonging
  • it builds trust
  • it provides focus

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.

A “Program Board” - illustration from [Moustier 2020]

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]

  • an ubiquitous language - this enables different team sharing thanks to a same language
  • a “Context Map”  - this provides different kinds of relationships on a systemic point of view; from those types of relationships, the interaction degree may be adapted [Moustier 2020].
Different kinds of relationships found in a Context Map [Evans 2004]

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].

Impact on the testing maturity

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:

  • Team A may do some “local end-to-end testing” (which is actually close to component testing) as soon as it is possible
  • Once Team A delivers the US to Team B, the second team may do some integration testing and then wider end-to-end testing
  • Naturally, Team C will do the same at a wider level.

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].

Path to merging ecocycles [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 

  • testability
  • panarchy
  • double loop learning
  • and ToC

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].

Agilitest’s standpoint on this practice

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

  • features bound to be altered or that may not be ready for testing
  • widgets to interact with
  • relevant business data to inject in test runs
  • etc.

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.

Related cards

To go further

  • [Conway 1968] : Melvin Conway - « How do Committee Invent ? » - Datamation magazine - 1968 -http://www.melconway.com/Home/Committees_Paper.html 
  • [Evans 2004] : Eric Evans - FEV 2004 - “Domain-Driven Design: Tackling Complexity in the Heart of Software” - ISBN : 9780321125217
  • [Gunderson 2002] : Lance H. Gunderson & C. S. Holling - « Panarchy - Understanding Transformations in Human and Natural Systems » - Island Press - ISBN 1-55963-857-5
  • [Moustier 2019-1] : Christophe Moustier – JUN 2019 – « Le test en mode agile » - ISBN 978-2-409-01943-2
  • [Moustier 2020] : Christophe Moustier – OCT 2020 – « Conduite de tests agiles pour SAFe et LeSS » - ISBN : 978-2-409-02727-7
© Christophe Moustier - 2021