Etymologically, “fluency” is about flow. Practically, it’s about language: from one angle, it’s how well you understand and speak under stress or pressure. My teammates playing the Agile Fluency Game in Hamburg a couple weeks ago had no discernible difficulty speaking English, but it must have been effortful for them, because when we felt the clock ticking, they returned to German. Communicating more efficiently within the team — including me, since I could mostly understand them — bought us time and brainpower to improve our outcome considerably.
The Agile Fluency Game is intended to help understand and speak about the Agile Fluency Model. As Diana Larsen explained it, the model suggests thinking of Agile as something like zones in a municipal transit system. From the city center, it costs more to get to the outer zones, but not because they’re objectively superior places. They’re just further away from where we are. If it’s worth it to pay the fare and take the time, we can get there.
Since the model offers four zones with benefits and relative costs, I might also liken it to the number of courses in a meal: Agile-striving organizations can order just enough to sate their investment appetite.
So what?
For me, the usefulness of the Agile Fluency Model centers on offering an alternative to some false dichotomies:
- doing Agile vs. being Agile
- being Agile vs. not
Perhaps these dichotomies are rhetorically useful. I certainly find them useful as motivation to reframe. As a student of behavior, I don’t see a clear separation between doing and being; as a student of Agile, I don’t see a clear reason (or basis) to judge ourselves in or out. If the Agile Fluency Model helps us refocus on making adaptive choices in and about our own environments, then it’s a useful frame.
In this sense, it’s also an Agile Congruency Model. If we can more precisely identify our organizational and individual needs, we can more explicitly meet them, and expend much less effort bridging or apologizing for a significant gap between our espoused values and our values-in-action. Maybe the two sets of values can be congruent.
Playing the game
We played twice.
The first time through, we spent a big percentage of our time and brainpower getting oriented in the game — some up front and some as we went along — kind of like when we were brand new to Agile. There were cards about features (of which we must deliver at least one per quarter, to make money) and about practices (which might be, I dunno, really helpful for delivering features). My intuition said that if the design of this game was based on real-world experience anything like mine, we should be willing to defer most other goals in exchange for practicing Test-Driven Development and Refactoring as early as possible. My teammates had other ideas, so my intuition was tested. Indeed, it got harder and harder to deliver a feature in time, until finally we couldn’t, and lost.
TDD and refactoring conspire to remove costs and risks that otherwise remain hidden. It’s precisely when the current state is hard to see that the proposed benefit is hard to imagine. Words often fail. Distilled from the experience and wisdom of James Shore and Arlo Belshee, the Agile Fluency Game offers a way for people who haven’t yet tried these disciplined development practices to get a meaningful, cause-and-effect feeling for their costs and benefits.
The second time through, we graphed the practices and their dependencies, avoided delivering more than one feature per quarter, and spent the rest of our resources acquiring practices prioritized by in-game benefits (such as reduced carrying cost of existing code). This turned out to be a very good strategy. We got into flow, played more than our individual roles, helped each other hold attention to our strategy, racked up increments of success and momentum, rolled up our sleeves because we were getting warm, and won an outcome beyond what we assumed possible. Afterward, Anja said “Can we do a real project together?”
Takeaways
After sharing that feeling, I was disappointed at not being able to take away a copy of the Agile Fluency Game. It’s understandable: since the game’s design is intentionally complicated, learning from the game in a reasonable timeframe benefits from — indeed, might require — intentional facilitation. Even so, it was disappointing. Even so so, I may consider enrolling in the training required to get it, because I’d love to have the option to share the game with my clients.
Why is having this option important to me? Because what I did take away is a reinforced belief that we humans are far more apt to learn new behaviors from experiences than from words. (Don’t get me wrong. I love words. And they’re a great way to become aware of behaviors we might like to try.) As a coach, I can tell when I’m at my best: it’s when I’m doing less explaining and more creating shared experiences. So I’m glad to have played the Agile Fluency Game, and I hope many more people get to play it.