This article deals with a reality that is, sadly, not fair in many cases. It discusses the question of how organizations can organize a Scrum process without wasting most of their time and helplessly surrendering themselves to so-called or self-proclaimed Scrum experts with their mantra of “The full facts have yet to be established”.

The game usually starts even before the project begins in a process step, let’s call it demand management.

A change advisory board has to deal with a large number of project proposals, which are usually described at a high level and prioritized, but only rarely come with an estimate.
And of course there is time pressure.

If this seems familiar to you, read on. If you’ve never experienced this before, you’d rather read a different story – a beautiful one.

The mantra of many Scrum Masters is this: “We do Scrum, we don’t give an estimate”. That is why Scrum is accused of being closer to communism than to reality.

Scrum is not necessarily a project management method, but rather an implementation method (like Waterfall in the past), yet it is directly related to the project and all of its aspects.

Many Scrum experts have settled comfortably in the method, gained some wisdom and simply ignored important questions – apparently, these are not important enough for many Scrum experts to answer.

You can be a Scrum expert if you correctly answered eighty questions at Scrum.org in one hour. Then you know what a Scrum team consists of, how many minutes a daily can last, what a timebox is, that the team is above everything and that Scrum attaches importance to transparency.

What you don’t know is, of course, what a project will cost and when it will be finished.

Here, it will be pointed out immediately that a backlog potentially lives forever and is constantly updated and that, in the beginning, a handful of stories are enough to start the development – which often enough also corresponds to reality and is absolutely true and meaningful in my eyes.

So why this article?

Because Scrum as a methodology is described quite comprehensively, but that is not the whole truth.

Because the truth – from a philosophical point of view – also knows a relation to reality. And reality often looks like this:

Scrum process ping-pong

The organization would now like to opt for Scrum as a methodology – in many cases it has no other choice – because the detailed specification of a classic waterfall is missing due to time and/or complexity constraints.

It will now ask itself how the Scrum project should be budgeted and controlled before the project proposal can be approved. This is where an amusing or frustrating (depends on the perspective) game of ping pong starts.

IT is supposed to estimate the project, but they can’t, because the requirements are not well  described or incomplete (in most cases, it is both). They return it to the technical department. They, in turn, can’t describe it any better, because they lack the IT expertise; after all, they are supposed to describe a product and not a business process.

The match goes back and forth for a while until the players lose interest. A draw. What to do now?

Of course, both are right. IT doesn’t have a crystal ball and now they are protected by the Scrum process or by the Scrum experts and their mantra.

The first mistake which is often made here is that the fact that you cannot estimate precisely at the beginning is being generalized.

Because the fact that at the beginning of a project I cannot accurately estimate the effort and the duration does not necessarily mean that this has to remain so for a long time.

The second mistake lies in a misinterpretation or overemphasis of Scrum as a value creation instrument.

First of all, Scrum is a risk management method

Yes, you did read that right. Software development is a complex and complicated matter. Even more so if you try to develop breathtaking software of the highest complexity without an exact specification.

Teams that accomplish this do incredible things. It’s like a tightrope act on a skyscraper without a net.  Scrum tries to handle this risk with everything it has. And that includes – and this is unfortunately often overlooked – the development rhythm.

Scrum introduces vertical, feature-oriented development – unlike a Waterfall, where the development is more horizontal and layer-oriented.

Let’s look at the relationship between the two methods from a different perspective: the value creation perspective.

Waterfall, which consists of the phases specification, implementation, verification (test), and documentation, creates value only in the implementation phase. Of course, the specification is a prerequisite for the value creation, and the verification and documentation set the sustainability of the value creation, but the value creation itself takes place only during the implementation.

This is completely different in Scrum. Here we try to extend the value creation period to a maximum. Start extremely early (Sprint 1) and – through the use of test automation, continuous integration up to release on demand – stop feature development only shortly before release. This, too, is clearly part of a risk management strategy.

Creating permanent added value, i.e. creating a constantly countable credit side, minimizes the risk.

Nevertheless, one of the serious mistakes that are unfortunately made is that often a chronological development (as in Waterfall) takes place again. So first the start page with the login is developed and then they slowly move on to the next step.

Like an artist who walks over a wire rope and realizes only after a third of the way that the rope is not properly tied at the other end, many teams arrive far too late at the architectural challenges when they operate this way. A safe way back is impossible.

What Scrum – if understood as a risk management method – actually corresponds to is not the phrase “Business Value first”, but “Risk first”.

Scrum process: Risk first

First, in short sprints with some proof-of-concepts, prototypes or whatever, we try to identify and eliminate the risks. This is also added value, but follows different principles. 

And now we incorporate this insight into project management so that we can achieve good project controlling in just a few steps. And this is how it works:First, in short sprints with some proof-of-concepts, prototypes or whatever, we try to identify and eliminate the risks. This is also added value, but follows different principles. 

1. First of all, the project application in the Demand Tunnel is estimated roughly

First, we recommend t-shirt sizes that correspond to a certain range (e.g. S <= 50 days, M up to 200 days, it doesn’t matter).  Of course Story Points and Fibonacci can also be used for this if your CAB knows this.  This rough estimate is only used to determine an initial budget. The probability of occurrence should be 50%, which is anything but accurate.

1. Then we define a first phase up to the point of no return

This is the point up to which you can cancel or restart a project relatively safely without losing too much money. In my opinion, this point should only account for a maximum of 10% of the initially planned project duration. In this phase, you work according to the “risk first” method, i.e. you do everything you can to assess and eliminate your risks. For after this phase you should gain approx. 80% certainty about the project. This phase is not about generating any business value, it’s only about gaining certainty about the feasibility of the project.

1. In the third phase, you create the MVP (minimum viable product)

I.e. the core process of the application; the smaller the definition, the better. In this phase, only business value is created. Code optimization, sustainable quality, pixel-precise UI, fancy features – all of these are secondary. After this phase, you should occupy a market before someone else does. Winning prizes with this product is as unlikely as it is desirable. You’re there, that’s enough. In this phase you should increase the security from 80% to 95% as early as possible. Since your backlog will, in fact, never end, you will never get closer to 100%. But usually you can live comfortably with this uncertainty.

1. In the fourth phase, i.e. after the MVP, you let the product mature

You will have received a lot of feedback about the MVP. This means that you won’t burn money senselessly when the product is mature, but you can optimize exactly what your customers really need.

This rhythm provides organizations with security early on, even though there is quite a lot of uncertainty at the very beginning.

This cannot be avoided, but it should disappear quickly.

If risks can be controlled rapidly with this method, organizations are also more willing to take them on at the beginning.