Uncomfortable with Agile

—Andy Hunt

05/01/2011
Published in PragPub Magazine

It’s been ten years since we coined the term agile. Are you finally comfortable with being agile? If you are comfortable, then that’s too bad, because it means you’re doing it wrong.

A truly agile project team lives on the edge of chaos.

Not slipping back into a comfortable, somnambulant stupor, and not pitching forward over the edge and into the dark abyss of chaos. Do too little and you stagnate, too much and you crash.

Instead, you should have that uncomfortable feeling of tipping back in your seat, just before you lose your balance and catch yourself. That’s what agile is. I think the best definition I’ve seen that captures this spirit of agile comes from Dr. Patricia Benner, author of From Novice to Expert. She’s speaking on the nature of expertise; how to train people in real-world practices (clinical nursing in this case), and notes that:

“Practices can never be completely objectified or formalized because they must ever be worked out anew in particular relationships and in real time.”

That is, you can never completely define agile, or its practices, because they are constantly evolving to meet specific needs in specific circumstances. Agile should be ever-shifting, ever-changing, ever-responding to change in context. You need to keep thinking, keep adjusting.

What Is Agile?

In the crush and press of the exigencies of the day, perhaps we’ve forgotten some of the theoretical underpinnings of agile methods. I’d say agile includes ideas from:

Chaos Theory
Kaizen
Systems Thinking
Risk Management
Return on Investment

and that we’ve probably lost sight of most of these notions.

Some of the key ideas from chaos theory include the observation that people, teams, and software products are inherently non-linear systems. That means that cause-and-effect can be impossible to isolate and identify. That’s not a flaw in your team or project, it’s a fact of life. So is emergence, that nearly-magical phenomenon where complex systems and patterns spontaneously emerge from simple interactions.

Have you experienced emergence lately? In your architecture or team dynamics?

Then of course there are the well-known ideas from Kaizen, emphasizing using quick feedback to make continuous changes, and so to create an environment of continuous improvement.

Are you using feedback to make continuous changes to your product or process?

From Systems Thinking, we came to the idea of people as First-Order Components of the systems we’re building. We’re not resources, we’re not staffing, we’re people, and we’re as much a part of the system as the database is. We realized that it was up to us; that individual practices, special tools or processes wouldn’t save us.

So are you investing in the people on your team? Buying them books (hint, hint)? Sending them to conferences, or training courses? Are you hosting brown-bag lunches to discuss technology and development practices?

Software development is risky business. There are many different ways to manage risk, and the agile way favors minimalism as a core approach. Timeboxing, whether in an iteration or in a design meeting, is a very effective way of minimizing risk. Another way of minimizing risk is to choose to write less code, or even better, not to write code. After all, the line of code not written is always correct. But you already manage risk this way, right? You’re constantly thinking about minimizing risk, aren’t you? You’re timeboxing everything, from iterative deliveries and meetings to how long a team member can be stuck on a bug without asking for help?

Similarly, in addition to minimizing risk, you want to maximize business value—the stakeholders need to see a positive Return on Investment (ROI). That means delivering small bits of functionality frequently that help the business make money.

Notice that each of these underpinnings of agile demands constant attention and thought. You can’t just run with a set of “standard” practices on autopilot.

Practice on the Edge

What does this mean in practice? What do you do now? I can’t tell you. No one can tell you. Only you can discover the answer for yourself. But I can give you some hints.

It means you should find yourself thinking. Being skeptical. Re-evaluating. You’re doing some set of practices—are they working? Are you getting value for your effort? Is everyone on the team growing and advancing in their career?

There are definite warning signs to watch for:

Sloganization—Speech becomes so sloganized that it becomes trivial and eventually loses meaning entirely. Watch for all your favorite agile buzzwords and see if they are being used as meaningless jargon.
Confusion between following rules and exercising judgment—When is it OK to break the rules? All the time? Never? Somewhere in between? How do you know? Some rules probably should never be broken (e.g., check everything into version control, have unit tests, settle on a fixed iteration length) and others may be more flexible (pairing conventions, specifics of customer involvement, etc.).
Confusing the model with reality—A model is not reality. Thinking that an agile project is “supposed to go this way” might be a trap. The only thing it’s supposed to do is succeed. Everything else is up for grabs.
Demanding conformity—The same standard may not always apply equally in all situations or with all people. You don’t want a bunch of monkeys banging on typewriters to churn out code. You want thinking, responsible developers. Don’t reward herd behavior or devalue individual creativity.
Spelling out too much detail too soon—Premature optimization is indeed the root of all evil, whether it’s in your process or your code. Tying things down too early is not agile, and detail can act like instant glue. Patience.
Oversimplification of complex situations—“Just follow the process.” If it were that easy, anyone could do it. But they can’t. Every project, every situation, is more complex than that. “All you need to do is...” or “Just do this...” are invitations to failure. Don’t fall for it.

Wachet auf

Time to wake up! Time to shake things up. Refactor your process. Refactor your code. Refactor your customers. Refactor your priorities.

If you find yourself going through your project on automatic, without thinking about what you’re doing, then you aren’t thinking. You might want to look to that first.

Something to think about.

What’s a guru meditation? It’s an in-house joke from the early days of the Amiga computer and refers to an error message from the Amiga OS, baffling to ordinary users and meaningful only to the technically adept.

Keep up to date with my low-volume newsletter and don't miss another article or fresh idea:

Your subscription could not be saved. Please try again.

Your subscription has been successful.