Bob Galen is a leading agile consultant with over twenty-five years of experience working in the fields of software technology and product development. He also authored the book, Software Endgames, and is a speaker at STAREAST where he will be presenting two sessions relating to testing in agile environments. In this interview with online editor Jonathan Vanian, Bob discusses how agile has influenced testing over the years, the role of a tester in an agile project, and what exactly is “session-based exploratory testing.”
Jonathan Vanian: How long have you been working on agile projects?
Bob Galen: I was working at Lucent [Technologies] in 2000 and we were an early adopter of extreme programming. Before that, I was living in Connecticut and I actually stumbled across the original papers about Scrum. They were published for OOPSLA by Schwaber, Beedle, Sutherland—those guys. I was really intrigued by that. I was doing stand-ups right around ’97 or ’95 when they were first describing it. I don’t think I was officially Scrum, but I was really intrigued by the methods. So, maybe for the last ten to twelve years.
JV: Why did you decide to use these methods?
BG: I think I’m aligned with servant leadership. I’ve been a manager for maybe twenty-five years leading software development teams. I remember I was a senior architect or senior engineer, and I came into my office one morning and there was this org. chart on my chair with names on it. My boss and every programmer at the time were introverted, and we didn’t like to communicate with each other. So he sort of like, plopped paper on my chair and was like, “Bob”—he didn’t even say to me, I had to go and ask—“Oh, that’s your team. I just promoted you to be a manager.” I didn’t even know half of the people on the org chart. I had to go find them.
But I’ve been leading for a long time and early on I made those quintessential mistakes of trying to tell people what to do. Very quickly I discovered that the service model and empowering teams were a much more effective way of getting stuff done.
So when I stumbled on agile, it sort of aligned really well with some of my core principles. It was sort of this beautiful convergence with the methods of my style and it seemed to work very well for me. It also gave me a package. What I like about agile is that it sort of gives you a toolbox or package deal for how to communicate a set of things that always work. Like, pair programming always worked. I paired in the late ‘70s and early ‘80s, it just wasn’t [labeled] XP—it wasn’t sexy. We didn’t really think it was a novel thing to do, but agile gave it a name and a package to all the stuff that we all knew.
JV: It’s only recently that people have put a name to these practices that have been around for so long.
BG: Exactly. Doing unit tests first—that’s not novel with agile. Ward Cunningham and a lot of people were talking about that earlier, but they didn’t give it the TDD acronym. They weren’t exactly fixated on unit test frameworks or things like that, but the model, the approach, and the technique were very effective. I remember doing it with assembly code for gosh sakes with very simple text editors and very little in the way of tooling. But we did test first.