- Introduction
- Stage 1: Development Projects Are Unsuccessful
- Stage 2: Developers and Customers Grow Apart
- Stage 3: Agile Process (or Almost Anything, Really) Becomes Attractive
- Incremental Agile Implementation
Stage 3: Agile Process (or Almost Anything, Really) Becomes Attractive
Many organizations have become thoroughly comfortable with this customer/user -IT/development/engineering relationship. Like a dysfunctional marriage, there are fights, pain, anguish, blame, and failures. But the relationship is well known to everyone. They know their roles, deflections, and movements. Even if there is significant waste and unhappiness, everyone is familiar with it. Agile processes may be better. But agile is an unknown territory that requires completely new relationships. What could possibly make someone want to change?
Desperation
One reason to change is desperation. The survival instinct causes people to abandon old ways of acting and adopt new ways. I've successfully implemented agile processes at a number of product companies when their very survival depended on the successful shipment of a product:
Individual, Inc. hadn't had a release of their primary product, Newspage, in over six months.
CoreTek needed a release of a fiber optic subsystem for an industry show to demonstrate viability and competence.
IDX Radiology needed to demonstrate a radically new teleradiology product to partners and investors to capture a market niche.
PatientKeeper needed to ship a release to stabilize the customer base quickly so that it could move on to a radically different product approach.
In these situations, people were willing to explore new approaches, forego preconceived ideas and previous methods, and take risks. The risk of failing to create a new product release was greater than the risk of changing the relationships. These were all product companies; if the products failed, the company failed.
Repeated Failure
People also get desperate in the face of repeated failure. There's an old saying that craziness is the belief that outcomes will improve despite making no changes. People repeat the same thing over and over, hoping that something better will result. I've successfully implemented agile processes in these organizations. At one large energy company, a project to improve asset recordkeeping had failed twice. Both failures were visible and expensive. The third time, they asked me and ThoughtWorks to implement Scrum and extreme programming (XP) processes. No questions were asked, no reservations were made. And the project is succeeding.
Vision
Another reason to change is visionan understanding that things can be different and better. The people who take this approach are known as early adopters. (See Geoffrey Moore's Crossing the Chasm, HarperBusiness, 1999.) When the early adopters are in small, self-contained projects, change is possible if everyone agrees to experiment. Many single-team projects have succeeded with XP and Scrum.
In some instances, the visionary was at the top of the IT organization. The IT organization was no more successful or less successful than its peers. But the CIO, CTO, or president had learned about Agile and wanted it implemented. These implementations would change a large number of relationships: customer to customer, customer to developer, developer to developer, and developer to operations. An incremental change process was required in these implementations. Agile processes were introduced gradually and incrementally; not all practices were implemented at once.