Key Arguments to Sell Scrum to Your Boss

Why should your boss let you implement Scrum in your organization? Things are already working, and they get their results.

Well, one thing that I've noticed is always hard on the development side is to quickly respond to changes. The marketers, business, sales, and production staff usually need things to be done now, because, well, now is now and tomorrow is tomorrow.

The process

Let's look at how to address the problem of responding to change, and that might lead us to the answer to our initial question. The process that you might be following, if you are using a "normal" Waterfall scenario, probably goes step-by-step something like this:

• Idea
• Discussion
• Ask development team
• Get an estimate back
• Tell them to do it quicker
• Development, which might press something else off its schedule
• Wait for release
• Wait a little bit more for release
• When it's finally released, it's not exactly what you wanted
• Go back to ask for emergency changes and rerelease
• Team works hard to do it, no time for testing, might introduce new bugs
• Release again

By the time it's done, you and your boss are usually way ahead, working on something else.

How can we explain to the boss that there is a way to respond to business needs faster? A way to make managers, and especially the sales/marketing team, happy more quickly? Embrace their changes faster? See changes as good rather than bad?

We need some arguments to present; we can't just walk up and ask not to be disturbed for two weeks. We need to sell this concept. This might require us to break down the process and advantages of Scrum in clear and meaningful ways. One way is to explain the process like this:

1. Wait two weeks, then get working software that's ready to be deployed.

If we could get a clearly defined task list and leave the team alone for two weeks, what would be the benefits? The goal of each sprint in Scrum is to deliver a "potentially shippable product," which means that in two weeks, you will get something that is tested, working, could be released, corresponds to the stories you wrote, and was done in the best way by the right people.

2. Less talk, more action.

Instead of spending time writing functional specifications, where a senior developer has actually already developed the idea and specifies every function to the team, we'll get right into development, and we can prototype the ideas directly.

3. Changes are good.

What if you want to make changes? It's now, when we look at the prototype, that we find all those small, annoying things it was impossible to think of before (like what if we put the phone number in the header of that landing page, or what if we add those target marketing questions?). We see those needs that normally make the developers think bad thoughts and say, "Why didn't you think of that before"?

This is where Sprint 2 happens. The things that couldn't be completed or needed to be better specified or thought through (changed) aren't done in the sprint you're workin in now; you put them in the backlog and plan them in for the next sprint. True, you'll have to wait two more weeks — but it will truly work. This is why we say that using Scrum means making incremental changes to a working product.

4. One list to rule them all.

"Hey, can you just fix this one thing for me? It's an important fix to a report and I need it now. Now. Now." Every day, various people from the organization sneak through the safety net you've built up with ticketing systems, queues, and request tools. They just want a small fix. They contact the developers directly — leaving the prioritizing decision to them — because we can't protect them.

The solution is to have one list and only one list. The only person who gets to add things to the list is the product owner — no one else. Every request has to go through that person, and then it's prioritized against the other items. This used to happened before, too, but now we have visualized it, so everyone knows it's the system.

5. Use the skills of the developers.

The developers only do programming, so they have to be served thoughtfully, through specifications and detailed written requirements. Otherwise, how can they understand what we need?

Hang on: The truth is that developers are human beings. They know a whole lot more than just development. You'll never know that unless you start challenging and involving them. And a good way is to have them think for themselves. Provide them with a user story rather than a complete requirement.

6. Rely on team spirit.

Developers are the experts on how the system works — if they aren't, your organization has problems — and when they get involved in the early planning phase (sprint planning), they'll come up with ideas no one ever thought about. This creates a really good team spirit. Instead of assigning them, they'll sign up for tasks, deciding for themselves what they'll do best on. By doing this, we are creating responsible coworkers.

7. Not a silver bullet — test it.

What we've done so far doesn't solve everything. We still have to develop. We still have to test it. By testing it, you'll soon see the benefits. Don't change the process or tweak it to fit your organization; try real Scrum first — then you can change it if you need to.

8. Deliver.

We've talked about a lot of things here, but in the end, all that counts to your boss is the result. Make sure to deliver. That's what will really change people's attitudes toward Scrum.

Back to the process

So, what would would the process, which we outlined in Waterfall form above, look like with Scrum?

• Idea
• Discussion
• Write a good story
• Put in a backlog
• Wait two weeks
• Review, make new tasks
• Wait two more weeks
• Process repeats

While we're doing this, other things can be planned and developed by other Scrum teams for different parts of the product you need, making the organization truly productive. And at the end of every two-week cycle, we have a working product.