Agility has to serve objectives

It's possible to get so wrapped up in discussing DevOps or agile development, or agile anything, really, that you miss the point of the concept: to better serve the "customers" of the processes you are agilifying. In fact, I suspect much of the bad rap that agile adherents get is a result of spending a little too much time being agile, and not enough serving the larger objectives of the organization.

This has been on my mind watching Google fumbling around lately. Although their internal processes remain shrouded in mystery, as far as customer-facing interaction goes, the company has been a poster-boy for the agile approach: release early, release often. But the larger it has become, the more that philosophy has come to conflict with the basic need to satisfy customers. More and more Google products are drawing more and more fire as they are either discontinued, rapidly obsoleted, their feature sets radically altered, or their interfaces jammed into a new and poorly considered standard.

These are classic techniques (or symptoms, depending on your point-of-view) of agile processes... try small things, get them out the door, prune what isn't working aggressively. The problem comes when there is no overall vision behind this, and when what "isn't working" is judged from the perspective of the producer rather than the consumer. Alienation and distrust are what you get when you decide to discontinue a popular, though niche, application, service, or feature set. Those are not outcomes that support the banner of either customer collaboration or individuals and interaction.

Like any tool, agile can be used poorly. Consider how you are using it and make sure you can see the forest for the trees.