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!

Reference wall pitfall

Let's summon some things up from the previous post on the reference wall. When you finished a user story, you put this on the reference wall confirm the story points it has taken you to finish completely. When you miss estimated the story, you estimate again and place it at the right spot. So far so good.

Killing

Now, it's rather easy to estimate new stories this way. When you agree that the story is kind of similar to one of the stories on your reference wall, you can estimate the new story real fast. But... There is a downside.

You probably didn't think about the fact that your creativity isn't triggered this way. I mean, if you recognize the reference stories as building blocks, you become less challenged. Let me elaborate on this.

At a certain point, almost all of the features customers ever requested, are on that wall. That means that every story becomes business as usual. You have entered a common way of working. In other words, your process is fixed and you are killing creativity.

What to do about it?

I don't know what to do about it, so that leaves you an inconclusive blog post. (I wonder if I have ever been inconclusive... I think not)

Reference Wall

Last month, I've seen something remarkable. These are the moments, things occur to me, which are so obvious, that I could not have missed that, but I did! It's how the magic happens in teams.

What am I talking about? 

You know planning poker, do you? If you don't, it's giving an estimation on how much effort you think you have to put into one user story to deliver it properly.
This team, this post is based on, is so determined to Scrum, that they swore, they never go back to 'the old way' of working. Some background to it: this company was putting people to projects and now it's the other way around. They say: 'If management thinks Scrum is failing and they want to back to the former way of working, I'll be off to an other company, I swear!'

This team is so enthusiastic, that it is inevitable that it comes up with beautiful things. And of course, I make good use of it, to feed my blog and share it with you. It's called a Reference Wall.

If you take a look at it, it's full of user stories which are formally estimated. They put all of the done user stories from out the sprint, right onto this wall, but only if these stories appeal enough to ones imagination. And the most wonderful thing about this wall is that it helps estimation a new user story a lot! Refinements are an easy way of working now.
Thanks guys!