· 4 min read
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.