The Agile Story: Show, don’t tell

The other day I was reminded of something I learned in creative writing, and how it applies to talking to people about Agile methodologies.

My professor would tell us “You don’t say, ‘When Jack lost his job, he went a bit crazy’ instead, you show him doing crazy things and let the reader see Jack’s state of mind for herself.”

William Carlos Williams said it another way “No Ideas but in Things.” Concrete things, facts, and images are the hallmarks of a good story. Here’s the Jack/crazy story with the commentary removed and a few details added:

After the layoff Jack drove home parked in the garage, and sat there for over hour. When his wife finally got home from work, she him sitting in silence, in his car, in the dark.

When she knocked on the window, he blinked turned to see where the noise came from, and didn’t even seem to recognize her.

To often we tell people our conclusions about what happened, rather than giving them the right context and the right images.

We tell them how Test Driven Development will increase their productivity, but we don’t give them the stories that show how it will make them feel more confidence and less stress.

The preface of Test Driven Development by example is a good example of what I’m looking for. Kent Beck tells a story about two days in the life of a programming team, and what Test Driven Development (TDD) did for them. I read this book 3 years ago, and I don’t remember much of the specific advice Kent gave in the book, but I do remember the story of Ward Cunningham, and the team of developers who saved the day.

A well told story is about organizing the right details in the right order. And people only change the stories they play in their heads when you offer them a better, more engaging story. If you’re trying to lead a team of people to try incremental delivery, or test driven development, weekly code reviews, or some other new technique, your best shot is not to tell them it’s better, but to tell a story where somebody they can identify with used that technique to solve a problem.

If you do this right, you’ll give the other person the privilege of saying “hey, why don’t we try that here.” Then, suddenly they own the idea, and you’re just a willing and encouraging partner. This is a lot better than fighting with the team “in their best interests.”

2 Responses to “The Agile Story: Show, don’t tell”

  1. 1Bob

    > My professor would tell us “You don’t say, ‘When lost his job, Jack went a bit crazy’…

    Who is your professor to tell Yoda how to speak!? ;)

  2. Yoda says \”Pronouns, lost I have. Find them I will!\”

    I think I lost the \”he\” there. But now it\’s back!

Comments are currently closed.