The Insufficiency of Scrum

Scrum is often promoted and adopted as a holistic software development methodology. It simply isn't. It doesn't help us manage our project goals, and it encourages us to build software that grows increasingly hard to change. Scrum is great at what it is intended to do, but it only provides a subset of the Agile practices we need to succeed.

Scrum fails to acknowledge the entire scope of software development. To demonstrate this, I'm going to break down the levels of scope the same way Scrum does.

1. Project: This is about deciding what the project goals are and steering towards those goals.

2. Milestone: This is a sub-interval of the overall project in which part of the project is delivered.

3. Feature: A change to the software that has value to the client. This is often described as a requirement or user story. Features are usually intended to fit within a single Milestone.

Scrum does a great job of addressing the Milestone level of scope but mostly punts on the other levels.

Project

At the project level, Scrum calls for a product backlog, but doesn't describe how to create or manage the backlog. The benefit of this is that it helps projects transition from the expensive Big Design Up Front of Waterfall. The major drawback is that many teams feel they can change the direction of the product without cost, because Scrum largely ignores that cost.

Milestone (Sprint)

This is where the heart and soul of Scrum lives. It teaches teams good habits with regard to dynamic steering and continuous improvement.

Feature (User Story)

This is where Scrum breaks down. It focuses entirely on finishing the user story (as defined by the Product Owner at the beginning of the Sprint). While this is a good contrast to development that is focused entirely on creating 'systems' as defined by programmers, it does not do a good job of honoring the complexity of software development. In particular, it doesn't account for the cost of removing duplication in code, data, or concepts. This leads to 'code debt', which means future features will be more expensive to implement than they need to be.

Dissonance

Scrum tells us that we can steer projects as though they were speed boats while allowing us to turn the project into a barge. At the project level, we are told that changing our project design is as easy as changing the backlog. At the feature level, Scrum encourages practices that make changes to the project become more expensive as each feature is completed.

The Story

Some well intentioned person in product management, looking for ways to improve their process, discovers Scrum. It is the answer to their prayers; no more late projects that don't perform the way the client expects!

Three of the managers from the team go to a couple of days of classes and become Certified Scrum Masters. Now they know what they're doing! As the new project is ramping up, they teach everyone on the team how Daily Scrums, Sprint Reviews,and Sprint Planning meetings all work and everyone starts doing them.

Everything goes great: valuable features get finished, the product backlog changes without a hiccup, and the team spends much less time planning and writing documenting while spending more time making progress.

Some time passes...

Things are a little tougher now. Programmers occasional mumble about re-factoring, engine work, etc. They ask to work on things that are clearly not user stories. Some features start slipping, or are perceived as 'hard' where just a month ago they would have been easy.

More time passes...

Things are definitely worse now. Most estimates are higher than the Product Owner expects. People are falling back into their old development patterns (e.g. wanting to write a technical design before they will make an estimate). Bug counts are increasing. What used to be easy is now hard.

The Advice

Ensure that there is resonance between the way you plan the project and implement the features. While there is the Scrum layer between them, they are still tightly coupled. For example (and this is not what I recommend), if you use Waterfall to build your product backlog, then you might want to have your programmers do more Big Design Up Front so they can benefit from the large amount of project planning that you did up front.

An example of good resonance would be:

1. Project planning using Agile Estimating and Planning by Mike Cohn

2. Milestone planning with Scrum

3. Feature implementation with Extreme Programming (XP)

All three of these methodologies are Agile, and support the flexibility and discipline of the others.

Agile project planning is still in its infancy, but Agile Estimating and Planning will get you started on the right foot. Remember to take care when you steer your project, because change is rarely free. Make sure that you integrate all relevant perspectives before you make a significant change to your product backlog. Get the right developers, product designers, and client in a room and let them candidly discuss the change. Ask the developers what changes they think would be good to make. They know what is easy to change and probably have a pretty good idea of what is valuable to you.

Extreme Programming is a great match for Scrum (they even share a lot of the same practices). XP has two main effects on a project:

1. The programmers get better at programming faster than they would without it.

2. Change in project direction is less painful because the software itself is easier to change.

XP also fixes some of the outdated concepts in Scrum by bringing the client and developers together and by allowing user stories to change as soon as the client realizes they should.

Scrum is definitely an improvement for many projects, but you should not switch to it lightly. Make sure you understand how it fits together with the way you plan projects and the way your developers implement features.

Comments

[Stephan Schmidt]

"Scrum is often promoted and adopted as a holistic software development methodology."

Never met anyone in the last 5 years who promoted Scrum this way.

Scrum is a management methodology for stories/MMFs.

I've wrote about that here:

http://codemonkeyism.com/scrum-is-not-about-engineering-practices/

Cheers
Stephan
http://codemonkeyism.com

[Sherrod]

Stephan is absolutely right. Scrum is in no way holistic, nor is it meant to be. It's a set of guiding principles. It's like getting railroad rails and the workers and some parts -- it's up to you to put them together in the *most appropriate way* and make that train go.

[Bill Schofield]

@Stephan & Sherrod

I agree with both of you. Scrum is not 'meant' to be used as a holistic solution, but many adopters perceive it to be one (especially non-technical ones).

My goal is to help them understand that there is something missing and what they can do to transition from whatever process they are currently using to Scrum without undo suffering.

Thanks for the feedback!
-Bill

[Jamie Briant]

I think you've missed several important fundamentals of Scrum. In fact, I find it hard to believe that you are talking about Scrum at all given my experience of it.

"The major drawback is that many teams feel they can change the direction of the product without cost, because Scrum largely ignores that cost. "

Scrum's biggest advantage, if done properly, is *exposing* the cost of change, and minimizing wasted effort when change is required. In our company, the CEO and COO direct the product backlog, and Scrum allowed them to see immediately how the future looked as they changed things. Indeed, it allowed them to nix what they they assumed were easy tasks, in favor of high value tasks that they had assumed were hard.

"At the project level, Scrum calls for a product backlog, but doesn't describe how to create or manage the backlog. "

Have you read any of the books?

"it encourages us to build software that grows increasingly hard to change."

Where? How? I believe quite the opposite. Software that is hard to change is usually over-engineered or under-engineered. Good software needs to be refactored to stay "in shape". If your engineers know nothing about refactoring, then over time your software will be fragile. Scrum allows engineers to factor in the cost of refactoring, and allows rational trade-offs in delaying such efforts. While Scrum does not itself demand refactoring, in the absence of knowledge of refactoring, your product will become fragile. But saying that Scrum encourages you to write bad software, is like saying it encourages you to drive dangerously, simply because it doesn't mention defensive driving. You are still required to know your trade, e.g. how to program C++, or how to refactor.

What you describe in "The Story" is called "Technical Debt".

Scrum and XP work great together.

"XP also fixes some of the outdated concepts in Scrum by bringing the client and developers together and by allowing user stories to change as soon as the client realizes they should."

And yet you complain that Scrum is bad because it allows changes without consideration of the cost of those changes. Your arguments are not consistent.

In fact Scrum suggests that while the backlog can be changed at any time, the sprint is not interrupted except in emergencies. This exposes the cost of change. Scrum provides discipline that XP lacks.

[Bill Schofield]

@Jamie

I have read Scrum books and practiced it for years. The purpose of this article is to help new adopters avoid some common misapplications of Scrum.

It sounds like you think I am criticizing something that you clearly care a lot about. That was not my intent. I was saying something like, "Broccoli is an insufficient diet." Broccoli is a great food but does not provide everything we need to survive.

Scrum tends to push the client and developers apart while XP tends to pull them together (see Chicken/Pig vs. Whole Team). I believe that large savings and improvements in product quality happen in the small (inside features) while expensive miscommunications happen in the large (at the User Story level and above).

Scrum starts us down the path of avoiding these miscommunications by focusing on Stories instead of Systems, but it does not address the cost involved in changing the overall product backlog frequently (this maps to having a wandering Product Vision).

Scrum does not honor the concept of technical debt (nor should it, because feature implementation is not in the scope of product management). XP focuses on technical debt and encourages us to not only reduce technical debt but also to get better at programming every day (so we create less technical debt as we move forward).

Thanks for the feedback!

[Jamie Briant]

On the contrary, I was criticizing you because, if I may continue your analogy, you said "broccoli encourages you to smoke cigarettes". What, exactly, about Scrum encourages you to write code that is hard to maintain?

Once again, I read the rest of your reply wondering "what has he been doing, and why does he think its called scrum?"

"Scrum tends to push the client and development apart". Er, which bit of Scrum is that then? Chicken/Pig is about accountability and responsibility. If you choose not to acknowledge the difference between chicken and pigs then you may have a very, happy, fluffy feeling, but you're likely to fail. Successful teams, of all natures, have leaders, coaches, supporters, bank-rollers. The have different responsibilities, and play a part at different times.

"Scrum does not address the cost involved in changing the overall product backlog frequently". If by that you mean that Ken Schwaber doesn't appear out of thin air and give the indecisive product owner a sound spanking, then I guess you are correct. However, if by "not address" you mean "hides, or ignores" then, again, you aren't doing Scrum. I'm not sure how you can think you've been doing Scrum and have encountered this problem. I assure you I have some of the most "market focused" product owners in the world, and it wasn't until we started using Scrum that these costs were exposed.

"Scrum does not honor the concept of technical debt (nor should it, because feature implementation is not in the scope of product management)."

Eh? What is product management if not management of the implementation of features? Product Management absolutely needs to know about technical debt, because just like monetary debt, sometimes they will need to borrow against it. They need to know the costs. Scrum specifically addresses technical debt by the measurement of velocity, and exposes what happens when technical debt is not paid down. Same applies to overtime. If you have product owners who do not know what technical debt is, they will very quickly learn about it from your velocity.

This article could very easily have been entitled "How XP supports Scrum" and been a positive message about XP. Instead, any positive message about XP has been lost because you felt the need to take down Scrum first. It will be very hard for anyone who has a positive view of Scrum to hear your views on XP. In fact this article is most likely to be used by Scrum naysayers who don't like XP either.

[Tenrox Project Planning Team]

Scrum seems to be a very good methodology when it comes to project planning software development and I would surely like to use it for my next project.

[Dan Yankowsky]

I think that Scrum, when done right, doesn't really do anything other than to establish a heartbeat. It ensures that the necessary things happen with the necessary frequency. It helps to establish the rules of planning. As a developer, I liked the contract: "if you (the product owner) promise not to change these stories for the next week, we (the developers) think we can get them done." It takes enough variables out of the equation that it becomes easier to focus on the development tasks at hand.

I've seen Scrum mishandled, too. As an example, it's possible for a team to continually overcommit. This can happen once the team misses a single commitment. Rather than make the next commitment smaller (as the data indicates they should), they instead overcommit (to try to "catch up"). This leads to another missed commitment, and the cycle repeats until all trust has evaporated.

I have seen a lot of arguments in the blogosphere that "If Scrum isn't working, it's because you're doing it wrong. There's nothing wrong with Scrum." I don't buy that argument. There are many stories of people having problems with Scrum. Most critics are told that they are doing it wrong, but aren't given any advice for how to do it more correctly. I wonder if Scrum is simply hard to adopt correctly. Maybe that's something that's wrong with Scrum.

Don't get me wrong - I like Scrum, I think it's a good process, and I would tend towards Scrummy practices on any project. But it's not above criticism.