Every year, people talk about the future of IT, which is shorthand for, "Some big changes may be in the works." In the last year, we've had to revise that sentence to read, "Some big changes are definitely in the works." Agile practices will be a critical tool for making this transition successfully, but not because of velocity. At least, that won't be the primary virtue of Agile that helps with the transition.
One of the Founding Fathers of Agile, Jim Highsmith, recently commented on his blog about an MIT study that surveyed one face of this mountain of change:
The implications of these changes in emphasis could be significant in terms of mindset and capabilities in and out of IT departments. From a focus on standardization, optimization, and cost control, the focus shifts to innovative uses of emerging technologies such as social media, cloud computing, and mobile devices; speed to market; flexibility to follow changing opportunities, and building new products and services.
Both Agile and Lean have an ethos that, at least on paper, acknowledges the noble failure. "Fail fast" is part of the Agile credo. Although it sounds as though it contradicts the "fail fast" approach, Lean's admonition to delay decisions for as long as possible is actually very complementary. The first draft of anything, from automotive design to software architecture to student papers, always contains elements that could be improved or that are just flat-out wrong. Practices that sit beneath the banner of Agile or Lean, such as set-based development, provide further ways to make mistakes and overcome them.
To a large extent, these practices deal with the easier varieties of failure. Prototyping a feature quickly, so that you can invite feedback when you actually have enough time to respond to it, is an extremely valuable technique for lowering the risk that you build something the wrong way. You need a different approach to identifying the features that you should not build, period.