Things don’t always go the way you expect them to go. Sometimes, you have to improvise. You roll with new information and new events as they unfold.
Dungeons & Dragons actively invites uncertainty with the randomized dice-based system. Because of this, I know that it’s impossible to plan everything. Instead, I have to rely on my improvisational skills to keep the game moving, keep my friends engaged, and present them with a thrilling adventure.
In the same way, an Agile process is meant to embrace uncertainty. Sprints, iterative planning, retrospectives…these tools allow a team to respond to change and adapt to new information. Here are some additional techniques I’ve learned in my D&D sessions that you can apply to your Agile projects.
Be Willing to Be Wrong
When designing a dungeon for my players, there are certain assumptions I find myself making along the way.
“Surely the barbarian will be able to break down this wooden door.”
“My players will definitely think it’s weird to find glowing sheep grazing in a dark cavern.”
“If I mention a dwarf sitting in the back of a tavern, the party won’t demand his life story.”
But those assumptions can easily be wrong. The barbarian stubs her toe on the door instead of kicking it into splinters. The party sees the eerie glow from the sheep and decides that it’s not worth investigating. And every single nondescript character I mention sitting in a tavern is interrogated like a murder suspect.
The same thing can happen on a project. I was recently working on a mobile application that required a login. Our development team was working on features based on assumptions we had made about the backend logged-in state. However, the backend servers used a totally different concept of what it meant for a user to be logged in, so a lot of our expectations for future work were incorrect. Eventually, the client noticed and corrected our mistake. We were dead wrong, and we had been for a while. But that was okay!
Because we realized our mistake, we were able to work around the miscommunication and realign our assumptions with the reality of the system. The developers on the team gained a better understanding of the system as a whole. We were able to make more informed decisions on features in the future.
If, instead, we had stubbornly held onto our beliefs about how the application “should” work, we might have started an implementation argument that we couldn’t win and would have soured the project for everyone involved.
Cultivate Excited Exploration
Recently, I’ve been trying to push myself and my players toward getting excited about moments that catch us off guard. As noted in my Preparation post, I used to over-plan my D&D sessions to the point that I would get angry and frustrated when my players didn’t do what I expected them to do. I would redirect my players to the “correct” path in obtrusive ways. This discouraged exploration and imagination in my players. If I was going to force them into a specific path, why should they bother trying something new?
As I’ve grown, I’ve learned the value of exploring players’ actions and letting them build the story with me. That means that they can do something unexpected, and I just have to roll with it. Together, we work to build a story that’s more engaging and way more fun than anything I could put together on my own.
The same should be said of the workplace. If you respond to unexpected developments with anger and frustration, you’ll discourage your teammates from presenting you with those realities. Not only that, but you promote an environment where people avoid trying something new, just in case it doesn’t produce the exact result that’s expected.
Instead, treat new information as a good thing, a tool to navigate toward the best product you can create.
Be Willing to Break for Processing
When it comes to changing direction, I’ve noticed that there’s a common expectation that people can improvise immediately. But sometimes it just doesn’t work that way. As an introvert, it often takes me a little extra time to think through a huge dump of new information and plan out my best path forward in this new context. I’ve found that taking a quick break from the gathering offers a nice space to do that processing.
You can say you’d like to break for five minutes to think, or you could just suggest a general break. In a D&D game, when a player announces that they want to travel to a city on the map that I’m not prepared to discuss, I often suggest a quick snack break before we get to this new location. This gives my players time to break from the game and gives me a few minutes to review my notes for this town.
Securing time for yourself to think by suggesting a break is a great strategy during a particularly intense team meeting, too. Breaks not only give you time to think. They also allow everyone in the meeting to decompress. If you’ve spent the past two hours hammering out details about your product, everyone will benefit from the relief of tabling that talk for at least a few minutes.
Like all things, running a D&D game or a project requires a healthy balance of preparation and adaptation. You want to be ready for what comes ahead, but accept that you can’t know what that will be. Be as prepared as you can be, but also be ready to adapt, to adjust, to be agile.
Improvisation has sparked some of the greatest moments of my D&D experience, and I’m sure it’ll work wonders for your project, too.
Come back next week Sunday for the next post in the series: