This chapter is from the book
This chapter is from the book
This chapter is from the book
Barriers or Opportunities
One of the constant excuses, complaints, or rationalizations about some agile practices are “They would take too much time,” or “They would cost too much.” This has been said about short iterations, frequent database updates, continuous integration, automated testing, and a host of other agile practices. All too often companies succumb to what colleague Israel Gat calls the “new toy” syndrome—placing all their emphasis on new development and ignoring legacy code. Things like messy old code then become excuses and barriers to change. Some activities certainly are cost-prohibitive, but many of these are artificial barriers that people voice. Experienced agilists turn these barriers into opportunities. They ask, “What would be the benefit if we could do this?”
Working with a large company—and a very large program team (multiple projects, one integrated product suite) of something over 500 people—several years ago we wanted them to do a complete multi-project code integration at the end of every couple of iterations. The reply was, “We can’t do that, it would take multiple people and several weeks of time out of development.” This was from a group who had experienced severe problems in prior releases when they integrated products very late in the release cycle. Our response was, “What would the benefit be if you could do the integration quickly and at low cost?” and, “You don’t have a choice; if you want to be agile you must integrate across the entire product suite early and often.” Grumbling, they managed the first integration with significant effort, but with far less time than they anticipated. By the time 3–4 integrations had occurred, they had figured out how to do them in a few days with limited personnel. The benefits from frequent integration were significant, eliminating many problems that previously would have lingered, unfound, until close to release date.
Most, but not all, of the time perceived barriers to change (it costs too much) really point out inefficiencies—opportunities to streamline the process and enhance the organization’s ability to adapt. Agile development demands short-cycle iterations. Doing short-cycle iterations demands finding ways to do repetitive things quickly and inexpensively. Doing things quickly and inexpensively enables teams to respond to changes in ways they never anticipated previously. Doing things quickly and inexpensively fosters innovation because it encourages teams to experiment. These innovations ripple out into other parts of the organization. Lowering the cost of change enables companies to rethink their business models.