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.
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.
See also: Inner and Outer Dependencies
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.“
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
- Feature Toggling
- 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.
Conclusion
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. https://doi.org/10.1007/978-3-540-71289-3_2
↩
