Forbes.com

How Agile Can Bring Innovation to Customers Faster

Companies far beyond the tech industry are applying Agile methods to everything from marketing to corporate strategy.

Di Greg Caimi

First published on agosto 02, 2016
Tempo di lettura min.


This article originally appeared on Forbes.com. When you think of John Deere, you probably picture old-school machines tilling soil in the heartland or mowing a suburban lawn. But you might be surprised to learn that this 179-year-old, Illinois-based manufacturer is using new millennium tactics honed in Silicon Valley to speed innovation. About six years ago, Deere’s Global Technology Innovation Network, an internal team tasked with discovering potentially disruptive technology, started schooling its team on Agile methods in a bid to speed up its product development. Now the team can turn an idea into a working prototype in about eight months, a process that used to take a year and a half or more. I recently discussed Deere’s use of Agile in more detail in a recent Bain Brief that I cowrote with my colleagues Darrell Rigby, Steve Berez and Andrew Noble. Agile is old hat for IT executives, who have been applying its small-team approach and rapid feedback loops for more than 25 years, and for good reason. Agile methods have more than tripled average success rates in tens of thousands of software development projects. In large, complex projects, Agile’s success rate jumps to six times that of conventional methods. And then there’s the ultimate bonus: The Agile approach leads to higher satisfaction among both employees and customers. Now companies far beyond the tech industry are applying Agile methods to everything from marketing to corporate strategy. Here’s an example to help you visualize the power of Agile: Let’s suppose an apparel retailer wants to overhaul its dressing rooms, sensing an opportunity to improve both customer experience and sales. After a series of brainstorming sessions and workshops, the group tasked with the redesign identifies three key features that should define the store’s new dressing rooms: “Magic mirrors” that enable customers to hold up an outfit and see what they’d look like while wearing it, without having to actually try it on. A delivery system that enables customers to select an item from a digital catalog and have it sent directly to their dressing rooms, either immediately or at a prearranged time. Remote stylists who can offer personalized fashion advice via video chat and send recommended items directly to a customer’s dressing room. In a conventional development cycle, the engineering department would work on all three features concurrently, so the new dressing room experience could be unveiled at stores all at once (with plenty of fanfare). The company might plan for a two-year cycle, but let’s estimate that the process takes 18 months from start to finish in this scenario. Despite the early finish, grappling with three complex tasks simultaneously would waste 40% of the team’s time on “context switching”—changing gears as engineers jump from working on one feature to another. Interrupting workflow like that forces team members to pause, restart and refocus their problem-solving processes over and over, killing productivity. In contrast, an Agile approach would split the project into segments and then prioritize—ruthlessly, if necessary—the key features to develop. The team could then focus entirely on completing one segment at a time. To determine priorities, engineers could rank each feature on a scale of 1 to 10, based on its value to the customer or other metrics, such as projected revenue and the resources required to create it. In this case, the team might determine that the digital-catalog delivery system could generate the most revenue with the lowest upfront investment. So the team assigns the delivery system a value of 10. The remote stylist function will be slightly harder to design and may not have quite as big an impact on sales, so the team assigns it a value of 7. And the magic mirrors present the biggest technological challenge with perhaps the lowest revenue potential, though they’re sure to wow customers. The mirrors get a value of 5. If the engineers deliver all three features simultaneously after 18 months, the company will reap the benefits of each for six months in the two-year cycle. However, if the team takes an iterative, Agile approach, developing each feature independently in successive six-month time frames, they’ll be able to get more use out of the most important feature—the delivery system—rolling it out with a full 18 months remaining in that cycle. The second-most-important feature, the remote stylists, will generate benefits for 12 months, and they’ll get six months out of the magic mirrors. The engineering team also wastes less time and energy switching gears between projects. To be sure, Agile won’t succeed without management support and proper implementation. But for companies trying to solve complex problems with unknown solutions in shifting market conditions, Agile can produce similarly excellent results—even outside the IT department. For a deeper look at Agile methods, I recommend reading “Agile Innovation.” Greg Caimi is a San Francisco-based partner at Bain & Company and leads Bain’s Digital practice in the Americas.

This article originally appeared on Forbes.com.

When you think of John Deere, you probably picture old-school machines tilling soil in the heartland or mowing a suburban lawn. But you might be surprised to learn that this 179-year-old, Illinois-based manufacturer is using new millennium tactics honed in Silicon Valley to speed innovation.

About six years ago, Deere’s Global Technology Innovation Network, an internal team tasked with discovering potentially disruptive technology, started schooling its team on Agile methods in a bid to speed up its product development. Now the team can turn an idea into a working prototype in about eight months, a process that used to take a year and a half or more. I recently discussed Deere’s use of Agile in more detail in a recent Bain Brief that I cowrote with my colleagues Darrell Rigby, Steve Berez and Andrew Noble.

Agile is old hat for IT executives, who have been applying its small-team approach and rapid feedback loops for more than 25 years, and for good reason. Agile methods have more than tripled average success rates in tens of thousands of software development projects. In large, complex projects, Agile’s success rate jumps to six times that of conventional methods. And then there’s the ultimate bonus: The Agile approach leads to higher satisfaction among both employees and customers. Now companies far beyond the tech industry are applying Agile methods to everything from marketing to corporate strategy.

Here’s an example to help you visualize the power of Agile: Let’s suppose an apparel retailer wants to overhaul its dressing rooms, sensing an opportunity to improve both customer experience and sales. After a series of brainstorming sessions and workshops, the group tasked with the redesign identifies three key features that should define the store’s new dressing rooms:

“Magic mirrors” that enable customers to hold up an outfit and see what they’d look like while wearing it, without having to actually try it on.
A delivery system that enables customers to select an item from a digital catalog and have it sent directly to their dressing rooms, either immediately or at a prearranged time.
Remote stylists who can offer personalized fashion advice via video chat and send recommended items directly to a customer’s dressing room.

In a conventional development cycle, the engineering department would work on all three features concurrently, so the new dressing room experience could be unveiled at stores all at once (with plenty of fanfare). The company might plan for a two-year cycle, but let’s estimate that the process takes 18 months from start to finish in this scenario. Despite the early finish, grappling with three complex tasks simultaneously would waste 40% of the team’s time on “context switching”—changing gears as engineers jump from working on one feature to another. Interrupting workflow like that forces team members to pause, restart and refocus their problem-solving processes over and over, killing productivity.

In contrast, an Agile approach would split the project into segments and then prioritize—ruthlessly, if necessary—the key features to develop. The team could then focus entirely on completing one segment at a time.

To determine priorities, engineers could rank each feature on a scale of 1 to 10, based on its value to the customer or other metrics, such as projected revenue and the resources required to create it. In this case, the team might determine that the digital-catalog delivery system could generate the most revenue with the lowest upfront investment. So the team assigns the delivery system a value of 10.

The remote stylist function will be slightly harder to design and may not have quite as big an impact on sales, so the team assigns it a value of 7. And the magic mirrors present the biggest technological challenge with perhaps the lowest revenue potential, though they’re sure to wow customers. The mirrors get a value of 5.

If the engineers deliver all three features simultaneously after 18 months, the company will reap the benefits of each for six months in the two-year cycle. However, if the team takes an iterative, Agile approach, developing each feature independently in successive six-month time frames, they’ll be able to get more use out of the most important feature—the delivery system—rolling it out with a full 18 months remaining in that cycle. The second-most-important feature, the remote stylists, will generate benefits for 12 months, and they’ll get six months out of the magic mirrors. The engineering team also wastes less time and energy switching gears between projects.

To be sure, Agile won’t succeed without management support and proper implementation. But for companies trying to solve complex problems with unknown solutions in shifting market conditions, Agile can produce similarly excellent results—even outside the IT department.

For a deeper look at Agile methods, I recommend reading “Agile Innovation.”

Greg Caimi is a San Francisco-based partner at Bain & Company and leads Bain’s Digital practice in the Americas.