Why Scrum?

When you ask an IT company: 'Why do you work with Scrum?'. Most likely you will get an comparison with an older variant developing process like Waterfall. Then I say: 'What will that help you, if you don't know what waterfall exactly is?' So I'll try to explain why we work with Scrum in a different way.

Value

Let's assume that you, as a customer, like to have a valuable product. That means that you don’t want a website of application just for fun! You want the best out of your money. With other words: you obviously want the most value. And we agree on that completely! But that leaves us the question: what exactly is value?

Say you want to have 3 different features and also you have given them these priorities:

• Feature 1: most important
• Feature 2: second important
• Feature 3: would be nice, but lowest priority

The team who will work on those features brainstormed about these features and come with the following striking conclusions:

• Feature 1: is difficult to implement and so it’s tricky
• Feature 2: quite easy to implement
• Feature 3: can be implemented without any problems, but leaves the customer with good advantages, from which the company will benefit immediately!

So, if you think about priorities now, you’ll see that you can twist them around. If you agree on developing the third feature, the team maybe discovers a neat extra feature which will give you even more value. That brings us to feature 4. And what is the rank of feature 4?

Be realistic and embrace chances

This scenario is not odd. On the contrary, this is always reality, let's not be mysterious or unfair about it. Prioritising values is a living process! So, if you sign a contract and pinned down the features and specs, most likely you burn your fingers. Therefore you should acknowledge the fact that we find it unfortunate that we cannot be flexible when we have to.

Capturing your wishes in an early stage of the process and have them written in stone sounds like firmness and trust, but is fact a lie. It’s often seen in old, large companies. Project leaders get a budget from their superior and therefore have to account for it. And it can be very hard justifying yourself with saying: ‘Well, in general we know what to build, but we don’t know for sure exactly what it will become at the end of the track...’

Plus, if you do have pointed out exactly what the application will look like and we find out during the process that the goal is not achievable, we will rush; we will rush like a rabbit despite everything, whether the features have value or not. And when we push ourselves because of the pressure, everyone is getting Inflammable and irritated. First of all, this results in a lack of concentration, so more bugs will be introduced, secondly and most importantly, we get a decrease of creativity. That is why we find it most important to create a healthy environment by having a full collaboration, so that we can respond to the opportunities and uncertainties that spontaneously arise (because they always appear, no matter what!).

Unpredictability

And that is the main reason why we do Scrum. This methodology offers the opportunity to respond to opportunities and uncertainties. Maybe you think: ‘You have years of experience, how can you have such a lot uncertainties?

For a couple of hundred years you died in about the same environment as you were born. But if you were born in the 70’s, almost nobody had a personal computer, compared to now, it’s almost unthinkable. For a decade ago, it was not common to have a smartphone. In other words, the world of technology is changing exponentially and we are obligated to keep up with it. That means, we have to renew constantly. And renewing comes with uncertainties, but most of all it offers many, many chances!

Treat chances as business as usual. Better to embrace uncertainties than to stupidly ignore them.

Enthusiastic about Scrum

That’s why we are enthusiastic about Scrum. We are building the application together. Together we have to step aside continuously and evaluate upcoming chances on the way. Know for sure that developers want to create the best they can! So please, let them do it the best they think they can!

Look out for Agility!

I don't know where to begin, so I'll start to tell you that it is for a fact that Scrum Masters often are pulling their hair out. Why is my team slowing down? Why is there a decrease in velocity? What happened? Is scrum failing? Is Agility failing? Am I failing?

We have been told that agility is about making a move and then look back if this move was a correct one. If not, take another step and try again. Everybody knows that this move is not just a random move, because we think things through. What if I told you that's not enough? You might end up in some situation you don't want to be in...

So, how come that I tell you that agility is not the way to work?

It's pretty obvious. If you don't take the long term into account, you can easily walk into a trap. Let me explain with a common scenario. A team is working on a software product. They are delivering feature by feature. But what they don't think of is creating automated tests. Also they don't think of architecture. Did you heard about the S.O.L.I.D. principles? The Scrum Master is not familiar with that and he thinks that testing and clean code is overrated. And in the beginning it's going nice and steady, nothing to worry about! But after a few months some bugs appear and functionality comes with different business rules. It's not a rare scenario that your product is going to fail because of changes made in future sprints. Expanding features is harder than everyone thought it would be. So, there you go! Velocity is going down.

What I want to explain is that Agility is about short term decisions and learning from them. But what you really need is a long term vision next to Agility and use them side by side. Be sure that you deliver with such quality that you are absolutely sure that your architecture is ready for extension. Only then you succeed in Agility and Scrum!