Explaining Scrum to a Waterfall-Addicted Listener

Do it simply and you'll win

2 June 2014


Did you ever have to pitch Scrum to a customer who has always worked with Waterfall?

Telling a romantic-movies lover about the Star Wars saga is easier. When talking about sprints, the backlog, user stories, etc., they will watch as though you're an alien and begin to ask the most absurd questions:

"So we don't need a functional analyst?" -- Eh, don't fire anyone!
"So, in two weeks will you deliver our software?" -- Nine mothers don't make a baby in one month!
"OK, so if at the end we don't like the software you develop, we won't pay, right?" -- Er . . . not really.

To this last question usually I began to talk about Agile contracts, and if before we have been talking about Star Wars, now we might as well be explaining a nightmare!

No one asks questions. The pupils of a manager's eyes become dollar symbols; he'll start making impossible calculations. And you'll lose his attention, definitely.

In my professional life at Consoft, I've talked about Scrum to many customers (and colleagues). After some presentations about Scrum to various customers, I've come to understand that starting immediately with Scrum, Agile contracts, and everything concerning them is not a good thing. A better strategy is to help the customer reflect on his past Waterfall projects.

Without blaming the method: Start with a graph that shows Waterfall's risks. Explain why those risks are so high (making the largest number of decisions in the moment of the least knowledge, activities adapted to planning and not vice versa, and so on).



Then show a graph that clarifies Scrum's risks, and when the customer sees that risks are much lower, he or she will become more interested. We will explain why the risks are so much lower in Scrum (work based on the value of an asset, not its planning; incremental and iterative decisions hand-in-hand with implementations; and so on).



Given this introduction, our listeners will be more mindful and more likely to accept a change of behavior (quoting a tweet by Dragos Dreptate @ddreptate: "Agile is about behavior, not terminology"). They will understand that collaboration between customer and supplier has more advantages than stringent contractual obligations that create a forced partnership.

They will also understand that working software is the best success measure of a project, because numerous documents can't assure the achievement of the project aims. They will understand that if everyone involved in the project collaborates in an atmosphere of transparency and trust, they won't need any tools to control the process. And, last but not least, they will understand that detailed planning that too often responds to reality is less important than a team ready to change (software and its way of acting and thinking [you know -- retrospective...]) in every iteration/sprint.

So the customer will have understood the meaning of the Agile Manifesto. He will be ready to collaborate with us and, at this point, a new agreement for software will no longer be the award of a contract for software development, it will be the collaboration toward a problem's solution.

And when the customer has come to Scrum in this way, he can't do anything more than ask himself, "Why didn't we try this before?"

One last thing: Present Scrum only to customers interested in producing value, not simply in consuming budget!


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 1.8 (34 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.