Piecemeal Agile adoption

There has always been a lot of tension in the agile development community over the extent to which agile practices need to be adopted in order to have significant, or any, benefit. Extreme Programming proponents, for example, have long held that every single one of the system's rules must be adopted in order for it to work; it's a synergistic process not amenable to piecemeal implementation. It's not unusual to hear other Agile proponents suggest that "failures" of their favorite systems are due to an incomplete adoption of the principles and processes they espouse, an argument with varying degrees of validity which is not without the potential for bias.

My feeling with regard to the piecemeal adoption of either Agile development or Agile operations is that there are certainly components of the associated principles which must be taken up simultaneously or not at all, but that it's rarely necessary to rigidly and completely implement every single method they incorporate in order to see some benefit from them. It's true that some practices make little sense without others; the idea that you should push support functions outside the organization, for example, does nothing but cause trouble unless you have also taken to heart the need to bullet-proof and standardize your internal systems to allow that sort of easy interaction. On the other hand, you can certainly adopt rapid, iterative release cycles without pushing power out to the organization's periphery... those principles don't collide. I've taken a similar stance on the adoption of ITIL and similar frameworks. As long as you consider carefully what you will and won't implement, you can get a great deal of benefit from pulling in only certain parts at a time, where they make sense for your organization. In most large IT organizations, it's impossible to simply adopt any new system from whole cloth at a given point anyway, so there is inevitably some mixing and matching to deal with no matter your intent.

The CIO Dashboard has posted on some of the ground rules for agile implementations alongside more traditional methodologies. Although they are primarily looking at it from a development perspective, the discussion verges into system architecture, which provides some models for considering the argument from the operations perspective as well.

The three pillars they identify in what they term "Architecture Driven Agile" are:

• Architecture


• Release Planning


• Organizational Structure

All three of those factors are also critical in the adoption of Agile Operations.

A solid system architectural framework may be the most important among them. Agile Operations allows for frequent minor, iterative changes, and accepts the probability that some of these may result in upset and breakage in the production environment. It's acceptable only because it assumes that your basic core architecture can remain functional and unaffected and that your release planning (number two on their list) and change management can rapidly roll back problematic updates. The changes you make, however, have to hang inside a solid, unchanging architectural framework, or you can't be certain what is breaking, or how to roll it back, or even what your initial limits should be.

Organizational structure, which might also simply be called "security" in the operations perspective, fills a similar role in providing a framework inside which changes can be safely made and reversed. It's important for the team to coordinate their efforts with the staff they may be affecting, and that the roles and rules associated with operations management are clear on both sides. Without this, communication usually suffers, and tight control over release planning and change management is impossible. "Control" is probably the wrong word there; it's not always necessary to directly control changes so long as it's possible to strictly monitor it. A working agile system might not require a lot of overhead intervention but certainly those responsible for overseeing it should be constantly aware of what is happening.

With those elements in place, other aspects of "pure" agile may be neglected or put off without serious long-term consequence.