The Agile Vision
In the end, the positive answers to two questions form the essence of Agile Project Management: "Are you delivering innovative products to your customers?" and "Are you excited about going to work every day?" Agilists want to build innovative productsproducts that test the limits of our abilities as individuals and project teamsand create a work environment in which people, as individuals and in teams , can thrive.
The Changing Face of New Product Development
New product developmentbe it for industrial products, consumer products, or internal business processesis being driven by two resolute forces: the continuing demand for innovation and the plunging cost of change (low-cost exploration). As the uncertainty about the outcome of a development effort increases , as the complexity of the interactions of design variables daunts cause-and-effect analysis, exploration through experimentation becomes the most effective and reliable mode of discovery. When we can conduct 1,000 experiments a day for $10 apiece, creating elaborate designs that would take a month to complete otherwise makes no sense. On the other hand, conducting 5,000 random experiments makes no sense either. Good experiments require good experimental design.
It is hard to overstate the impact of low-cost exploration on product development or the competitive advantage that will accrue to those companies that can adjust their development and managerial processes appropriately. A significant element of this strategy will involve software and the manipulation of bits rather than atoms , driving a low-cost exploration product development process that should strive to:
- Fill products with "bits"
- Create a bit-oriented product development lifecycle (i.e., model and/or simulate products in software as far into the lifecycle as possible)
- Relentlessly drive down the cost of changing bits (low-cost iteration)
- Develop people and processes capable of the above strategies (agile people and processes)
Embedded software has rapidly become a critical piece of industrial products. Cell phones now boast a million or more lines of code. Automobiles have microprocessors for everything from fuel injection to transmission shifting. Airplanes are fly-by-wire, controlled completely electronically .
Softwaredeveloped well, of courseis more flexible than hardware. In fact, drastically shortening the product development lifecycle forces hardware engineers to lock in hardware designs earlier than they would like. Software's flexibility is often used to correct hardware problems or add new features after hardware designs are fixed. So the more "bits" there are in a product, in general, the better. As bits replace atoms, more product features can be developed faster and with greater flexibility.
But we can't drive a bit, or sit on one, or use one to hit a golf ball. At some point, atoms must be assembled into products that we can use. The critical question is, when do we assemble the atoms? There is a furniture manufacturer in West Virginia that completes its entire product design process in software. At the end of the design phase, the software generates instructions to manufacturing robots, and the furniture parts are cut and assembled . The more chemical compound and biological response information there is available in large databases, the further into the drug development process companies can go before lengthy and expensive activities such as animal testing have to begin. Simulations, modeling, and prototyping, for a wide array of products, are all increasingly being done in software prior to any physical assembly. Once physical assembly begins, flexibility suffers.
The point is that the longer teams can manipulate bits rather than atoms, the more effective the product development process can be. So two strategies are critical: increase the number of bits in products and manipulate bits rather than atoms as deep into the development process as possible.
Agile People and Processes Deliver Agile Products
There is, however, a caveat to the above strategies. A company's development and project management processes, and its executive support and performance measurements, must encourage experimentation, exploration, and low-cost iteration. Authors Moshe Rubinstein and Iris Firstenberg (1999) of the University of California write about "minding" organizations, a term that coincides with "adaptive." "The minding organization behaves like a living organism, in which adapting is central to vitality and survival. Overly rigid and detailed planning must give way to a strategy that combines less planning and more adapting."
Agile, adaptive project management and development processes support exploratory product development. Managers and executives need to understand the kinds of projects in which these processes can best be used and how to encourage employees in their use. As Harvard Business School professor Stefan Thomke (2003) writes , "Experimentation matters because it is through learning equally what works and what doesn't that people develop great new products, services, and entire businesses. But in spite of the lip service that is paid to 'testing' and 'learning from failure,' today's organizations, processes, and management of innovation often impede experimentation." Implementing a low-cost exploration strategy will require a substantial cultural change within the development staff, project manager, and executive ranks of many organizations.
Exploratory processes require adaptive people and adaptive organizations. There are individuals who excel in production environments, those who strive for repeatability and precision through the use of prescriptive processes and performance measures. Every organization requires production processes for a portion of its operations. But every organization also needs exploration processes, those that excel in delivering new products, new services, and new internal business initiatives. Unfortunately, the project cultures and management controls for exploration and production are usually at odds with each other, causing organizational schizophrenia . Great organizations will find a way to deal with both exploration and production processes. Others will languish behind.
So how do organizations deal with two distinct process models that have seemingly incompatible cultures? I think the answer lies in the word "adaptation." Adaptive cultures adjust to the situation, while production cultures have difficulty changing. When the business environment was more stable, production cultures could thrive. However, as the pace of change has accelerated, the mix of exploration versus production activity in organizations has shifted, creating a competitive advantage for those companies with predominantly adaptive cultures.
Culture then identifies a critical piece of the agile vision, which might be expressed with a simple axiom : Don't work in Dilbert's company, and don't be Dilbert. Dilbert's company is the epitome of authoritarianismthe exact opposite of self-organizing . Dilbert complains, but he takes no responsibility for changing his environment. Dilbert and his cohorts lack self-discipline. Agile social architectures have both and thereby deliver innovative products and create great places to work. As Andrew Hill (2001) relates in his book about John Wooden and UCLA basketball, "The Bruins were built on speed, quickness, a tough man-to-man defense, a withering zone press, and a relentless fast break. Now, there may be some kid in America who grows up dreaming of playing slow-down, highly structured, Princeton-style basketball , but I've never met that kid. There was something intoxicating and captivating about the pace and attacking style of the Bruins." I think most product developers want to work on UCLA-style "agile" projects.
A grand vision? A utopian vision? An impractical vision? Possibly. I once received an email response to a message I posted on an online forum in which I argued that traditional project management is often authoritarian and high ceremony. "Jim, your sentence implies that authoritarianism and high ceremony are 'bad' things. Do we really care whether or not something is authoritarian, or should we judge it solely by its ability to deliver value to the customer?" My response was, "I care deeply." Delivering valuable products is important, and it's critical to project management success. No project team can exist for long without delivering value to its customers. But in the long run, how we deliver, how we interact at work, and how we treat each other as human beings are even more important.