This is an automatically generated post with Deepl. The original article was published here in 2019.
“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”
John Gall
Many years ago, I saw an impressive documentary about a man who built a suspension bridge in the Andes. First, a thin rope was thrown across the gorge and then a thick rope was pulled across with its help. To do this, the man had to descend into the gorge and climb up the other side of the gorge. But once the thick rope was attached on both sides, the man was able to transport tools and materials across the gorge. The single rope became several ropes, then the basic structure of a bridge and later a complete suspension bridge.
What does this have to do with agile software development? Building a bridge without any kind of modern technology? Only ropes and wooden planks as materials? Let’s take a look at another form of construction activity, instead of lofty heights, let’s look deep into the rocks of a mountain range.
Several teams of miners drive tunnels through the mountain, so that the teams can work simultaneously, they do not simply start on one side of the mountain and drill their way through to the other side, but start their work on both sides. This allows them to at least halve the time needed to build the tunnel. In this case, however, they drive another shaft halfway into the mountain and start a tunnel from here, in both directions. This reduces the tunnel construction time to almost a quarter of the original plan. However, there is a risk in this plan. The excavations will meet somewhere in the mountain. Only when the breakthrough is made will success or failure be known. The measurements, planning and work must be carried out extremely accurately, otherwise a horizontal or vertical misalignment of the tunnels will cause the project to fail.
Tunnel constructions are classic waterfall projects in which extensive planning can be carried out and then construction can be completed without major changes. There are geological surprises from time to time, but a tunnel plan is, quite literally, set in stone.
Many software developments are carried out like tunnel construction projects. Many tunnel sections are marked out and work is started, and later the connection points for the individual sections are considered. However, software projects are not driven through granite, but are in a soft, malleable and seemingly living mass called market requirements. Even if the sections are implemented correctly at the beginning, it may turn out in the course of the project that a number of connectors have been forgotten, requirements have been changed and some parts have been planned completely incorrectly.
Agile development is based on 12 principles. The first of these is
“Customer satisfaction through early and continuous software delivery.”
A tunnel construction project, as described above, does not comply with this principle. A tunnel that has only been driven a few meters into the mountain does not help the customer. Neither do individual sections in the mountain. The customer can only use the product once all sections have been successfully connected.
The primitive suspension bridge stands for projects that allow the customer to provide feedback to the project team at an early stage. Although only a rope is stretched across the gorge at the beginning, the customer can use it. They cannot yet transport larger loads across the gorge, but this will gradually change.
A payment system for an online store can be created either bottom-up like a tunnel construction project or top-down like a suspension bridge. In both cases, you need a shopping cart, a choice of payment method, dialogs for bank transfers, credit card payments or Bitcoin transactions.
While with the buttom-up method the complete components are put together and only then, at the end of the project, do serious planning deficiencies become apparent, a top-down design starts with the simplest functioning system. The shopping cart may not even be able to display the products correctly at the beginning and only prepayment is initially possible as a payment method, but the customer can test the software, give feedback and try out new ideas.
Top-down development is also invaluable for the development team. Everyone involved can rely on a truly functioning design from day one.