How to get a head start with Scrum

Scrum is easy to understand, yet difficult to master. The Scrum Guide says so and it's true. If you have worked with Scrum in your organization you probably recognize it also. It's not difficult to start with Scrum. But often it does not take long for the first organizational bump in the road. Or the organization is not ready to receive a "Done" increment every couple of weeks. And instead of adapting to the continuous value of product coming from the Scrum Team, the organization starts resisting the product or the team delivering it.

It's just one of the examples that can occur when you're moving from a plan-driven approach to a continuous value delivery and empirical approach like Scrum.

So when is the right time to start? What conditions need to be in place?

The good thing about Scrum is that the framework is lightweight and therefor it's not difficult to start. However, not considering anything and just giving it a go may not be the approach that fits every organization. Often, if the organization is heavily regulated or has a lot of processes and rules in place, doing experiments is much harder than in a Startup environment, where experiments are the norm. The difficulty with a Startup however is often that when it grows, it needs more structure, which does not fit the culture.

So how should we approach this? When is your organization ready to start with Scrum?

In this article I would like to give you some practical tips for starting with Scrum in your organization. What pitfalls should you be aware of and are there things that you can prevent upfront to make sure you get to a valuable increment after the first few weeks?

Consider the company culture

The first thing to keep in mind is, that every organization is different. Nothing is the same. Different departments, people, roles, working agreements, housing situation, collaborative structures etc. All of which together determine the company culture. So think of what is important to your company? Is it a Startup mentality? Are experiments allowed? Or do people feel safe within their processes and tools? Where are you on that scale? There is no right or wrong here, but it can determine the approach you use to introduce Scrum to an organization.

For instance, if a company has a focus on controlling risk and heavily weighs on processes, use an approach that fits; emphasize that Scrum reduces risk by delivering fast, shortening the feedback loop to gain control and be able to adjust to the situation.

If your organization has a culture that values entrepreneurship, focus on the self-organizing element of the Development Team and the freedom it has to deliver a high quality product.

This is something that we can call culture or organization sensitive. Since company culture is a complex environment in itself, it will need an empirical approach just as much. For instance Lean Change Management or Scrum.

Get to DONE as fast as you can

I have seen teams struggle for year on end without delivering a "Done" increment at the end of the Sprint. This may happen at first, but be aware that not being able to deliver a "Done" increment can be a sign of organizational impediments. In some cases, the Scrum Team will try to resolve these; which in essence is a good thing, but it can become frustrating when company dependencies won't budge. Scrum will get the blame real fast.

The Scrum Guide tells us that if there is Sprint Goal becomes obsolete, the Product Owner can decide to cancel the Sprint. But how often does that happen?

Cancelling the Sprint can be a desperate measure, but it might be needed to create transparency on these organizational impediments that the Scrum Team is unable to resolve.

Find a good Product Owner

Having a good Product Owner with the right competencies can be difficult, but very important. Having the courage to stop a Scrum Team that has already spend 500k without delivering any product is not easy, but HARD. This is not something that is to be taken lightly.

Finding a good Product Owner is tricky advise. Because, what is a good Product Owner? Can it be measured? Should you look for a certain skill set?

I can image there are other blog posts out there about what a good Product Owner should look like. I would advise you to read Geoff Watts' book "Product Mastery". There you will everything there is to know about good Product Owner-ship.

To get you started, make sure the Product Owner:

• Has a product and customer focus;
• Is mandated to decide on the product roadmap;
• Is made responsible for the outcome of the product.

The roles of Scrum are important

Scrum is not Scrum if there is no Product Owner, if there is not Scrum Master and you are nowhere without a cross functional Development Team.

Somehow we find it convenient to combine the role of the Scrum Master and the Product Owner. Don't. They're separated for a reason.

The Development Team is not called a C#-team or test-team for a reason. People need to be collaborating on the work that has potentially the most valuable outcome. This is hard to achieve and the Scrum Master is there to coach the team and the organization to the level that they understand this and see the value it will bring to the organization and its customers.

The Scrum Master role is sometimes left out or combined with other roles. Maybe the output of the Scrum Master is less visible and often indirect. The most successful Scrum Masters I've have seen were always there in the background making sure the Development Team could deliver a constant flow of valuable output. That means taking a step back and so that the Development Team gets the credit.

So make sure you are aware of the Scrum Roles, their importance and synergy between the roles. All these roles are professional roles. Skills need to be developed continuously. Make sure there is room for this improvement.

Rules are there for a reason

We don't change the rules of the game just because we're losing. That's called cheating. There is a lot of cheating going on in organizations using Scrum. Often not because of the rules of Scrum (remember, Scrum is lightweight), but because we don't like the transparency it creates.

I started out with the statement that Scrum is easy to understand and hard to master. And because it is hard to master, many organizations change the rules of the game hoping they will still be able to win. Often the result being the opposite.

I tell my kids they learn to be a better player by losing many games. They learn and grow and after a couple of years, the game has grown on them and they master it. They still lose every now and then, but we get better because of it.

However, rules are there for a reason. This goes for Scrum most of all. If you don't understand the rules, don't change them, but try to understand why the rule is there. Understanding the reason behind a rule can help you optimize your performance of the game!

Concrete example: leaving out the Sprint Review because there are no stakeholders or customers attending. This heavily affects your inspection of the product and makes changes you make based on assumptions. Scrum apparently creates transparency on the fact that your stakeholders are not involved (or maybe even interested) in what you are doing. You can then decide to change Scrum and skip the Sprint Review or you can work on solving the problem with your customers/stakeholders.

Conclusion

When people ask what is needed to start using Scrum, the answer usually is: inspect and adapt as you go. However, if you want to increase your chances of success, consider:

• Decide on an approach that fits you company culture;
• Make sure you create a potentially shippable increment as soon as possible;
• Think about who is fit for the Product Owner role, don't underestimate (or underpay) this role;
• It's important to have a Scrum Master and a Product Owner, not being the same person;
• Respect the rules of Scrum and try to improve your game.

Paying attention to these things can help you get a head start in delivering value sooner for your customers with Scrum.