author and publisher.
Uncomfortable with Agile
Published in PragPub Magazine
It’s been ten years since we coined the term
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
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:
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
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
From Systems Thinking, we came to the idea of
So are you
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,
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.
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
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.
The Pragmatic Programmer, 20th Anniversary Edition
May 7, 2019
New Album, "far flung thoughts"
February 28, 2019
The Four Keys To Rapid Response Software Development
January 14, 2019
- List All News...
Bailing Out Your Company
September 12, 2018
Fixing the Stress of Designing, Forecasting, or Planning
July 9, 2017
Stop Practicing and Start Growing
July 11, 2016
- List All Articles...