Pretty image
The Dude behind Cutting an Agile Groove chats about agility, coaching, and whatever else is on his mind.

David Hussman—widely known as “The Dude”—teaches and coaches agility in companies of all sizes, working side by side with designers, developers, tester, leaders, and others. He speaks and writes about the evolution of software product development at conferences around the world. His video series Cutting an Agile Groove was recently released by The Pragmatic Bookshelf. Figuring that he had some free time with the video production out of the way, I talked him into sitting for an interview on agility and coaching and other areas of his expertise.

ms: Hi David. You and I had a lot of conversations, but this will be the first one with the email tape recorder running.

dh: I’m looking forward to it.

ms: Great. While watching a recent interview with Andy Hunt conducted by Mike Floyd at InfoQ, I thought of you. If it’s all right with you, I’d like to leverage off some of the points Andy brought out in that interview, because I think they’re issues that you deal with every day.

dh: Of all the interviews I have done, I think this approach is a first.

ms: Let’s see how it goes. Andy talked about how the agile movement he and Dave Thomas were instrumental in launching has played out. I’m interested in your perspective on that, because you’re dealing with it in the trenches. Ten years after the penning of the Agile Manifesto, what do you see as the biggest benefits and the largest challenges?

dh: I got into the agile movement because it resonated with how I had been successful: plan a little, do a little, learn a little. Like any movement, rebellion was founded in wanting a better way to work. Ten years later, it is no longer a band of rebels and the agile movement is feeling the weight of popularity. The core benefits are still strong: collaborative groups who learn and pivot based on delivery. There are cool new techniques to use like story mapping and continuous deliver. But sadly, as the popularity of agile methods grows, so does the industry around it. There are more people now talking about “doing agile” instead of learning through doing it. Instead of small bands of rebels covertly delivering, I see large companies and huge projects attempting to use agile methods. Popularity is not bad, but it does call for pragmatism.

ms: Meaning?

dh: I am working hard to get people to look at their outcomes first—the evidence—as a guide to validate and modify their process.

ms: Andy pointed out that most of the advice being offered on “going agile” assumes that you’re starting with a clean slate. But as he says, once you write the first line of code, it’s all legacy. You deal every day with companies trying to get products built and launched, and you have to deal with people wherever they are in their process. How do you do that?

dh: Whether projects are in flight or starting from a green field, I always start with short interviews that provide an understanding of how people are currently working, what they do well, what are their challenges, what they want to change and why, and what constraints might lie in their path. The interviews help me to form a suggested coaching plan.

ms: Can you give me an idea what such a plan would look like?

dh: The plans are a set of tools that augment their existing strengths and address their immediate challenges. While the formality of coaching plans varies, all plans share one thing: they are measurable. I avoid a focus on agile and coach people toward ensuring—by measuring—that the tools fit their context. You can think of this as “designing agility” that introduces the least amount of process that provides evidence for learning.

DavidHussman3.jpg

ms: In the real world you have to deal with personalities, you run up against accounting principles and organizational constraints you can't overcome. How do you counsel people to deal with such seemingly intractable issues?

dh: Constraints are the realities that challenge process ideals. Tough personalities, highly distributed teams, legacy code that is spaghetti—those are common constraints. Planning to coach must include considering the constraints in place instead of blindly teaching people a process, like Agile, Scrum, Lean Start Up. I put constraints into three buckets: immovable, mostly moveable—like mostly dead in The Princess Bride—and self-induced. A common self-induced constraint is “we don’t have time to test,” or automated testing, which most often means “we do not know how to get started” or “we really do not value testing yet.” Mostly movable constraints are more difficult and take many forms: large amounts of external pressure due to differed delivery, weak product thinking, and swamplike environments—those are a few examples. Coaching in a company where the makers work in unpredictable environments has little to do with agile methods but everything to do with fostering meaningful agility. Put another way, if you can’t build it, you can’t deploy it. Or if you can deploy it, you can’t test it and you can’t learn. After ten years of coaching software teams, I continue to be convinced that we need to focus on learning supported by process instead of learning to do processes, like big-A agile.

ms: Andy also mentioned the sloganization of agile, the pervasive attitude that “I’m doing the practice, so I’m doing agile.” People who proclaim confidently, “We’re doing story cards,” with no understanding of why they would want to use that tool. It’s a trap that any methodology is prone to. How do you foster lasting agility that matters, helping people to avoid falling into that “follow the process” trap?

dh: I call the process trap the “recipe trap.” Far worse than being stuck on a practice is being stuck on a process. Years of trying to get people to produce software using agile methods, instead of simply “doing agile” motivated me to create my own law as a guide. Like Ohm’s Law (I = V/R) where I is current which is reduces when V (voltage) is constant and R (resistance) goes up, Dude’s Law, in honor of The Big Lebowski, says that value is a measure of why versus how. Or stated as a simple equation, Value = Why/How. To apply Dude’s Law to your question, when people tell me about user stories or story points—both of which are How—I ask them to show me the results, reframing the practice as a tool that has a purpose—Why—which is more than an empty ritual. Specific to user stories, I teach people to use story mapping because this draws on the ideas of stories as delivery tools but also help produce “the big picture” context which is so often missing where people are spending copious amounts of time talking about “doing agile.”

dude.jpg

ms: Have you ever had someone say, “Don’t call it agile, we tried that and it failed?”

dh: I do hear this often. It is usually a symptom and not the root cause. Sometimes it means people tried new ideas without learning the skills needed. Other times it means that they tried for force a process on a team instead of introducing meaningful tools. Where people are lacking skills, they may simply need to practice a bit. I taught music for years and my teaching included a mix of practices skills—techniques—that helped people play songs. You have to have some level of skill before you assess the quality of an instrument. If you strum a saxophone and you don’t like the sound, don’t blame the instrument. Likewise, if you “try agile” and fail, it may be that you lack the skills to use the tools. Again, if you focus on outcomes, you can choose the tools that will directly help you with your product in your specific context.

ms: I find it encouraging that there is a growing interest in the idea of “coaching.” But coaching sounds like one of those slippery terms. What’s to keep “coaching” from meaning whatever the coach wants it to mean? What is coaching to you?

dh: Five years ago, there were a small number of people using the coach moniker. It was often so confusing that I added “Software Anthropologist and Coach” to my business card to ensure that people asked me what I did. Today, you can’t throw a rock without hitting someone who is a “coach.” But coaching software teams is just another form of coaching. To me, coaching means helping people produce, helping them learn to produce, and helping them learn to learn. The interviews and coaching plans I develop help me find a balance of work people can do unassisted, pragmatic and focused education, and in the trenches coaching, the coaching being where I focus most of my time. Coaching includes building team bonds and teaching new skills that help people produce and learn. Coaching success is best measured by what is produced and how it is being accepted and used. Process and software that are deemed successful without examining the outcomes is like coaching a team—or producing a band—that plays well but never plays for an audience.

ms: All right. Well, thanks for sharing this, David.

dh: My pleasure.

You can learn more about David’s work at his company site. Send us your feedback or discuss the article in the magazine forum.