In the interests of keeping the U.S. Postal Service in business, I subscribe to a number free technology periodicals. I’m too cheap to pay for anything more than MSDN Magazine. One of the free rags I like to keep in the reading room is Information Week.

A recent article entitled Where Agile Fails caught my eye. You can get a copy of it online if you want to hand over your contact info. I enjoyed the article and it makes a good general point. The author Charles Babcock draws our attention to the fact that many agile teams overlook operations and the challenges brought about by frequent releases into production.

I was only disappointed in the title. Any reader who quickly browses the article, allowing the title to influence conclusions, may walk away with the wrong idea. The title would be more informative if less typographically attractive as Where Agile Teams Fail to Involve Operations, Agile Teams Fail.

When agile development is done right, it includes as part of release and sprint planning some elements of deployment, operations, support and maintenance. Some sprints or releases planned may not go into production, so operations need not be involved too heavily, but I think they should be be apprised of the team’s plans and progress and given the opportunity to prepare in advance for the needs of the application and users.

When a release or sprint will go into production, the operations team should be represented in the planning meetings. This will give them the opportunity to learn what is expected of them and plan accordingly. It will also give them a chance to ask questions, raise concerns or even point out why they will not be able to support a go-live date for a release. And when that is the case, you want to know sooner rather than later.

Where agile succeeds is in the notion that people and interactions are more important than processes. The Manifesto does not indicate that it is referring only to developers. Clearly that is not the case. Operations people are people too. Yes, Fred, they really are.