The Fundamentals of Agile: An Interview with Jeffery Payne


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."


User Comments

Charles smith's picture

Thanks for this nice and important information. It helped gaining multiple perspectives towards agile. I would like to add another perspective as detailed in

“Agile is a group of iterative and incremental software development methods. It encourages flexibility and speed in responding to change. It requires collaboration between self-organized, cross-functional teams to generate requirements and solutions. – See more at:

January 20, 2016 - 1:39am
Clifford Berg's picture

Fantastic article.

I second Jeff's point, which he makes repeatedly, that performing Agile practices ("ceremonies", etc.) does not make a team or organization Agile. I also second his point that one should start with one's current process and ask what is not working. IME, "installing" Agile by making everyone implement Agile practices overnight does not work well. It can be made to work eventually, but what happens is that teams abdicate their responsibility for their own process and become dependent on the coach or Scrum Master - the teams stop thinking, and thinking is the most crucial thing for Agile success! Watch Dave Thomas's talk last summer:

Jeff is also right that Agile led to DevOps. However, DevOps was really born out of the failure of the Agile community to think beyond entrenched Agile practices. Agile has become more about certain practices than about the values and principles. Jeff alludes to this: that Agile should not be about the ceremonies. DevOps should have been the evolution of Agile, but it arose as its own movement because the Agile community was not able to think that far. DevOps adds to Agile considerably - it expands the scope to beyond the team; and DevOps also changes some important Agile practices, such as how one performs continuous integration: in a DevOps setting, CI level testing shifts from a focus on unit tests to a focus on end-to-end behavioral tests. Why? Because we now can: using VMs (or even better, containers) and cloud services, each developer can stand up an entire end-to-end test environment and run end-to-end tests before they push their code. That's a big change.

Jeff also focuses on a crucial point: "If you don’t tackle [getting developers and testers to work together] you’re going to struggle in agile because you're going too many hand offs." At its core, DevOps is about testing - about all aspects of testing - not just unit testing. Defining the development/test pipeline is central to DevOps implementation, and defining that pipeline is a collaborative effort.

Well said Jeff!!


May 5, 2016 - 10:10am

About the author

Upcoming Events

Feb 27
Mar 06
Apr 24
Apr 24