Lately, I have been bitching about Scrum on social media, saying that the waterfall model is still better than Scrum. But then what is the answer? We need some kind of model. Since my answer did not fit into the discussion thread anymore, I post it here instead. This is very agile work in progress; I will certainly continue to work on and refine the article over time.

My first priority, to be honest, is not the client, the product or the code. My first goal is to be physically and mentally healthy. In the last few years, everything has become faster and faster, especially so with Scrum.

Been there, done that! I gained 20 kilos and I had a burn-out 10 years ago. Is it helpful to go faster in the wrong direction? As a developer, I have already developed many failing products – in time and budget! Scrum is very easy to learn – in just two days you are certified. But simple answers to difficult questions? That is nothing other than snake oil! We need good people, especially in management. Developers can be tested objectively. Managers, unfortunately, cannot.

For me, everything starts with trust and respect for one another. After that, we have to start getting rid of all the too-tight processes. For me, “agile” means, above all, risk management. We have to proceed iteratively in baby steps. Why do we need estimates, for example? We only need estimates if the steps we take are too big. If we take a small step and it fails, we just make a new one. In my own projects, I get rough estimates in T-shirt sizes – XS, S, M, L, XL. But I don’t measure my team by that, it merely serves my product strategy. What are the low-hanging fruits that we can implement quickly? Which ideas are too big and immature to implement? Furthermore, extreme programming offers a lot of good ideas about how to develop good products. Pair programming. Mob programming. Testing. TDD! Are you ready for it? Then you are ready to work really agile without a tight corset. Otherwise, I recommend the waterfall model. With this, we might develop the wrong products, but at least not at the expense of our health.

P.S. For what exactly do we need all the control that Scrum provides?!

We need very critical, tough, but fair technical interviews, e.g. pairing on some code for 2 hours. More about this elsewhere. But once we have decided on someone, we don’t have to control every single step. Objectively, as well as subjectively, you can see the work performance of each person without constant null checks. As long as the working relationship brings in more for both sides than it costs, we go this way together. If it no longer suits one side, we split up. This does not make any statement about the quality of either of the parties, but only about the interaction of both. If you don’t fit together, then there is no trust and to continue to work together would then be harmful to both. But as long as you have this trust, as long as you want to work together, there is no need for constant control mechanisms that evaluate performance very one-sidedly. They damage our relationships, they damage creativity, and they generally reduce our performance as a team.