How to Do Agile Software Development the Right Way

To learn more about Elisabeth's journey to Agile software development, listen to Episode 75 of the award-winning DevOps Radio podcast.

Agile development has been around for years, but not everybody is doing it the right way. Just ask Elisabeth Hendrickson, who until recently was vice president of quality assurance at Pivotal Labs, a leader in agile software development and now a division of VMware.

Hendrickson's career in the software industry spans a few decades and includes stints as a technical writer, developer, and test automation specialist. The variety of jobs has been a good thing, she says, giving her a holistic view of the industry and a deeper appreciation of each step of the development lifecycle.

Hendrickson started on her journey to agile software development after spending several years working for companies that developed software the traditional way, where the roles of code writing and quality testing were rigidly separated. She noticed that despite extensive testing, quality problems persisted. "It looked like QA was doing an incredible job," she says. "They were finding and fixing all these bugs, so you think you would get better quality."

Agile Creativity

Not so, Hendrickson says. "What's happening is they're finding the bugs so late in the cycle that it's too late to fix them all." Based on that experience, she wrote an award-winning paper debunking the notion that you can correct poor engineering simply by testing more.

In her search of a better way to do quality assurance, Hendrickson crossed paths with Rob Mee, co-founder of Pivotal Labs. "I had been learning about agile software development and I was intrigued by everything he said," Hendrickson says. It wasn't long before the future VP of QA joined Mee's company. The move completely changed her perspective. "This is what software development is supposed to feel like," she recalls thinking. "I never looked back."

At Pivotal, she came to realize that agile software development was all about getting ideas into the code base in a way that was quickly "shippable," thus allowing for fast feedback. She saw how waterfall-type approaches, with their multiple stages and signoffs, were actually just a series bottlenecks that slowed innovation. By contrast, agile software development - when done correctly - smooths the path from innovation to delivery. Agile practices were there to support human creativity, not about "process for process' sake."

Although organizations have now widely embraced the concept of agile software development, Hendrickson believes one of agile's core tenets - early feedback - has been forgotten by many, with potentially dire consequences. "Agile done badly can be dangerous," she says. "If you don't have any form of feedback and you're just focusing on being fast, you will end up shipping software that doesn't work."

How do you know you're doing agile right? Hendrickson boils it down to what she calls the "Agile Acid Test." There are three parts to it:

• Delivering a continuous stream of value. This doesn't mean developing faster, but rather sooner. You put capabilities into the hands of customers more frequently, in smaller chunks, and get feedback faster.

• At a sustainable pace. Delivering software more frequently doesn't work if it's not sustainable for the team. "Doing a death march every month doesn't work," Hendrickson says.

• While adapting to the changing needs of the business. As the world shifts, your organization needs to shift with it. Agile software development makes sure you don't build software products that nobody wants.

Delivering software continuously at a sustainable pace enables you to get the feedback you need to "steer towards value," Hendrickson says. That's why she's always focused on delivering sooner, not faster. And when you think about it more broadly, she says, that's a strategy that could benefit the whole business.

What else is on Elisabeth Hendrickson's mind? Tune into DevOps Radio Episode #75 to learn about how she motivates development teams, thrives in a traditionally male industry, and avoids one of the worst mistakes you can make in agile software development.