How Agile Development Can Lead to Better Results and Technology-Business Alignment

Studies show agile development works, and yet few companies follow its principles. Read this article to learn how your organization can manage the agile way.

By Thomas Wailgum
Mon, May 21, 2007
Page 5

Verizon Wireless’s VZ Navigator product, which provides users with turn-by-turn, voice-supported directions on their mobile devices and has become one of the company’s most popular mobile services, was heavily agile-influenced. Waghray’s team consisted of stakeholders from IT, sales, customer care, marketing, training and finance. The team’s main focus, Waghray says, was to develop the “simplest complete” solution right away, and then build upon that to make better solutions. “The reason it was successful was that the [agile] methodology encouraged constant communication and alignment across all stakeholders, leading to parallel development of not only the IT solution but also of training documentation, test cases, external and internal interface validation and development, and user communication to get them ready for launch,” he says.

To many of the businesspeople on the team, the results were shocking. They told Waghray that this project should have taken three times as long as it did, which was roughly eight weeks from start to finish. According to Waghray, the VZ Navigator project “made a significant and immediate impact on the bottom line and it has now enabled an organizational capability to do this with similar products.” It is “a culture and timing change,” Waghray says of the process, “but I have never gotten more accolades from a business project.”

Managing the Agile Change
Since agile teams are designed to be autonomous bands of rapid change agents making critical business decisions on the fly, the once-immutable laws of project management shift dramatically. Because waterfall’s typical 18-to-24-month development times are drastically reduced to two-week windows, every day of development and every conversation become critical. In Dury’s IT shop, mornings start with a team huddle and a breakdown of what everyone is responsible for completing that day. “We don’t need to talk about what gets done three weeks from now—this is what we want to do today,” Dury says. “We don’t want to lose days.”

It’s incumbent on CIOs to set the new expectations—teamwork, openness, collaboration—for everyone in their agile group. “There’s an expectation of collaboration. You can’t just go work in your own little world,” says Farm Credit Services’ Martin. “There’s also a new visibility into the work and, in some cases, the nonwork.”

Those team members who resist, however, will more than likely find themselves out of a job. (An old Persian saying seems appropriate for CIOs to remember: “The dogs bark, the caravan passes on.”) Scott Ambler, an agile expert who works as practice leader for agile development at IBM, suspects that many developers, requirements analysts, and data and testing staffers are worried about agile’s career-changing consequences. “They have likely worked on a slew of failures, and they often feel powerless to change things. Worse yet, they have the threat of outsourcing hanging over their heads,” Ambler says.

Continue Reading

Our Commenting Policies