How To Introduce Agile To the Uninitiated

A few months back, a colleague of mine and his organization were about to begin their agile journey. They had piloted Scrum with a single team, and this team was going to share their experiences at an off site with the rest of their small organization. At this same off site, he asked if I’d be willing to take an hour to introduce agile to his organization. I told him I would, and then I realized the challenge I faced.

How would I distill a decade of experiences to sixty minutes of content? Further, I was certain some of the crowd had a misunderstood version of agility imposed on them at some previous org. Others though were hearing about it for the first time. So how could I talk to both groups simultaneously? Also, how could I connect with my audience on a personal level in order to elevate their concerns and questions?

My approach? I stripped away all the silly buzzwords and labels, I spoke in terms of preferences instead of in terms of right and wrong, and I asked a ton of questions using one simple slide.

I started by telling the group that while the things on the right have value, I find more value in the things on the left. (That should sound familiar to anyone who has read the manifesto.) I then asked them what they made of my preferences and asked where they agreed and disagreed. Finally, I asked what the words on the screen meant to them. I can’t recreate that conversation, but let me touch on a few of them and provide attribution as I go.

• People over everything. I can’t tell you how many times I’ve echoed this. Whether it’s customer or employee, always consider how our decisions affect others. Thanks goes to Henrik Kniberg for this brilliant insight.
• Invitation over imposition. This is the basis of what I’ve explained previously. Read this to learn more about why this is valuable.
• Done over started. Credits goes to a great trainer and all around awesome guy Michael James for this insight. Humans are fascinating creatures. Here … try this. Ask a group of people this question:

What’s a better indication of progress? Getting things started or getting things done?

Most–if not all–will answer that progress is defined by how many things we finish. Agreed.  It is.  So why then do we invariably find ourselves choosing to start lots of things but finish few? Also, why aren’t we insisting on changing the system to allow for more “progress” as we define it?  Simply fascinating.

• Experimentation over theorycrafting. Sometimes I refer to this as a bias toward action because the “what if” game only gets us so far. Instead of hypothesizing about all the things that might happen, try something–however small–and see what happens. Decide from that small experiment and its data if it’s worth doing more of the same through another small experimenting or pivoting to try something different.

I realize I didn’t talk about them all, nor did I intend to today. Instead, I wanted to give you a snapshot of a technique I found successful. If you’re asked to introduce agile, maybe it’ll work for you as well. After all:

It’s not necessary to meet people where they’re at, but it is necessary to speak their language before teaching them a new word.

And before I go, another thank you to Henrik who also taught me about failure recovery over failure avoidance. And to MJ for introducing knowledge creation over task completion to me. I wouldn’t be where I am without the inspiration of a great number of people, and I hope my contributions to our community is as substantial as all those who came before me.

---