“Don’t ‘Do Agile’; Instead ‘Be Agile’”. This meme started to gain popularity around 2010. I understand it. Depending on how you interpret it, I can even agree with it. All the same, I have never quite felt comfortable with it and I believe that it continues to hurt people, even today.

The Importance of “Being”

I like the spirit of “being agile” over “doing agile”, as it follows in the footsteps of the venerable “values over principles over practices” meme of the early days of Extreme Programming (XP). This older formulation reminded me, the beginning XP practitioner, of a central purpose of the practices: to develop and refine certain fundamental skills that provide the foundation of delivering valuable features sooner. By thinking often about the principles and values, I could avoid turning these practices into bureaucratic rituals, a phenomenon that plagues most (all?) software delivery organizations, at least of a certain size. Sadly, as we have seen since the publication of the Agile Manifesto, a significant number of people interpret “X over Y” to mean “X good; Y bad!” Many people consequently set the values, principles, and practices against one another. They conclude that they don’t need the practices at all, perhaps as an overreaction to the experience of ritualizing practices in the past. Some well-meaning practitioners decide not to teach the practices at all. These attitudes reflect a false dichotomy: “either follow the practices blindly and unquestioningly or throw them out the window and decide everything from first principles”. I don’t do the former and I see the latter as playing the game on an unnecessarily difficult setting. Let me offer another interpretation.

The Importance of “Doing”

When I started learning about and trying XP, I needed the practices (test-first programming, pair programming, weekly planning, quarterly planning, acceptance tests, refactoring) to help me understand the principles (constant planning, eliminating unnecessary work, radiating information, delegating decision-making down), which in turn helped me adopt the values (communication, feedback, simplicity, courage, respect). Along the way, I’ve needed the values to guide myself towards new or stronger principles (relentlessly attacking bottlenecks). I’ve also needed the principles to guide myself towards new or stronger practices. I use them all in a harmonious, self-reinforcing way. Kent Beck once wrote, simply: “The activities (practices) are what you do. The values are how you decide if you are doing it right.” I tend to use the values and principles to guide my actions, but in situations where I don’t quite know what to do, I fall back on the practices, trusting that they will carry me forward until I figure out which way to go.

Tension Can Guide Growth

Sometimes, a practice feels strange in the moment. The rules tell me to do this, but my gut tells me to do that instead. As long as I pay attention to the feeling of strangeness while following the practice, I learn something important about the tension between the two, and this helps me better understand the related principles or values. I suspect that this relates to the journey one takes from Novice to Master practitioner along the Dreyfus Model of Skill Acquisition. Novices seem to respond best to practices. Proficient practitioners seem to guide themselves mostly by the principles. Master practitioners seem to flourish with just the values. When acting as a Novice, I find values and principles interesting, but less practical, because I don’t know what to do next. When acting as a Proficient or Expert practitioner, I find practices comforting, but don’t feel compelled to follow them strictly at all times. As a Novice, I didn’t have “respected” advisers telling me to simply “Be Agile”. I wouldn’t have known what to do with that advice. I’d have likely ignored the advice and likely labeled the advisers “typical airy-fairy consultants”. I needed to know how to “Do Agile” to start on the road to “Becoming Agile”.

Scripting The Critical Moves

This last point relates not only to agile methods, but to any kind of change. The Heath brothers wrote in Switch about “scripting the critical moves” (chapter 3) as a key ingredient to changing people’s behavior. Of course, people want a clear, compelling vision to draw them forward, but if they don’t know how to take those first few tentative steps, they will often remain frozen, despairing about a vision they can never reach. I walked the floor of the banquet room at the XP Universe 2001 conference, telling the likes of Ron Jeffries that they’d shown me a future I would never have, because I couldn’t see how to get started. Those brave enough to take their those first unclear steps will likely falter, and many of these people will give up too early, feeling unsupported and alone. (Search the web for articles about how “TDD sucks” and you can feel fear, anxiety, and resentment.) True, a few will persist and make it, but why should we turn our desire to change the way we work into a test of stamina and determination? We want to guide people towards a more effective, more enjoyable way of delivering software, not break them down to build them back up. In teaching people to “Do Agile”, we script the critical moves for them. We don’t have to withhold the message “Be Agile” from them, but I think we owe it to people to give them more than platitudes and abstract philosophy.

Getting Started

So if you think you want to be agile, but don’t quite know what that really means, do agile things, pay attention to what you’re doing, talk about the results, and reflect on what they might mean. Talk to others about it. Ask questions. Seek out trusted advisers and work with them.