The Cost of Coexistence


Some organizations want to make the transition to agile, but aren't ready to trade in their old ways overnight. They'd rather spend some time getting to know agile—letting it coexist alongside already established, traditional methodologies. In this article, Michele Sliger and George Schlitz explain that such coexistence is possible, but that there is a cost of coexistence of which all organizations should be aware.

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
  1. 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?

  2. 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.

  3. 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.)

  4. 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?

About the author

Michele Sliger's picture Michele Sliger

Michele Sliger has extensive experience in agile software development, having worked in both XP and Scrum teams before becoming a consultant. As a self-described "bridge builder," her passion lies in helping those in traditional software development environments cross the bridge to agility. Along with co-author Stacia Broderick, their book The Software Project Manager's Bridge to Agility focuses on the topic, helping PMI-trained project managers make the transition. Michele is a Certified Scrum Trainer (CST) and a certified Project Management Professional (PMP). If you have a question, or would like help with your agile adoption, Michele can be reached at

About the author

George Schlitz's picture George Schlitz

George Schlitz is co-founder of BigVisible Solutions, a consultancy that focuses on large-scale agile adoptions in diverse industries. Bringing knowledge of agile, lean, systems thinking, and theory of constraints to his clients. His passion is helping clients overcome the challenges of enterprise change using a wide array of techniques. George's leadership experience in business and as a military officer help him excel at coaching and mentoring of leaders and teams. George is a Certified Scrum Coach (CSC) and a certified Project Management Professional (PMP). If you have questions, or would like help with large scale agile endeavors of any kind, George can be reached at

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!