"You've got business and IT working together, collaborating, and that's what will make the difference," Bargmann says. "At first, everyone feels like they're 'forced' to work together, but once it becomes apparent that the goal for both teams is continual improvement, that's when you start to see the value," he says.
With an agile methodology, if products are headed in the wrong direction, problems will be caught early, says Klaussen, and the methodology is designed to allow for changes in the overall product roadmap without a lot of waste — in terms of capital, resources, and time. Those are real benefits that are seen and felt by all stakeholders — the business side, the developers, and the customers, he says.
"The agile process encourages the team to build the project in a way that can touched, felt, played with, and tested on a very frequent basis. It means building the product in slices based on demonstrable value, like end-user functionality, that often require a little bit of every part of the solution working together," says Klaussen, so developer teams often are integrating front-end, middleware and back-end components frequently to ensure functionality rather than trying to cram all the pieces together at the last minute.
"What this eliminates," says ESPN's Bargmann, "is the situation where your developer teams have estimated, say, a nine-month project window, and then they realize they can't get it all done, or they have to go back and integrate other features, or fix bugs. So they come back to the business stakeholders and go, 'Sorry, it's gonna take an extra couple weeks,'" he says.
With Agile, Klaussen says, "You have the vision, you create the plan. But when reality shows up, when feedback needs to be incorporated, when business objectives change, then following a methodology that accounts for this enables the team to be more resilient and the delivered outcome to drive actual business value," he says.
While in traditional software development frameworks, incorporating feedback into the product roadmap was seen as a failure, within Agile, it's seen as a success, Klaussen says.
"This is a success because the team learned they didn't have it quite right and were able to fix it quickly. Most other methodologies treat this is a failure. It wasn't spec'd right, and then the blame game ensues. But there is a human element in listening, spec'ing and implementing a solution. And the more the team creates a loop that checks that they are hearing and creating meaningful functionality, the faster they learn how to get it right," Klaussen says, and thus, the greater value to the business.
Going Agile Isn't the Whole Answer
Of course, 'going agile' in name alone won't change much, says Bargmann. You have to make at least a partial leap to a true, product- and business-outcome-focused mindset, he says.
Sign up for CIO Asia eNewsletters.