Scrum is a popular take on agile software development. Scrum has become for many, the de-facto approach to agile software project management. That is great, but does scrum work?

I’ve done Scrum, and so I have some opinions on this.

What is Scrum?

Many other articles explain Scrum in complex terms. Let me boil it down to the core elements of Scrum.

There cornerstones to making Scrum work effectively - regular iterations, sprint planning meetings, daily stand ups, and retrospectives. There are key roles - product owner, scrum master, team members, and stakeholders/customers.

Scrum Essentials

Let’s define each of those things.

Scrum works in iterations. That means one to four week “sprints”.

A sprint is a time box for an iteration. Sprints are regular time intervals to create a cadence that product owners and stakeholders can depend on.

Sprint planning meetings are when you plan the work for the next iteration. The goal is to plan work that can be accomplished by the team during that sprint.

Daily stand ups are quick daily check-ins with the team. Everyone meets and does a short update of what they did, what they are doing next, and if they have any blockers. They should last no more than 15 minutes.

Retrospectives are a meeting after a sprint to discuss what worked well, what didn’t work well, and what to improve. It’s the most important part of Scrum and it is often the part teams ignore.

When Scrum fails, it fails at the retrospective.

Scrum Roles

Now let’s talk roles.

The Product Owner is responsible for making sure the team is building the right thing. The Product Owner interfaces with customers and the team as an intermediary.

Scrum Master is someone who facilitates communication in daily stand ups, kickoff meetings, and retrospectives. The role should rotate, but instead it is often given all the traditional duties of a project manager.

Team members are people doing the work to build the project. Scrum teams are cross functional. Ideally you have developers, designers, support, marketing or sales, involved in the process.

Stakeholders or customers are people who use the product. They are the ones who get value from what is being built. Their opinions and needs are critical to the long term success of any business.

Real Scrum Experiences

The day to day experience of Scrum is different for each team. People interpret Scrum very differently depending on how they see the world.

I see Scrum as a framework to manage a team and project. It gives you a way to approach common problems, but it doesn’t solve them for you. Others see Scrum as a specific prescription to solve all of your team’s problems.

Every person has a different Scrum experience.

Define Agile vs. Scrum

Scrum exists as part of this idea of agile software development. Agile software development was born out of The Agile Manifesto. Scrum shares many of those principles.

When teams “go agile” a lot of times they mean they are using Scrum. At the same time, if you are using Scrum, you might think agile means Scrum. It doesn’t.

To make things even more confusing, many teams say they are agile or Scrum and they aren’t.

This confusion makes it critical to really understand the difference between Agile, Scrum, Kanban, and so on.

I believe Scrum is a process revolving around sprint iterations with a sprint planning meeting, daily stand ups, and a retrospective meeting at the end.

The rest is open for discussion as to what makes the most sense. Non core elements can change over time.

Anything outside of that model is either a different flavor or agile or not agile at all.

Scrum Communication

Scrum lives or dies with team commnication. In my experience Scrum falls apart when teams stop having honest communication about a project.

Scrum works best when you have truly self managed teams without a true project manager who is the manager of a team. Some of the planning does require a project manager type role, but when the project manager or product owner is the boss of the team, communication suffers.

Here is how it starts…

Before a planning meeting, the project manager might decide that a certain pile of features needs to get done. This already breaks the Scrum process.

In Scrum, the team is supposed to plan and estimate work for the next sprint. If the manager already has a target it sets up a bad situation.

Next, the project manager will lay out his goals for the next sprint. If these goals don’t match reality, there will be friction in the estimating process.

What happens is the team members will try to make an accurate estimate. Then, the manager will question and reduce the estimate, even if it’s unfeasible.

Iterations like this go bad. Work doesn’t get done well. The team gets burnt out. Eventually people start seeking employment elsewhere.

To make matters worse, retrospectives are not common. So, instead of stopping this toxic behavior by communicating, the problems pile up.

Project estimation is hard and few project managers have the guts to stand up to a client or their bosses on behalf of the team. This makes good communication paramount to the success of Scrum.

Good communication means honest estimates, honest daily stand ups, and an honest retrospective after each sprint.

Scrum Process Isn’t Static

If you want Scrum to work for your team, it can’t be the Scrum that you see advertised everywhere. The most successful Scrum teams learn and evolve the process every sprint. That is why you have to have retrospectives every sprint.

Continuous learning is the most powerful feature of Scrum if used properly.

A good retrospective is compound interest for your team’s productivity.

If you know anything about compound interest you know that it’s determined by two numbers - compound rate and compound frequency. The frequency often has a bigger impact than the rate.

Would you rather have a 50% gain in productivity once a year or a 2% gain in productivity every two weeks?

The correct answer is 2% every two weeks. The compounding effect makes it a 67% gain vs. a 50% gain.

That is the power of learning and improving the process after each sprint. Over a long period of time you get dramatic improvements with just small tweaks to the process.

The teams that learn every sprint and make changes to their process are the teams that see a huge benefit to Scrum.

So, does Scrum work?

I think Scrum is a good concept. But, I haven’t seen it work with many teams because of the inherent flaws of human behavior and work organization.

Scrum requires honest communication and a strong feedback loop from both the customer but also the team. A lot of managers can’t handle that because they feel it undermines their authority or position.

In the long term Scrum is no more beneficial for those teams than waterfall is. If anything, Scrum becomes more stressful with constant looming deadlines.

I’ve been on one team that did Scrum right. It hit the core elements hard. It improved the process every sprint. It’s the model I draw inspiration from when I think about what agile should be about.

Other teams haven’t gone as well. At some point there is a temptation to ditch Scrum on a deadline. Then deadlines become constant and Scrum isn’t sustained. A boss will want their own way instead of listening to the team or being honest with a client.

If you or your team is planning on doing Scrum, you need to understand what your communication and team culture is.

Are you willing to commit to the communication side of Scrum in an honest way? Are you going to learn from each sprint with a retrospective?

If that’s not you, then don’t do Scrum. You are better off finding a system that fits your culture.

If that is you, then Scrum could be a good option. I would recommend starting Scrum by following the default Scrum structure first.

Spend at least the first few sprints just getting good at the tempo of Scrum. Let your retrospectives focus on how to get better at the new process before changing the process too much.

When Scrum works it can be a great working experience for everyone involved. It requires a lot of effort, learning, and practice to make Scrum work. You will have failure along the way. Learn from that failure and get better at your craft.

Scrum does work, but it doesn’t work for everyone all the time. Make sure Scrum is a good fit for your team before jumping in.


P.S. Have you subscribed to Code Career Genius yet?