Making Agile Stick: Developer lessons from the world’s most adaptive art-form
by Alex Lamb
I wrote an article a little while back on the surprising similarities between Agile development and improv theater. At the end of that piece I made a promise to share tools from improv capable of building on Agile best-practices to supercharge your team and take their cooperation and effectiveness to the next level.
Below are five of ten core principles backed, where possible, by well-established scientific research. However, but before I get into them, I should probably say a little more about why I have such confidence in these principles and why I feel certain that they’ll make a difference to whatever organization you’re a part of.
In that prior post, I revealed that I’d worked in both software development and improv theater. What I didn’t tell you was that after starting four improv theater companies and watching the extraordinary difference the techniques were making in people’s lives, I became deeply interested in the science of what was going on. What followed was several years of ongoing research into how improvised activity of any kind affects both the brain and social behavior.
Somewhere during that time, I started collaborating with grad students at UCSC, providing communication skills training for young scientists. Before long, the project had become a full-blown behavior science outreach project in San Francisco. It involved participants from numerous academic disciplines and even a research partnership with the UC Berkeley Biology department. In the wake of all that, I found myself sitting on a pile of data and expertise that I’ve since used to fuel international speaking gigs on organizational behavior and culture change as well as close training collaborations with Silicon Valley companies both small and extremely large.
So here, without more ado, are the first five of ten principles. I hope they prove as useful to you in your work as they have to me.
1. You are not your work
Improv stresses the concept of ‘disposable theater’ and trains performers to not take the failure or success of any particular scene as a reflection on themselves or their abilities. Instead, the outcome of a performance is a product of the group and something to be worked on. Improvisers do this because people are more effective and more rational when they understand the role that chance plays in the outcome of projects. For an excellent explanation of this concept, I can recommend Thinking In Bets by Annie Duke. Her background is in both poker and cognitive psychology rather than improv, but the concept is the same.
What this means in terms of software development is that it works best to maintain a clean separation between developer and code. It’s healthy to be able to critique code you wrote, and to be able to accept critique without feeling like blame is being assigned. Similarly, feeling strong personal ownership over code is a sign that something bad is happening. Usually this has to do with trust in the rest of the team. When trust is strong and team practice is good, handing code off is almost always seamless and easy.
2 . Play all genres
In improv, there’s a strong tradition of having players deliberately take on multiple different styles or story genres. Similarly, players are encouraged to try playing against their habits, taking on characters and roles different from those they normally use in order to boost their flexibility. This is not because players are aspiring to be excellent at everything, but rather because the act of flexing the mental muscle of acting in new ways boost neuroplasticity and improves overall performance. What this means is that strong improvisors will actively seek out genres or character types that they’re weak at and practice them, embracing failure as they go.
What this translates to in software development is not hard to guess. Strong developers never exclusively evangelize for a single language, framework, or methodology. While everyone of course has tools they prefer, effective developers seek out those they don’t know yet and try to use them without prejudice or assumption before passing judgement. This helps prevent the rise of the Golden Hammer anti-pattern.
At a deeper level, this relates to how software professionals engage in the process of self-reward for the work they do. Generally speaking, there are two ways for developers to self-validate: mastery over their tools/environment, and mastery over the problems themselves. A little mastery-over-tools is great. A lot of it leads developers to prefer particular technologies because they were hard to learn, or because others aren’t familiar with it. Old technologies with long learning curves get trumpeted on the grounds of the extraordinary empowerment they hypothetically confer. It’s not hard to think of popular examples. Giving in to the lure of ‘powerful’ yet cryptic tech usually leads to opaque code and unpayable technical debt. For coverage of this phenomenon in other settings, consider looking at the hazing effect that Dan Ariely covers in his excellent book Predictably Irrational.
3. Make failure fun
Before going on stage, many improv groups will pump the sky with their fists or high-five and gleefully chant together: I suck and I love to fail! The reason for this is to cement the feeling of triumph as they throw themselves into a joint act that invariably comes with learning experiences and the occasional botched result.
There are several reasons why this has powerful benefits. For starters, the warmth and strength that comes from team engagement trumps the fear of underperforming. Also, this act innocculates players against the sensation of failure, encouraging them to take appropriate risks together.
Taking the notion of failure and subtly reframing it as something to be enjoyed boosts improv’s most powerful benefit: an adjustment of how the brain activates its amygdala. The amygdala is the brain module responsible for triggering the release of cortisol into the bloodstream and initiating our fight-or-flight response. Once the amygdala is tapped, our ability to focus rationally on our work degrades.
Through deliberately courting small risks and supporting each other as we do so, the way we respond to risk changes and our level of rationality goes up. This is never more important than on a fast-paced technical project where rational thinking is the only way to deliver results. For a book that covers how cortisol can affect business communication, try Crucial Conversations by Patterson et al.
4. Make your partner look good
One way in which improvisers make their work appear seamless and magical is by prioritizing the success of the other players on stage above their own. Instead of cracking jokes unilaterally (gagging), you line up material so that whoever you’re in dialog with can reap the comedic benefit. The net result of this is that the entire performance looks better and smoother than it would otherwise be possible to achieve. In doing so, you trust that your co-player will do the same for you.
The parallel in development terms are straightforward. Where relevant, you build out code that makes it easier for your teammates to do their jobs rather than focusing specifically on your own responsibilities. You take the opportunity to do as many small, easy things on behalf of your coworkers as you can.
As well as the obvious benefit of mutual support that this behavior confers, there is also a deeper, less obvious reason why it’s powerful. Small acts of giving activate our innate human urge to engage in reciprocity. And reciprocity triggers a host of deep instincts around tribe formation and trust. Once your team’s reciprocity engine has turned on, excellence generally follows.
To learn more about reciprocity and how it works, I wholeheartedly recommend Robert Cialdini’s staggeringly insightful book Influence: The Psychology of Persuation.
5. Yes And
A core tenet of improv performance that helps the work look superhuman is the use of the Yes And principle. In essence, players accept whatever reality their stagemates have created and build upon it without question. Not accepting a reality that has already been established in the scene is called blocking, and is something improvisers scrupulously try to avoid.
In software terms, what this means is that code that has been written in a given sprint stays as-is unless it is specifically causing errors or will cause significant rework to amend later. Even if the work deviates from the house style or isn’t completely transparent, it constitutes a part of the scene. The right time to address the limitations of the code is in the review at the end of the sprint when refactoring can be agreed upon.
In brainstorming and design sessions, the Yes And principle is also useful so long as it’s used intelligently. When someone presents an idea, looking for holes or dismantling their offering in the moment is only likely to make the idea’s creator defensive and block dialog. It’s often much more effective to pick an element of that idea that you like and build upon it until the idea is owned by multiple people. Then, if the idea is deemed unworthy afterwards, the team can dismiss it together and egos stay out of the planning equation.
For a deeper investigation of the Yes And principle, try this book of the same name by Leonard and Yorton.
Up Next…
In this post, I’ve tried to focus on relatively tactical principles that can often be applied by Agile teams easily and quickly. In Part 2, I’m going to cover some more strategic concepts that will help you strengthen your developer culture from its roots. Building effective Agile teams like the ones here at productOps doesn’t just mean attending to how you operate from sprint to sprint, but also how you train, plan, and nurture your talent.
