Defusing the Agile Discussion

In my last post, I outlined the four hidden meanings commonly embedded in the questions "Are you agile?" and "What's your process?"

• No. 1: Do we believe in the same principles of software development?
• No. 2: Do we believe in the same approach to product development?
• No. 3: Can you make software development less scary?
• No. 4: What are your typical process components?

In this post, I'll explain why those versions of "Are you agile?" can become loaded, and suggest ways to defuse the agile discussion. I'm focusing on the agency context, but hopefully these ideas are useful in other contexts as well.

Loaded Question No. 1

"Do we believe in the same principles of software development?" is loaded because nobody wants to come across as not caring about good software (at best) or as being unethical (at worst).

To defuse this part of the discussion, we should first acknowledge that the principles question is settled — and agile won. Any self-respecting, modern digital agency subscribes to the Agile Manifesto's principles and ethics. (There are probably vestiges of the old approach in sectors — government and enterprise — where a self-centered ethics is less-harshly penalized.)

It's a huge red flag if you need to ask an agency in 2014 whether it values code quality or producing working software. In that case, you're better off asking one of the agency's references, anyway.

The second way to defuse this question is to reframe it around how an agency puts these principles into practice. Instead of asking "Are you agile?" ask "How do you ensure code quality?" or "How do you minimize planning bloat?"

Agencies should frame their capabilities in those terms as well. Say "We believe in producing quality working code, and we think that's best achieved through process components X, Y, and Z," rather than "We are agile and use process components X, Y, and Z." The latter is just code words.

Loaded Question No. 2

"Do we believe in the same approach to product development?" is loaded because the agency context often makes a lean approach unrealistic.

Many agency projects are content/marketing sites, which are somewhat less suited to the lean approach. For example, a typical content site's primary features are "users can CRUD various content objects" and "public site visitors can view content." This makes the notion of a minimum viable product less applicable because it's harder to cut back on content than it is on features. (That said, there are usually plenty of content-management features to scale back on: versioning, image management, layout flexibility, personalization, etc.)

Also, many agency projects are requirements-based rather than solutions-based. That is, unlike a lean product company that's focused on solving a specific problem, many agency clients focus on requirements they want implemented. The client stakeholder might have already made promises internally and externally about what will be included. They may have a one-shot budget and want to squeeze in as much as possible. Incremental development and testing is somewhat beside the point when the client ultimately wants all the things.

Finally, many agency clients are not temperamentally suited — organizationally or personally — to a lean approach.

To defuse this question and pre-empt unrealistic expectations, it's important to assess the context: What is the client's business? Is this a content site or a feature-heavy web app? Does the client have a prescriptive requirements list? Then have a frank discussion about what aspects of a lean approach could work in that context.

Loaded Question No. 3

"Can you make software development less scary?" is loaded because it's hard to say: "No, we can't shield you from the scariness. Only by embracing the reality — by riding the wave — can we be successful. Our process ensures we'll conquer that wave, but it can't make the wave disappear." Conversely, it's hard for many clients to accept this truth.

This question is extra-loaded when paired with Loaded Question No. 2. In that case, the client aspirationally wants to be lean but is likely terrified of the reality the lean approach is designed to work with.

This part of the discussion is hard to defuse. The best approach is to be as open as possible. Acknowledge the uncertainty but invoke your experience: you know how to ride the wave without wiping out.

Loaded Question No. 4

"What are your typical process components?" is loaded when it's a proxy for the other loaded questions — when "Do you pair program?" actually means "Are you ethical?"

The best way to defuse this is to explicitly discuss the other questions and acknowledge that a given process component isn't inherently good or useful. Rather, its usefulness depends on the context (agency vs. product company vs. in-house; pre-launch vs. post-launch). And if a process component (e.g. an upfront specifications doc) is not useful, that doesn’t mean the component (or the agency) is bad. It's just ... not useful.

Toward More Productive Discussions

Given all of that, I wonder how valuable the "A" word is at this point. If it's usually shorthand for something else, is there much value in talking about "agile" at all?

At any rate, I'd love to hear your strategies for having these discussions, especially Loaded Question No. 3.