How Software Leans toward Agility and Experimentation
Agility depends on learning and experimentation. You make decisions, execute, and then re-evaluate. Software development seems like a natural medium for experimentation and agility, because, in a physical sense, software is relatively easy to manipulate.
You can set aside a working version of some code and try something new, and if it fails, you can easily go back to what worked. Although this is an oversimplification because software development has systemic costs, when compared to building systems in hardware or working in a domain like manufacturing, it’s easier to make changes using software.
Because software is so malleable, it would seem to lend itself more toward agility than traditional brick and mortar businesses. An article in Forbes provides a counterexample of this notion, however. Using the Spanish-clothing retailer Zara as an example, Steve Denning illustrates how the barriers to agility are less about physical constraints—though they do play a role—than culture and a willingness to experiment and defy conventional wisdom. Denning notes:
Zara does almost everything that a cost-conscious traditional manager wouldn’t do. Instead of cutting costs in each activity of the firm, Zara optimizes operations for the performance of the firm as a whole.
Zara in fact implements the basic principles of agile software development—total focus on delighting the customer, working in self-organizing teams, coordinating work in short cycles driven by customer feedback, values of trust and openness, and horizontal communications.
As a contrast, Denning mentions that Zappos, before joining forces with Amazon, faced barriers to optimizing its supply chain from its board of directors, who were focused on optimizing traditional metrics. He writes, “In effect, they were proposing to destroy the very things that had made Zappos unique and successful.”
This might sound familiar to those who have been in organizations that have halfheartedly embraced agile software development. It’s hard for teams to resist the temptation to adapt agile practices before they see how they work, using traditional metrics to evaluate and optimize their process.
For example, teams may forgo unit testing or defer thinking about deployment because of the time it adds to early parts of the development cycle. These teams ignore the possible benefits to the entire process. Any change in process will have a cost; and if you want a chance to experience the benefits of the new process, you need to be willing to accept some risk and change your model of how things work.
In a later article in the series, Denning explores what the manufacturing industry can learn from software in order to become agile. If a company that deals in physical processes can be agile, a company that delivers software also can be. There are many things software teams can learn from examples in manufacturing, especially since lean software development is grounded in lessons learned from manufacturing.
