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:
- 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
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?
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
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.)
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