The most challenging part of my job is convincing clients, and potential clients, of the virtues of Agile and how it will help them reach their goals. The reason it is challenging is simple: we lack a shared understanding of the topic that we’re discussing. This challenge isn’t limited to clients, as my most contentious conversations tend to be with peers who should be on the same page. Ultimately this challenge isn’t so much a puzzle to be solved as an opportunity to explore.
In the past 15 years I have worked at 6 companies that all claimed to be Agile. Even before the Agile Manifesto was committed to paper, I worked with members of my development teams to implement practices that today look like flavours of Extreme Programming and Rapid Prototyping. We tried things and they worked. Or more often, they didn’t. We used to execute on a weekly cycle. A week seemed at the time to be the longest period of time we could go without a client clamouring to see “the latest” version of their precious software. We thought we had figured it all out, and our process was the best. One important takeaway from my experience is this: Agile methods are akin to mothers. Everyone has one and most believe theirs is the best.
Indeed, there is no one-size-fits-all approach. Contrary to (frighteningly) popular belief, Agile ≠ Scrum. I’ve lost count of how many times I’ve uttered this formula. Someone unversed in Agile has few expectations that need alignment. You can start with a discussion of benefits and methods and go on from there.
A little knowledge can be a dangerous thing. When your antagonist’s complete understanding of Agile revolves around Scrum practices, any discussion of other methods such as Kanban or XP is handicapped from the start. Forget conversations about scaling Agile to the enterprise, managing Agile processes in an otherwise Waterfall environment, or folding UX and testing into development iterations. They will be spending all of their time trying to put concepts into neat boxes in context with Scrum.
Worse, too many groups practice a Scrum ceremony or two and consider themselves Agile. “Yeah,” I typically hear, “we’re Agile. We hold a standup every day!” Or, “We have a Scrum Master who gives us our work assignments!” “We don’t do that” rationales such as planning sessions take too long; retrospectives are just finger-pointing exercises; 2-week sprints are too short to get anything real done.
The first step to breaching this gap is reaching agreement that the formula is not in fact Agile ≠ Scrum, but is actually Scrum ∈ Agile. For the mathematically disinclined, this reads “Scrum is an element of Agile.” Using Scrum terms to describe Agile concepts is a bit like traveling from New York to London. You’ll need a vehicle to get there. A car and a jet are both vehicles, but driving a car across the ocean is going to take a bunch of time. And this is after you figure out how to survive 2 miles underwater for a week.
Once you have agreement on the formula, the next step is to dispel the number one misconception of Agile: that Agile only applies to software development. Agile is not a software development methodology. It may have started out that way, but Agile’s success has to do with divorcing the Agile philosophy from its implementations. Agile is a journey, not a destination, exacting cultural change through continuous improvement.
The third step is to refocus the discussion away from process and towards shared goals. So much effort is expended on the mechanics of Agile without a thought given to their benefits. Why do we allow teams to be self-organizing and self-managing? Why do we make the financially illogical decision to put a pair of programmers on a single workstation? Why don’t we extend a sprint if we’re falling behind? The answers to these questions pave the way for a joint understanding of the subject at hand and allow both parties to speak in a common tongue.
Seek first to understand, then to be understood. Only with a common shared understanding of Agile and using a common language can we ever hope to realize all of the benefits that Agile affords.