If you’re reading this blog, chances are you’ve decided to adopt Scrum, congratulations! But after all of that careful consideration, where should you start? Changing the way your organization has been working for years is challenging, which makes starting the change very difficult.

Ultimately, the change to Scrum will have some impact on everything and everybody within your organization. Everyone will feel the burden or the success as you tackle digital innovation projects. Ideally, all software teams should follow the same methodology, but changing how the organization works overnight is a huge risk and a recipe for failure. For example, any traditional development team which relies on upfront design will have trouble working with an Agile/Scrum-oriented team.

With this in mind, it’s important to make the change to Scrum as fluent as possible. Changing the way products are delivered isn’t something that you should expect to do in a couple of weeks; this could take months or years to truly change how your organization works and gain the benefits from it. And even after adopting Scrum, expect your organization to continuously adjust to ensure optimal team collaboration.

In this blog series, I’ll go through some of the key aspects of adopting Scrum and provide ideas to help guide you through to a successful adoption.

Making the change to Scrum

You probably already have a well-oiled project organization. And this group will likely include development teams, a project manager, and Subject Matter Experts from the business. Let’s call these people the Scrum Team. In my next blog post, I’ll go into more detail on setting up a proper Agile team; but for now, let’s call everyone else a Stakeholder.

Everybody, including all Stakeholders, needs to know what is expected from the change to Scrum. While some may already know about the Scrum methodology, all team members and Stakeholders need to have the same understanding and expectations when starting development of a new product. Here are a few tips to ensure that everyone has the same information.

1. Educate Everybody. In order to change the way you work, everybody involved with the development of the product needs to have the same understanding of the new process. This includes everybody directly involved with the development, but also the business users and management team.

The best way to achieve this is to have everybody attend a Scrum course. This teaches why it is important to run the processes the way Scrum describes. There are hundreds of sites explaining how the Scrum method works, but to truly understand the reasoning behind all Scrum activities, you need more personal instruction. This allows everybody to start off with the same understanding of the process.

2. Focus Communications. In order to drive real change within your organization, you need a focused approach to sharing this new process. And that approach needs to come from all angles, with encouragement from the bottom and the top executive team. Here’s a quick overview to explain why:

A bottom-up approach is promoted by a development team who adopts Scrum and slowly spreads it across the organization. The team starts off excited, but can quickly become distracted. After the first few sprints, management starts asking the team about requirements, progress reports, estimated delivery days, etc. These are all traditional KPIs, which can become cumbersome to a Scrum team. The team can easily be distracted by the rest of the organization (and their requests), forcing them to resort back to a Waterfall approach to accommodate those requests.


A team can’t fully adopt Scrum without getting the authority and protection from management. Nor can management expect the traditional status reports, since progress in an Agile method isn’t measured the same way. For example, it’s impossible to tell the project completion percentage, since we don’t know exactly what the finished product will be.

Alternatively, a top-down approach is driven by Management and forces the organization to change. This is something that can create a lot of resistance.


A Scrum team is supposed to be a self-organizing team, people will only take up that extra responsibility if they feel safe and trusted enough to do so.
Ordering a team to organize themselves seems contradictive and is likely to work counterproductive.

In order to start a successful organizational change, you need to approach the change from both sides. Management should initiate an open discussion with the potential team members. And ideally, the team members should volunteer to play a role in making the change happen. Most developers like to be in control of their own work anyway. To successfully adopt Scrum, the team needs to be willing to make the change and take ownership, and management needs to work with the team to show them their support instead of trying to control the process. This means that management also needs to set the right priorities and limit distractions.

3. Set Expectations. Everyone involved with the product development should know what they can expect from the development team and what the team expects of them. This doesn’t just include the developers, but all Stakeholders! 

While developing the product every requirement, meeting, discussion, or report will be slightly different from what has been done for years. This makes it important that everybody involved knows, before starting the product development, what to expect and what is expected of them. Without having the proper expectations and somebody to help to set these expectations people easily fall back to what is familiar, and you will end up with a scrum-fall project.

In a traditional Waterfall project, most requirements are scoped out in advance through many hours of interviews until everyone is satisfied with the details in the scope document. A common misunderstanding is that adopting Scrum replaces these types of sessions. This is not the case; Scrum only makes the process more efficient and allows for improvement while exploring the requirements. Every conversation that is being held in a Waterfall method will still need to be held with Scrum, it will just be in a different form.

Instead of having many scheduled interviews the Stakeholders (business users) will now work continuously with the product owner and the development team to identify and improve the requirements through small collaborative sessions throughout the development of the product.

It might not be the most important action in here, but still, something to keep in mind for the first products you’ll start developing: keep it simple! There many different types of products that you can choose to start your journey. But try and keep it simple for your first process, make the change to standard Scrum at least for one product successfully and learn from that experience. After gaining some experience it can be worth to look at additional variations of Scrum such as LeSS[1], SAFe[2], or DaD.

The road to an agile organization will be littered with challenges you’ll have to overcome, but with the four key ingredients: Education, a Willing Team, Supportive Management, and Reasonable Expectations, you are already off to a great start. Hopefully, this post helps kick off your move to the Scrum methodology and an agile development approach. While doing that there are many other things we’ll need to do, such as identifying a good team structure, finding the Product Owner, and running all the right meetings as efficiently as possible. Look out for my next blog post where I’ll cover more on this.

[1] http://less.works/
[2] https://www.scaledagileframework.com/