How can I measure (evaluate) the benefits of switching from Waterfall to SCRUM?

Question

Agile

In our company, all development is carried out according to the classic Waterfall - project teams, Gantt charts, task assessment in person days, documentation before the start of development, etc. etc. There are many tasks, there are no typical ones. There is a strong desire to transfer development to SCRUM, for which we are launching a pilot project on this framework, to see how it goes. We need to understand how we can evaluate the result and present it to management. The management of the organization agrees on the transition of all development to SCRUM, only after we can show the benefits in numbers - cost reduction, by increasing the development speed or something else. An important point is that this must be done in comparison with the current process. Here's how to do it, it's not entirely clear - what and how to measure? I will be grateful,

Answer 1

> There are many tasks, there are no typical ones.
if the tasks are unique, then all your development plans are a hoax.
> the transition of the entire development to SCRUM, only after we can show the benefits in numbers,
your thinking is not yet ready to switch to flexible methodologies.
A lot of things don't count in numbers.
You are offered to calculate the following in numbers: go to the store guided by the area or go to the store with your eyes closed on the map that you drew at home, while you have never gone to the store before and don’t even know if it is there.
According to the plan, both here and there you should equally effectively reach, but in reality, with your eyes closed, after 15 minutes of the way a car will knock you down, or you will simply break your neck by going in the wrong direction.
========
The bottom line is that for 2 years of planned development, do not come to the garbage pit instead of the store.
Trying to plan everything and calculate the result of the work is again from a waterfall, you live in a non-deterministic world in which you can NOT calculate and control everything around, you either accept it and start thinking and acting differently (based on feedback), or you continue to study eyewash.
P.S.
business does not like uncertainty, they love guarantees and accurate answers - therefore, the customer will still DEMAND that they rub game into his glasses, regarding the volume of work and deadlines, this is the main problem of introducing flexible methodologies, the habit and unwillingness of people to think differently .

Answer 2

When scrum works -
1) Early prototyping (MVP)
2) Frequent releases (often a sprint lasts two weeks and a release at the end) - this makes it possible to get early feedback and stop developing unnecessary features, or quickly change direction if the requirements for a feature have changed.
3) Due to the two-week pulse, developers can be less stressed and work more efficiently, but this is individual.
Look and calculate whether the work was thrown into the basket due to changed requirements, the deadlines were screwed up because of this or not, what was the impact on adjacent teams, and you can determine the profit.
Sometimes, before the Proof of Concept is rolled out, it’s hard to decide what to roll out to the release, and then at the first stage Scrum is replaced with Kanban.

Answer 3

Hire or train your professional Scrum Master first. Without it, you are unlikely to benefit. Fragmentary knowledge in Scrum and the absence of a person who knows it well will only exacerbate the problems. If you ask such a question, then most likely you don’t have such a person, and your scrum will dry up and formally be limited to only the sprint board and daily roll calls, there will not even be an effective management there.
Scrum is a much more difficult area than programming, there are several levels of certification https://www.scrum.org/.
I would draw an analogy like this, programming is chess - a game with complete information, you are required to have a knowledge base on the subject and logic.
That scrum is poker - a game with incomplete information, where the theory of probability and psychology will be added to the knowledge of the subject and logic.