Effectiveness is the new efficiency
For all Scrum fans, let’s get the bad news out of the way: Scrum is just a compromise. The good news is that this is the only piece of bad news.
However, it has far-reaching consequences. For example the fact that many developers have to throw everything they thought they knew about software development overboard and have to learn the craft anew.
The reason for this is the nature of the compromise; this should be taken very seriously. In practice, this is rarely the case because often people don’t really understand it. This leads to bitter disappointment in many Scrum projects.
This post aims to spare you this kind of disappointment. The magic formula behind this is effectiveness instead of efficiency (Scrum vs. waterfall). Anyone who is no longer familiar with the difference between effectiveness and efficiency, we will refresh your memory here.
Scrum vs. Waterfall
Efficient procedure with waterfall
In the – let’s say – classical development process, we try to create a perfect world for ourselves by first creating a general and then a detailed specification, sending it through various review processes and approvals, then designing an architectural model, etc. We then create an architectural model for ourselves.
In short, the object of the project is made transparent and therefore easy to plan. This takes time and costs money, but it enables us to proceed very efficiently.
An efficient approach means creating an optimal relationship between input and output, which presupposes that I know exactly what I have to do and that I can plan my actions accordingly.
This usually leads to an optimized horizontal, i.e. layer-oriented development (e.g. data model, data access layer, business logic layer, GUI layer).
But what if you don’t have the time or money to go through this often lengthy process of specification?
You can’t just create a perfect world in passing. Or you lack the resources or the knowledge to describe such a perfect world.
But maybe you already know that the requirements can change during the project because you need to be able to react to market situations.
And even worse: software has become much more complex in the 21st century. In addition, it is often much more interconnected and time-to-market requirements are also significantly higher today, and often all three factors are at work simultaneously. In short, we need more functionality (and therefore complexity) in less time. And the spiral goes straight up.
It’ s a vicious cycle. Because these factors are actually the reasons why you should create a perfect world in which you can proceed very efficiently.
Project managers are faced with a dilemma and a compromise needs to be found: SCRUM.
Effectiveness as a compromise in Scrum
Scrum is a compromise that we make when we don’t have a perfect world but still want to successfully complete a project.
But because we cannot be efficient without this perfect world of detailed specifications, architectural models, etc., Scrum shifts the focus from efficiency to effectiveness. In other words:
Achieving a goal is more important than creating a perfect relationship between input and output.
This compromise comes with a price. Because this compromise, which focuses on effectiveness instead of efficiency, brings with it a paradigm shift: away from the efficiency of horizontal – i.e. layer-oriented – development and towards the effectiveness of vertical – i.e. feature-oriented – development.
And the first to pay this price are the developers, who not only have to relearn large parts of their craft, but who also have to face ever-increasing demands.
By the way, this is a circumstance that project managers often completely ignore when putting together their teams. Now developers have to know the vision of the whole project at least roughly, they have to think a feature end-to-end, they have to be able to develop it through all layers and, at the same time, keep an eye on the architecture of future features, so that later they don’t have to do too much refactoring.
Untrained teams will often quickly reach their limits. It takes a few Sprints to bring teams up to this challenge.
But quite a few managers and project managers lack the patience for this. The method of choice here is intensive prototyping.
Finally, I would like to put an end to a widespread misunderstanding
Scrum is often said to be much more flexible, more talk and less documentation, that we have flat hierarchies, or none at all.
I.e., achieving a goal is more important than creating a perfect relationship between input and output.
This may be true. What is fatal, however, is that this often creates the impression of a certain “laissez faire” that can be maintained in Scrum projects. That’ s completely wrong!
Scrum requires a maximum of discipline.
Being a compromise in a not perfect world, Scrum is already heavily burdened and therefore a fragile entity. This method cannot handle even more compromises when using Scrum, the stock of compromises was already used up during setup. The rest has to be much more stringent and precise, but above all more disciplined.
