06. Jul 2021
What clamping building blocks have to do with agile software development

In software development, agile processes and methods are already commonplace for many. But also in other industries, the iterative and incremental approach makes sense and even in everyday life you sometimes come across situations in which the agile approach helps. This is how Christoph Geiser, Product Owner at XITASO, recently felt when building a model. In the following, he shows the advantages of the iterative and incremental approach and what this has to do with clamping building blocks.

Christoph Geiser
Product Owner

Recently, I once again assembled a model from building blocks. Even in my mid-30s, I still find this fascinating. Not so much because I want to play with it later, but rather because I’m excited about the process of building and exploring the functions of a model. This time it was to be a concert grand piano.

Agile approach; even outside of software development

During my building process, I came across a section in the instructions that reminded me of the agile development process that we value at XITASO and actively live every day.

So I thought about the best way to proceed here: I could build all the keys in parallel. So first twelve times step 1, then twelve times step 2 and so on. After completing step 6, all twelve hammers would be completely finished and could be installed. The other approach would be to build the hammers serially, i.e., carry out steps 1 to 6 one after the other for one hammer each; and repeat the whole thing twelve times.

Which of the two variants makes more sense?

To find out, I first considered the time required and wondered if I could finish faster with one of the two variants. Probably not as the effort is the same in both cases.

Does the result differ between the two methods? That’s not the case either, because in the end I have twelve hammers in my keyboard, no matter how I build them. Or is it? If you take a closer look, you will actually find a difference: If I build all twelve hammers in parallel, I only finish all the parts in construction step 6. Only then can I use the hammers and have a functioning keyboard.

But if I build the hammers serially, as in one by one, I would quickly be finished with the first hammer. I can install this directly and have functional parts of the keyboard after a short time. So, it’s actually an iterative and incremental process.

Iterative and incremental process

And it is precisely this process with which we quickly achieve results in agile software development: We model and build software in such a way that we can proceed step by step and present a functional product to our customers after each step. If necessary, there are further iterations.

Another often used image for this process is car manufacturing. My colleague Baptiste Grand, Agile Coach at XITASO, explains what this is all about as part of our webinar series “Agile Wednesday“:

What I really like about it is that after each intermediate step, I already have a product that meets my target (in this case transport from a to b). Just like I can use the first keys on my grand piano at an early stage.
The image of car construction is by Henrik Kniberg. If you want to know more about the background, I recommend his article “Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable“.

My summary

The agile approach has many advantages. Not only for us as software developers, but above all for our customers. You have probably experienced it yourself. What can be more annoying than commissioning a project and not seeing a result until months later. In the worst case, the product is very different to the expectation and may have functions that you do not need at all. So, it is much better to see the first results quickly and to be able to test and use a product yourself at an early stage.

This also offers the advantage that the feedback from the customer can be sought much earlier. Because if the customer can try out and use the product at an early stage, he recognizes in good time whether the chosen path is the right one, or whether corrections are necessary. It is much better when the iceberg is detected early, and a change of course is still possible.

Author & contact person