There is no Agility for Dummies. Agility isn’t a silver bullet. You don’t achieve it in five easy steps. So what is it? For myself, I’ve characterized agility in two statements:
Agility is the ability to both create and respond to change in order to profit in a turbulent business environment.
Agility is the ability to balance flexibility and stability. In an uncertain and turbulent world, success belongs to companies that have the capacity to create change, and maybe even chaos, for their competitors. Creating change disrupts competitors; responding to change guards against competitive thrusts. Creating change requires innovation: developing new products, creating new sales channels, reducing product development time, customizing products for increasingly smaller market segments.
Some people mistakenly assume that agility connotes a lack of structure, but the absence of structure creates chaos. Conversely, too much structure creates rigidity. Complexity theory tells us that innovation—creating something new in ways that we can’t fully anticipate—an emergent result—occurs most readily at the balance point between chaos and order, between flexibility and stability. Scientists believe that emergence, the creation of novelty from agent interaction, happens most readily at this “edge of chaos.” The idea of enough structure, but not too much, drives agile managers to continually ask the question, “How little structure can I get away with?” Too much structure stifles creativity. Too little structure breeds inefficiency. This need to balance at the edge of chaos to foster innovation is one reason process-centric methodologies often fail. They push organizations into over-optimization at the expense of innovation. Agile organizations don’t get lost in some gray middle ground; they understand which factors require stabilization and which ones encourage exploration. For example, in a high-change product development environment, rigorous configuration management stabilizes and facilitates flexibility. The problem with many traditional software development and project management approaches is that they have too narrowly defined the context; that is, they’ve planned projects to a great level of task detail, leaving very little room to adapt to changing conditions. (Adapted from Agile Project Management, 2009).
This post is from Adaptive Imagineering by Jim Highsmith. Click here to see the original post in full.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.