Dependency Board

Dependencies are a Bugaboo

One thing up front:

Dependencies are a Bugaboo; …

Dependencies should be avoided or at least reduced wherever possible!
Dependencies bear risks, restrict freedoms and often result in non-compliance with plans.

If WE do not finish in time, the OTHERS cannot continue and the plan may fall through. Commitments to third parties are not kept and the time-to-market of a product is delayed. If this is the norm, there is no way this can be considered a good thing, right?

The Dependency Board …

often a visible sign that something is wrong.

Dependency Board

If you can knit a sweater and underwear from the sum of the woolen threads that show the dependencies on the Dependency Board, you can suspect that something in the setup of the Agile Release Train (ART) is suboptimal.

Avoiding / reducing dependencies by optimizing the ART

An ART is responsible for the development of a Product or Solution . What exactly this is and what it includes – in scope / out of scope – is worked out via a Value Stream Analysis. Part of this analysis is also to name the systems and experts that are required for the development of the product – or the solution. The Value Stream Analysis is directly followed by the ART Identification.

The goal is to define an Agile Release Train that can develop the product or solution as independently as possible. Because as we all know, dependencies make life difficult.

Agile Release Trains are divided into Scrum Teams, each of which is responsible for a part of the product / solution. Here, too, it is important to find a setup that creates as few dependencies as possible. The more autonomous each team can develop, the better.

Value Stream Analysis and ART Identification can be performed at any time. Whenever you have the feeling that dependencies are making your life too difficult. Usually, however, they are at the beginning of every ART.

Avoiding / Reducing Dependencies through Feature Toggling

Dependencies arise where one is dependent on the other. Colloquially, „I can’t move forward until you deliver this to me.“

zwei Teams sind vom Ergebnis der Arbeit des vorangestellten Team abhängig

Here, the party that has to deliver something can be referred to as the server or provider, and the party that depends on it can be referred to as the client or consumer.

Either data must be provided by a provider in order for a consumer to use it, or a consumer makes a request directly to a provider in the form of a function call or rest call. Whatever the case, there is a dependency.

From a programming point of view, such a dependency can be avoided during the development phase and before going live by means of

  1. Feature Toggling
  2. Mocking

for the period of development and before going live.

When the consumer (client) implements its part of the customer request, it simulates the provider (server) that does not yet exist by means of a so-called mock. A mock simulates the presence of all the things that have to be delivered from the outside – a provider (server).  Of course, this also works the other way around, for the team that has to program the provider (server). The respective „other side“ is simulated. In this way, development can take place independently of each other.

At the same time, a switch – a so-called feature toggle – is built into the program code, by means of which the use of the not quite finished functionality can be prevented. Such a toggle disables, for example, the visibility of a link or a button on the user interface, because perhaps not all components of the programming are ready yet.

Unfortunately, all too often mocks and feature toggles are not used, which unnecessarily exacerbates the problem of dependencies.

Avoidance / reduction of dependencies through contract-driven development.

This is the pinnacle of software development.

Contract-Driven Development is a new approach to systematic software construction combining ideas from Design by Contract, from Test-Driven Development, from work on formal methods, and from advances in automatic testing as illustrated for example in our AutoTest tool. Like TDD it gives tests a central role in the development process, but these tests are deduced from possibly partial specifications (contracts) and directly supported by the development environment. This talk will explain the concepts and demonstrate their application.1

More on this another time.


It is amazing that dependencies are pointed out, but seemingly no one thinks of the one, obvious question: „How do I eliminate this mess?“ Appropriate methods have been around long enough.

Want you to minimize dependencies and optimize ART?

1. Meyer, B. (2007). Contract-Driven Development. In: Dwyer, M.B., Lopes, A. (eds) Fundamental Approaches to Software Engineering. FASE 2007. Lecture Notes in Computer Science, vol 4422. Springer, Berlin, Heidelberg.

Keine Kommentare

Share This Story, Choose Your Platform!

Über den Autor:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Bitte füllen Sie dieses Feld aus.
Bitte füllen Sie dieses Feld aus.
Bitte gib eine gültige E-Mail-Adresse ein.
Sie müssen den Bedingungen zustimmen, um fortzufahren.