Fact: Scrum is not a project methodology

Posted by Linus Dalin on March 14, 2010

Let’s start with the first and single most important misconception around scrum in software development. This is used due to misunderstanding of the scrum methodology but also because of more fundamental misconceptions of projects and the use of terms therein.

Scrum is NOT a project methodology, it is a development framework!

A project is a defined scope with a goal set to be completed during a specific timeframe. It has requirements on delivery precision and communication of progress as well as result.

Scrum does not replace project methodologies. If we replace existing measurements and project reporting models, this can lead to problems in the rest of the organization when time estimates and milestones are lost. After all, software development is more than the development department. We need to use scrum to make better estimates and communicate it better, but we may still need other communication paths to satisfy other stakeholders.

For release planning in a typical organization, the time it takes to actually perform tasks is not the critical issue in a calendar perspective (i.e. when things can be ready). What is important is when we actually can get things started.

One way of viewing the scrum teams are like small factories or production units. These units make up the core of the development capacity. These production units are managed by the scrum masters that constantly fine-tune and improve them. As a product owner, I divide the tasks among them, prioritize monitor and work with the tasks and verify the quality coming out on the other side. If I have different teams I can steer the projects to the most logical group to undertake the mission.

Stable teams is one of the most important aspect in improving the efficiency of development but is absolutely essential for getting predictability. For a good organization it takes approximately 3-4 sprints to get a stable velocity and for less experienced teams and product owners even more. If the teams or the tasks tend to change, this will probably never happen and we will never get any estimates.

So the resulting conclusion from this is that when a project shall start, there is already a team (or multiple teams) that can take on the mission.

Scrum Teams shall out-scope the projects.

Scrum Teams shall out-scope the projects!

Now we can continue with the next costly mistake viewing Scrum:Is scrum really a development issue?

1. Fact: Scrum is not a project methodology
2. Fact: Scrum is not a development issue
3. Big Question: Where will the improvement come from?
4. Fact: Scrum does not remove all problems in an organization.
5. Myth: The Scrum Master is key
6. Myth: Scrum is more important than common sense