Rules for Radicals and Agilists

I was quite interested in Peter DeYoe’s recent blog post comparing Agile development to the P90X fitness program he just started. Riffing off the slogan “Decide, Commit, and Succeed,” DeYoe winds up with

Decide if Agile is right for your organization. Commit to the principles of Agile and deny your urge to fall back on old habits. And if you make it to the third or fourth sprint, a new, healthier paradigm for software development fitness will emerge and lead you to Success.

I like it! But I have a different model for Agile adoption, which is highly influenced by the life example of my darling Drsweetie.

See, Dr is not what you’d call one of those really patient people. She gets frustrated relatively quickly with things that don’t work, and is rarely interesting in tinkering and tinkering with something that shows no results. I, on the other hand, am the one who spends five hours trying to reassemble the toilet. I’m the one who waits a few days to talk about something important because she’s not in the mood right now. That sort of thing.

I don’t see Dr as a “decide, commit, succeed” kind of person. She’s more of a “try, see results, adjust, continue” person. It’s a fundamentally Agile attitude.

The original Agile Manifesto

Which reminds me of a mutual hero, the old-time community organizer Saul Alinsky. I read his (unsurprisingly brief) manifesto Rules for Radicals sometime in the mid-1980s and quickly recognized that Alinsky’s practical ideas had immediate application in normal life. Paraphrasing from the book–because at the moment I unfortunately can’t find my copy!–I especially liked principles like these:

• Incremental improvement: If you can’t get the problem 100% solved, at least take what you can get and come back later. (Agile: Commit to continuous improvement.)
• Process over ideology: Alinsky never told his community groups what their policy goals should be. The important thing is to organize effectively, in order to make more options available. (Agile: Emphasize refactoring and empower self-managed teams.)
• Rule 11: “Pick the target, freeze it, personalize it, and polarize it.” (Agile: Story cards and task backlogs are great tools to guide development effort into the most desired, very specific features.)
• A consistent strategy of allying with friendly organizations rather than competing with them. (Agile: Don’t throw out legacy code. Adapt it.)
• And my absolute favorite, Rule 6: “A good tactic is one your people enjoy. If your people aren’t having a ball doing it, there is something very wrong with the tactic.” (Agile: Favor any and all practices that give rapid feedback for motivation.)

So where does Dr fit in?

I keep thinking of Rule 6 and its application to my dear Dr and physical fitness.

I used to play basketball at the YMCA three times a week until my morning schedule made it impossible. Sometimes it was only for 45 minutes, but it was incredibly intense aerobic activity and more importantly, I kept doing it. Something about jumping to block a shot or grab a rebound makes playing the game so much more compelling to me than the equivalent effort exerted on a treadmill or weight machine. Maybe it’s because I love games, or because as a kid I was astoundingly bad at sports.

Dr’s the same way. She’ll run on a treadmill a few times, but it gets boring and doesn’t really tone quickly enough to feel rewarding. She’s more likely to run through the park with her dog. The key is to find something healthy to do that’s exciting enough on its own to keep you coming back until the fitness results appear. Then you will keep doing it.

Agile teams are like that too. Part of what makes a burndown chart work is its sheer practicality: you can easily report back to management, with decent precision, just how much still needs to be done, maybe on a daily basis. But as a developer, it’s also cool to see your progress as tasks shrink or disappear completely.

When you treat refactoring as a task in its own right, rather than acting like it’s an imposition on you and an impediment to getting your real job done, it becomes fun. You’re making authentic progress in a way that you can recognize, not just moving stuff around so you can get to the real work.

I find that fitness is like software development is like organizing. You have to isolate the target, pick a technique that you and your people enjoy, and understand that continually improving things is a valuable outcome in itself.