Over the last two years I’ve been involved with several clients who were trying to rollout Agile practices across the enterprise. The stages that each of these organizations moved through were very similar as were the problems that they faced. It is possible to anticipate some for these problems and to lessen their impact but only if there is a known roadmap for the overall strategy. Although no two organizations follow exactly the same path, nor have the exactly the same timing, it is possible to exact the major trends and patterns. What follows is an overview of those major trends and patterns.
The Path to an Agile Enterprise
The diagram below summarizes the overall path that organizations follow when transitioning from a Non-Agile environment to an Agile environment. [The different stages in this diagram are arbitrary. By that I mean that there was no standard measure by which companies were judged when moving from one state to another. As a result this diagram is certainly up for discussion, and I’d be interested in your thoughts and comments.]
The transition is from left to right with each stage having it’s own problems and challenges. An organization may fail at any point along the path. Whether an organization will be successful in the transition to an Agile enterprise depends upon how willing the organization is to dealing with the issues raised, and how willing the organization is to change it’s culture. I’ll have more to say about that at the end of this series but for now I’d like to remain focused on the overall path.
A trip down the path
At the very start we have a Non-Agile enterprise. These are organizations to which Agile practices have not been introduce and yet the prevailing attitude is that Agile methods do not have anything to offer over existing methodologies and practices. This attitude is often arrived at with little or no understanding of what Agile methods are or what benefits they can provide.
There are several ways in which Agile methods can be initially introduced. The most common way is be developers reading existing literature  and implementing some of the practices into their own work. This creates interest from other developers and management. The ideas gradually spread. Once sufficient momentum has been established, the organization may want to proceed with experimentation on one or several small projects. This phase of Agile adoption is usually limited in both scope and budget. Enterprises will feel that this is a natural way to experiment with new ideas and techniques while at the same time limiting the risks involved.
There will be lessons, both good and bad, learnt from the completion of the experimental projects. The overall consensus will be that there were enough lessons learnt to move forward. At this point the Enterprise will begin to accept that there are advantages to Agile methodologies and will begin a more systematic rollout. This pilot phase will be more organized but will still be limited in impact. Pilot projects will be seeded through the group or department. These pilot projects will be more significant than the previous experimental projects in terms of budget, team members, and visibility to both senior management and external clients.
Agile methods are excellent at highlighting and raise awareness of impediments. The nature of these impediments changes over time. Initially they are issues that directly effect the development team; poor tools, inefficient build and source code management issues. As projects teams get more experienced, quality issues come into focus; test driven development, continuous integration, refactoring etc. Even further into Agile adoption, organizational issues start to emerge, such as project staffing, individual compensation, and promotion (see below). Naturally, the emergence of these problems can create clashes between Agile team members (who are pushing for change) and those outside the team (who feel that their position is threatened).
If the enterprise is serious about Agile adoption and has support from senior management, some of the issues will be addressed. The first changes will be tactical; those changes that are seen to be immediately needed to support the Agile teams. This might include changes to use a simpler build process, the introduction of continuous integration or reducing the numbers of meetings that teams are expected to attend. These initial changes to the organization are typically limited in scale (confined to a particular group or department) and perceived risk.
With growing acceptance of Agile in the enterprise more and more teams will be interested in adopting Agile on their projects usually resulting in a sudden increase in the number of Agile projects. This sudden increase in Agile teams will result in different teams taking up different Agile practices, or adopting similar practices but implementing them in different ways. For example: some teams will do 2 week iterations, some will do 3 week iterations and some teams will do 4 week iterations; some teams will have daily team meetings, some will not; and different teams will estimate story points in different ways. The response to these different variations will be greater formalization of the Agile methodology. This formalization will usually be undertaken by a project management office (PMO) who will want to understand what is meant by “Agile within the context of the Enterprise”. The PMO will try to define Agile practices such as terminology, length of iterations, reporting and metrics.
Following the formalization or standardization of the Agile process, the enterprise will be ready to attempt a large scale rollout. This is a rollout of Agile methods across several departments or organization. The types of projects attempted will be far more ambitious and may include Scrums-of-Scrums, significant visibility to senior management and increased corporate risk (associated with potential large project failure).
These enterprise-wide projects will raise enterprise-wide issues (compensation, promotion, roles and responsibilities) in addition to the usual local problems (tools, build times, quality issues etc). These challenges will be the most difficult for the enterprise to address because they will directly challenge the culture of the organization and will require changes to peoples’ behavior and day-to-day practices. In addition some individuals will perceive that their position and authority within the organization are at risk. In order to make a successful transition [to an Agile enterprise], any risk (either real or perceived) associated with the introduction of Agile development needs to be resolved promptly by senior management.
The enterprise that has successfully negotiated this path is an enterprise that is able to manage constant change within the organization; an enterprise that is closely in tune with their customers, that can rapidly change according to changing business conditions at incremental cost (rather than exponential cost) and that has employees who are constantly learning and innovating.
I’ve presented an outline of the stages through which an organization moves when transitioning to Agile, and provided a brief outline of each of those stages. In part 2 of this series I’ll provide a strategy for how the transition can be made and when some of the important activities need to occur. I anticipate that I’ll post this article in about 2-3 weeks time.
The final part of this series is (for me) the most interesting. I’ll discuss some of the organizational impediments that one may encounter along the way, and what can be done to resolve these impediments. The final articles are still taking shape so I’m not sure if this will be one big article or two smaller articles … I guess you’ll have to stay with me to find out! =)
 My recommended readiing list.