Key Arguments to Sell Scrum to Your Boss

11 December 2012

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.

Article Rating

Current rating: 0 (0 ratings)

Comments

Michelle Johnson, CSM, 12/12/2012 6:53:55 PM
Robert, I like your article. However, the biggest push-back I've had from previous bosses on implementing Scrum is #1, what if they do not have releasable software after 2 weeks? What if they cannot deliver a row-boat, but have to deliver the Titanic so the software can be ISO certified.

I have developers chunking out huge pieces of work into "story #1, story #2... story #8" that essentially are the same piece of work, but they can't figure out how to chunk it down to a smaller iterative pieces because the whole thing has to be done or if they did "chunk" it out they claim it would be a lot more work.

I did have some success when user story #2 was identified as incorrect in a demo and this saved our engineers a lot of unnecessary work on stories 3-8. But I'm still getting push back that this should be a waterfall project.

Suggestions welcome.
Paul Barnes, CSM, 12/13/2012 4:49:31 AM
Nice article Robert. My comments would be that, actually I think it's okay for people to add stories to the product backlog, but they remain unprioritised and therefore not considered for release/sprint planning until the product owner agrees and does the prioritisation.

Also, there is a cultural element that needs to be considered. And this is one that is the most challenging (apart from budgeting/funding) for execs and teams alike to get to grips with.
Yingjie Liu, CSM, 2/14/2013 2:11:22 AM
I like this article.
Glen Wang, CSM, 2/18/2013 2:58:08 AM
Yes, agile has two secreted weapons. (1) Empowered people, the unity of knowing & doing. (2) Story/Backlog, the unity of strategy and tactic.
Vivek Chandra, CSM, 4/9/2013 3:20:47 PM
If the waterfall is what he has used before and had good success,it will better to do a demo in a test or training environment after developing a feature from his "now list".
Kapil Dhawan, CSM,CSPO, 4/25/2013 10:14:38 PM
Hi,

In addition to @Vivek's comments, It is very difficult to change the mindset of people if it is already working for them for most of the time. Good way is to note down the list of prioritized pain points in the current model and then PoC them using Scrum.

I agree to @Glen. These secret weapons are always needed.

@Michelle
"what if they do not have releasable software after 2 weeks?"
I would say, May be once in a while, but if it is happening every now and then, then there is a serious lack of proper scrum implementation. By inherent nature, Scrum exposes such scenarios quite early and regularly, like in Daily Scrums, Sprint Retrospectives. Team needs to take all these events very seriously in order to avoid future surprises.

"I have developers chunking out huge pieces of work into "story #1, story #2... story #8" that essentially are the same piece of work, but they can't figure out how to chunk it down to a smaller iterative pieces because the whole thing has to be done or if they did "chunk" it out they claim it would be a lot more work."
We should not forget INVEST policy. S stands for 'Sized appropriately or Small'. Take help of an Agile Coach or Domain/Technical expert who can help the team in dividing the work appropriately.

I have recently experienced a good success with one of my projects where work division into appropriate sized stories and prioritization changed the game for us. Rework is inevitable but a good base architecture/design helps in reducing that rework.
Robert Karlsson, CSM, 10/30/2013 6:39:17 AM
Thanks all for your comments!
This article was written to give a good overview and help with arguments for why to sell it to your boss. It's not a silver bullet and can't answer all your needs. People are different.

I've worked with both waterfall and agile after this article, and I think it's important to understand that meanwhile all projects can't be agile - at least 90% can.

Sometimes what's missing is that you can do agile iterations within a waterfall concept. No, I don't mean upfront planning on the details - but even in scrum we talk about having an "Umbrella" of things established. We need to agree on high level technical assumptions, budgets, specifications before we can begin. The team can't build in php if the technology supported is .Net. We need to find the limitations early.

One of the biggest assumptions of scrum, if I might add, is that Waterfall practicioners thinks that scrum means "no documentation" and "no order". This couldn't be further from the truth. It's just that we value working software OVER a lot of documentation - it doesn't mean that we don't do it. And the "no order". Also wrong. It's not a "play around paradise" - no we have to show respect and behave the same way as in any other collaboration - but we are allowed to express our thoughts in a more unlimited way - without the risk of loosing our jobs for trying out something new.

I can go on forever! But let's end with what I like most with scrum:
- As a team member you get involved in the process so that you can contribute earlier to a smart product thus making the solution overall much better.

Robert

You must Login or Signup to comment.