Q&A: Why agile software development is all the rage

When it comes to software development, it seems like agile is still king: In Digital.ai’s 17th annual State of Agile report, a full 71% of respondents said they embraced agile software development methods over traditional, linear methods of software development, like the waterfall model.

Though the term “agile” can have a befuddling number of meanings, at its core an agile workflow involves continually writing, testing, deploying, and shipping code in an iterative manner. Popular agile methodologies include scrum and kanban, though in practice there are many overlapping variations.

IT Brew sat down with Leigh Ann Gunther, the vice president of education at the Project Management Institute’s Delaware Valley Chapter and a senior technical project manager at Comcast, to discuss what problems agile solves, why it may be better suited for modern software development, and how management can build an agile culture.

This interview has been edited for length and clarity.

Is agile something that has to be an entire methodology that you follow, or can you integrate it into other approaches?

Frequently, when we talk about agile, we assume that that means we have to follow a specific framework like scrum or kanban, or maybe a scaled version of that, and then SAFe (Scaled Agile Framework]). Fortunately, it’s been mixed together, and I think that there’s a big difference between the methodology and the mindset.

If management doesn’t fully understand agile development, what can go wrong?

You can force a methodology on a team and organization, but if they don’t understand why they’re doing it and what the value is that they’re getting, and that their customers are getting, then they’re not going to be happy in any model.

And nobody likes change, right? So forcing someone to change in their work environment and not explaining it, not understanding what the end goal is, you’re gonna have resistance—and inevitably, what we would call a failed transformation. Also, transformations towards agile fail [when] it’s just verbiage that comes out of their mouth, it’s just words.

What happens when something goes wrong in agile development?

Usually, if we hear about a defect in scrum that needs to be addressed, it’s not all the way to production—so it hasn’t actually made an impact on the customer, because we have this continuous integration, where we’re constantly testing the new code that’s going in before it goes out to production. When big things go wrong, we roll back and we pivot…They’re never huge mistakes, because your development cycles are short. The packages that you’re developing and delivering to production, delivering to the end customer, never have a ton of functionality in them.

You don’t have that in predictive or waterfall because by the time you’ve demoed something, and you’ve shown it to the consumer, well you’re already done. They haven’t seen it until it’s finished.

Are there certain kinds of projects in software development where a linear approach might be more effective?

Traditionally, we say something is better suited for a predictive or a waterfall [model] if we know the absolute steps we have to take to get there—which I think is a little misleading, because it’s not necessarily about how we take the steps. It’s about how we work with each other and the mindset that we manifest as we’re doing the work.

I can’t think of a reason in software development that you would choose to do waterfall over an agile methodology. The Big Bang Theory [or software released] just doesn’t hold in today’s world where things are moving so quickly and requirements change.