In the early part of the decade Nicholas Cage starred in the movie “Gone in 60 Seconds,” something about stealing cars very rapidly. In the mid-1980’s colleague Ken Orr wrote “The 1-Minute Methodology,” that uncovered the secret to speed—disconnect input from output. If you can steal a car in 60 seconds or execute a methodology in a minute, why not learn to be agile in 90 seconds?
I get tired of articles like “The 3 things you must know to be agile,” or “Five easy steps to agile implementation,” or “The secrets of agility unleashed,” or “Agile Mastery in Minutes.” Software development is hard. Agile may be a better way to approach software development, but it’s still hard. Maybe I’m slow, but I’ve been working at agile in various forms for nearly 20 years and still learn more every day. Companies are different, teams are different, problems are different, legacy systems are different, business strategies are different, technologies are different. There is no one size fits all agility, and finding your size takes time.
Maybe the Agile Manifesto, since there are only 4 values, has lulled people into thinking agile is simple—do a set of practices and presto, whammo—you’re agile. But complexity theory says that simple rules generate complex behavior, that these rules are conditions that can spark creativity, innovation, and variation. I started out calling my brand of agile—adaptive software development—because I wanted people to think carefully about adapting agile to their specific situations, not using the generic version. Alistair Cockburn’s Crystal methodologies take a similar approach.
Some Agilist’s tout self-organizing teams, then prescribe practices that must be done. It’s like they want teams to make their own project decisions, but hey, don’t decide to modify this perfect methodology I’ve given you. We in the agile community talk about trust as the core of self-organizing teams, but then don’t trust teams we coach to adapt our recommendations thoughtfully. Agile mastery comes over time, to individuals, teams, and organizations. Mastery comes from bumping up against thousands of specific, detailed problems and solving those problems through investigation, collaboration, and thought. Agile practices are on one hand simple—what could be simpler for example than a daily stand-up meeting—but complex in execution.
Colleague Ken Collier talks about the difference between doing agile (practices) and being agile (mindset & behaviors). Unfortunately many organizations want “prescriptive” agility—just tell us the 4 steps or 8 practices. Some agile consultants prescribe exactly what to do, and somehow forget the adapting piece. Isn’t “prescriptive agility” an oxymoron, or may be it’s just moronic. Becoming agile is a process, not a goal. It’s a process of learning and adapting, not prescribing. It isn’t something that can be learned in 90 seconds.
