When it was published in early 2001, the Agile Manifesto was revolutionary. Outlining 12 principles of agile development, the authors laid out a better way for teams to approach software development – providing a process that prioritizes customer satisfaction through early and continuous software delivery; flexible enough to allow for changes even very late in development.
Like many breakthroughs in the IT world, “agile” is often reduced to a buzzword in the years since the concept was introduced. Some companies embrace the term but never do the hard work of implementing the principles and practices that truly set agile development apart.
In a recent interview with the Tech Barometer podcast, two pioneers of agile development processes explained how development teams can be sure they’re getting it right.
Get Real-Time Customer Feedback
This, in a nutshell, is what separates agile development from “waterfall” development. While waterfall development relies on copious documentation, agile is about putting a product out into the world and seeing how it works.
“You have to understand: It ain’t real unless it’s out there and the customers are using it,” said Jon Kern, an agile transformation consultant and one of the 17 engineers who met in Snowbird, Utah, 20 years ago to write the Agile Manifesto.
“For me, there’s one sentence that I’ll often use to try to describe what agile is, and it goes like this: Do everything you can to reduce the gap in time from doing something to getting feedback.”
Prioritize Process Over Products
Too often, teams express frustration with their development tools, when what they should be doing is making changes to their development processes, said Dan Hardiker, chief technology officer at Weaver and a longtime proponent of agile development.
“There’s a saying in SCUBA diving that tourists come along who have money and all the gear, and they’re the dangerous ones because they buy the advanced equipment that can get them into situations beyond their control,” Hardiker said.
“You end up throwing out a development tool and saying, ‘Let’s replace it with the next new shiny thing.’ You think that technology will save us when it’s already in our hands.”
Take a Systems View
“What I try to encourage teams to do is use a systems theory and be holistic,” said Kern. “That’s why I love what Nutanix is doing. They’re pushing agile and lean concepts under the guise of making things run anywhere, making everything work together.”
He explained that hyperconvered infrastructure and software-defined systems that allow developers to work across private and public cloud brings everything together under one control plane.
“It’s not a bunch of separate little things,” he said. “You’re part of a system. You’re part of a whole.”
Refine Over Time
Kern said that teams must continuously refine and optimize their processes.
“That’s probably the hardest thing, to not fall into the trap of just coming in every day working like an hourly employee doing 9 to 5,” he said.” It’s very challenging to be agile, and you have to constantly evaluate what you’re doing.”
“If you’re worried about whether you're doing agile properly, or about the things that hold you back from doing agile, it’s going to be the ceremonies, where you do stand-ups each day or you’re doing your backlog sprints,” added Hardiker.
“And when you get to the retrospective, is this the retrospective that we do every two weeks? And what comes out of it? How have we changed the agile processes that we’re using from three months ago or six months ago?”
Shorten the Time-to-Change
When evaluating whether teams have indeed adopted agile, Kern looks for one key metric: how long it takes to make a change to an application.
“Typically, I’ll try to ask teams what it takes for them to deliver the smallest change – I’m thinking like a typo, just something trivial,” Kern said.
Shoot for ‘Just-Enough’ Documentation
Agile was created in response to a software development environment where teams sometimes prioritized documentation and sign-offs over their applications’ actual performance. That doesn’t mean all documentation is bad, Kern said, but he stressed that less is almost always more.
“The team should be able to always look at, ‘Are we delivering the right amount of documentation? Is it too much?’” he said.
“I often tell people that I like to do just enough upfront design, just enough documentation – and even sometimes slightly less just to see, ‘Oh, you needed more, sorry, I'll add a little bit more’ – versus just blindly going to some level that might be too much. The agile mindset requires you to constantly think about the downstream feedback from your actions, and that includes documentation.”
Emphasize Pragmatism, Reflection and Empathy
Hardiker explained that he feels pragmatism, reflection and empathy are the most essential qualities for agile teams to embody.
“These are the three things that you need to exhibit in others, and yourself, and support teams to create what we look for, which is high-performing teams,” he said. By applying these qualities to their processes, Hardiker said, teams can ensure that they’re making the most of processes like two-week sprints (and even reevaluate whether they should be conducting two-week sprints at all).
“You should be reflecting to see if there’s a better way in which we can learn because let’s face it: There’s only one thing that’s truly irreplaceable in this world, and that’s time,” Hardiker said.
“And now those two weeks have gone, and we’re never going to get them back. But we’ve got two weeks again. So how can we make more out of it this time?”
Calvin Hennick is a contributing writer. His work appears in BizTech, Engineering Inc., The Boston Globe Magazine and elsewhere. He is also the author of Once More to the Rodeo: A Memoir. Follow him on Twitter @CalvinHennick.
© 2020 Nutanix, Inc. All rights reserved. For additional legal information, please go here.
