Can a large organization adopt agile approaches to software development when the organization holds the notion that not all projects should be agile? In other words, can there be a mix of waterfall-type projects and agile projects in the same organization? The short answer is yes, however there is a cost that must be paid for this coexistence.

In transitioning to agile, most companies gradually transition a few teams at a time, learning from their successes and mistakes and applying the new knowledge to the rollout of new agile teams. This process can take months or years, depending on the size of the organization and the stability of management and agile champions.

The adoption usually begins as the result of an acknowledgement that a change is needed in order to remain competitive—or just to remain in business. What management often misses, however, is that there is typically a complete shift in the culture that must occur, as well, if the agile adoption is to be successful in the long run. This shift has effects not just on the development groups but on the entire organization.

Peter Senge's "Learning Organization" is an example of a corporate culture that is a values match for agile adoption. If your company does not fit this model and instead places emphasis on compliance without exception—metrics without regard to the behavior they engender, where mistakes are punished (often by firing) rather than being seen as an opportunity for learning—then what you have is a values mismatch, and you'll need to invest in the cost of cultural coexistence while still pursuing cultural change at all levels.

There are many costs incurred in keeping agile and more traditional methods as dual options in an organization. Some of these are easily overlooked and include:

1. Overhead. There is a lot of overhead involved in keeping multiple fundamentally different methods in place. Consider the cost of each of the following:

• Maintaining multiple repositories of process information, references, and other materials
• Supporting organizational processes that will differ (e.g. compliance/audit, governance, status reporting, and hiring and career development)
• The engagement model between teams and centralized groups will be different (e.g. how does a centralized architect interact with an agile team versus a traditional team?)
• Training in all of the above

2. Coordination. Efforts using the drastically different processes may experience complex communication and coordination challenges. For example, how will an agile team work with a separate, traditional team on dependencies (and vice versa)? How will we report progress on different types of projects and then convert the data into information needed to make portfolio decisions?

3. Tooling, contracting, and facilities. The introduction of agile brings with it some new approaches to tools, contracting, and facilities. Cross-functional, collocated teams need a shared workspace, and those who are not collocated need collaborative tools and solid communications infrastructure. Flexible contracts that are not fixed with regards to scope, time, or cost and resetting vendors and customer expectations are other modifications that must be addressed. While these changes need to happen in an agile transition anyway, having both the traditional cube farm and agile bullpens, for example, is going to increase cost in terms of management complexity.

4. Turnover. Experience from many agile practitioners indicates that some percentage of employee turnover is common. (This is not necessarily specific to agile, but occurs during any drastic cultural change.)

5. Opportunity Costs. If the company is moving to agile because of its benefits, what are the projects not implementing agile giving up by not moving to agile?

There are some possible benefits to allowing both to coexist, too. Consider these:

1. Comfort. Allowing both to coexist provides the opportunity for the company to stick its toe in the water before diving in completely. This may be seen as a more careful approach for companies without an appetite for major change. The change effort can expand (or not) throughout the organization at the pace at which the organization is comfortable.
2. Prioritization. This approach allows for value-based prioritization of change introduction objectives. There may be groups that are functioning sufficiently with the status quo. Do we need immediately to change projects that currently are effective?
3. Focused use of limited guidance. Allowing both to coexist may allow the limited number of available external agile consultants and coaches to focus their efforts on a few groups at a time, preventing the problems associated with just diving in blindly without assistance
4. Roll Back. Having a contingency plan (usually the old process) may make it easier for the company to fall back, should the agile transition not work or be rejected. 

During the transition, companies need to be wary of stagnation—i.e. the acceptance of average or mediocre performance. The roll out itself is not the goal. The improvements in product quality, decreases in time to market, increased employee morale, and increased customer satisfaction are all the real reasons for moving to an agile paradigm. Forgetting these ultimate goals can result in a half-hearted push to agility that instead follows a required MBO metric, leaving everyone happy with single- or double-digit increases in productivity rather than pursuing the triple-digit increases that are possible with the associated organizational and cultural change that are part of agile transitions. And, the costs of coexistence are not likely offset by single-digit improvements.

Regardless of the cost of coexistence, cultural change is a must if an agile adoption is going to stick in the long term. Leaving it for last only extends the uneasy truce and increases the likelihood that the organization will high-center, or reach a point where hard decisions about organizational change must be made in order for improvements to continue. Ignoring these issues leads to an inexorable slide back into the waterfall.

A transition to agile is much more than just a change in software development practices. It is a change in culture that will have an impact throughout your organization and anywhere else product development touches. Though it may seem like good risk mitigation to support multiple options for product development process, it is wise to consider the costs of doing so.