- Agility
- "Agile" Studies
- Agile Software Development Ecosystems
This chapter is from the book
This chapter is from the book
This chapter is from the book
Agile Software Development Ecosystems
If agility can be characterized as creating and responding to change, nimbleness and improvisation, conformance to actual, and balancing flexibility and structure, then ASDEs should help organizations exhibit these traits. They do so in several ways.
First, ASDEs focus on the set of problems described in Chapter 1—problems characterized by uncertainty and change—which require an exploratory approach. As the degree of uncertainty becomes greater, the probability that an Agile approach will succeed (over a Rigorous approach) increases dramatically, until at some level an Agile approach becomes the only type with a reasonable chance of success. As the level of uncertainty increases dramatically, it becomes unlikely that any methodology can help. No matter how good an exploration geologist you are, no matter how lucky, the inherent risk of exploring uncharted terrain remains. ASDEs improve the odds, but they don't guarantee success.
Second, ASDEs are intensely customer driven, which is both a characteristic and a risk factor. That is, no customer involvement, no Agile approach. It's basically that simple. But ASDEs advocate something even scarier—actually putting the customer in control. If we drive development from the perspective of value first and traditional scope, schedule, and cost second, then customers must be actively involved.
Third, ASDEs focus on people—both in terms of individual skills and in terms of collaboration, conversations, and communications that enhance flexibility and innovation. As Alistair says, "Software development is a cooperative game." Most traditional "methodologies" place 80 percent of their emphasis on processes, activities, tools, roles, and documents. Agile approaches place 80 percent of their emphasis on ecosystems—people, personalities, collaboration, conversations, and relationships.
Fourth, ASDEs are not about a laundry list of things that development teams should do, they are about the practical things a development team actually needs to do—based on practice. The stories about what methodology manuals contain versus what development teams actually do are legendary. Furthermore, needs change from project to project and from iteration to iteration within a project. Alistair uses the word "embellishment," which means that many methodologies get "embellished" with artifacts, tasks, roles, techniques, and more that creep into the methodology because someone thought they really should be there, even though they themselves could never find the time or inclination to actually do them.
By articulating what ASDEs are and what they are not, people can decide which, if any, of the premises, principles, and practices to use.
"Never push Lean Development beyond its limits," is the twelfth principle of Bob's Lean Development. This principle can be extended to all Agile approaches. Every approach to a problem carries the risk of loss. If we don't understand the domain in which some methodology or practice is applicable, if we don't understand the risks associated with a practice, if we don't understand the business risk and opportunity, then we may apply the wrong practice to a particular problem.
One last characteristic of ASDEs—they may be inefficient. Production drilling for oil is about efficiency and cost control. Exploration drilling is about risk management, improvisation, intuition, and occasional lucky guesses. Exploring is often messy, full of fits and starts and rework. Companies that want to explore—to innovate—need to allow for some inef-ficiency.