In this interview, Coveros CEO and agile instructor Jeff Payne discusses why you should make the move to agile, its many benefits, and how to transition. He also explains his SQE Training course, Fundamentals of Agile Certification.
Josiah Renaudin: Today I’m joined by Jeff Payne, the CEO and founder of Coveros and instructor for SQE Training's Fundamentals of Agile Certification class. We'll be speaking on both agile as a whole as well as the different aspects of the course itself. Jeff, thank you very much for joining us today.
Jeff Payne: Thank you, Josiah, for having me.
Josiah Renaudin: Absolutely. Before we start really digging into the material of the course, can you tell us a bit about your background and your experience with the agile methodology?
Jeff Payne: Sure. I’ve been building and testing for twenty-five years. I got first interested in agile really when Windows XP and some of the early agile writing started appearing out into the world and books and papers started being written about agile. What attracted me to it was a couple of things. First of all, as a developer early in my career before I started my first company, when I read about agile, it just made perfect sense to me. It seemed like the types of things that I would want to do and would think would work as a developer.
Second is that running a company at that time that was around quality assurance and testing, I loved the fact that quality was so integrated into agile, because we were always pushing to get people to move quality earlier in the process, do unit testing at the developer level, and to automate when it made sense. Your QA and test and agile just fit perfectly with that. When I decided to start a new company in 2008, I decided to center it around agile and DevOps, which is naturally very closely aligned with agile.
Josiah Renaudin: Yeah, good for you, because of the fact that both of those concepts are really blowing up more and more as we dig deeper and deeper into them. What do you think makes agile so different from traditional methodologies?
Jeff Payne: There’s lots of differences between agile and traditional methodologies. I think most of these are outlined pretty well in the principles of agile that are part of the manifesto. The manifesto is really the defining document for the agile movement. A couple that I like the most, the principles that I think really highlight the differences are, first and foremost, working code is the measure of progress. We always talk about all the different artifacts that we can produce during the software development process, things like requirements, docs, design docs, and obviously the code, and test cases, and test plans, and things like that, and they’re all good things and we need them all, and to review them is a good thing to do.
However, the reality is there's only really one thing that ships to the customer, and that’s compiled code. All the other artifacts that we produce are things that are supposed to help us get to where we want to get to. Agile says, "It’s great to have those things, use those things as you need them, but don’t try to measure your progress based on them." I’ve sat in on a lot of review meetings, and document review meetings, and project review meetings, and you’re always trying to figure out are we on schedule, are we on budget, are we going to get what we want to market? The reality is it’s really difficult to do that if you’re not measuring what you’re actually delivering and that’s working code.
In traditional methodologies, you don’t have working code until really late in the process, so that makes it really hard to use working code as a measure of progress. That’s where the agile approach where you’re building code in small increments and small bite-size chunks is just radically different than traditional methodologies and something I think makes agile work.
The second one that I would highlight is the principle of agile around embracing change. That kind of sounds like motherhood and apple pie, because the world’s changing and we need to change with it, yada, yada, yada, but you'll notice that a lot of traditional methodologies around software are all about trying to control change. There's change review boards, and there's change control, and there’s manage to change this, control change that, but the reality is we don’t control change. Agile says, "We're not been going to control change. Instead of controlling it, we should embrace it, we should expect it to happen and when it happens we should figure out how to deal with it."