Is Your Cloud Support Agile? Take Our Quiz
Practically everyone working in the cloud says they're doing agile projects. But you'll find some tinges of non-agility, particularly in the support function after you put a system into production. Take this quiz to find out how agile your cloud support organization really is.
Mon, January 16, 2012
CIO — As I've written endlessly, cloud projects are a nearly perfect fit for agile project development techniques. Even if your finance guys insist upon fixed price and fixed schedule, the tendency in the cloud is iterative development and scrum teams.
But agile really is focused on development —all the agile manifesto authors came from the development discipline — and not on the ongoing obligations of system support. Where agile optimizes speed and business value of innovation, it doesn't have much to say about MTTR or cost optimization. Do agile principles help in support organizations? You bet! Do they pan out in your support team? You be the judge:
Are Your Developers Doing Support?
Serious points off if they are. A key metric of the support function is the capability to use low-cost resources to solve all but the most intricate problems. Sure, your developers can probably do support faster and better than a level-one support tech, but that hardly means they should. (All too often, the developers won't even bother to close a case, let alone improve checklists and tests.) If your developers can't extricate themselves from support cases, it means they can't be doing higher value work. And it means your support organization can't go down the experience curve. It's also a pretty clear indication you've got a problem with&
Is There Sufficient Support Knowledge Base?
The support team needs FAQs, troubleshooting checklists, escalation rules, release notes, application notes, revised test vectors, normative log files, and training materials. All organized into a solid Knowledge Base. Unfortunately, many agile developers eschew the creation of these documents during the development cycle. It's viewed as overhead, bureaucracy, and —in some of the more extreme sects of agile —as a misleading abomination ("the code is the only documentation that matters!"). If you can't get the developers to do documentation, you'll need an explicit technology transfer function to transform the production artifacts into a Knowledge Base that the support organization and customers can digest. Make sure your deployment schedule and budget have placeholders for this transformation process (which will have to be continuous and repeated with each iterative release).
Is the production system continuing to use continuous integration principles, with scheduled periodic pushes?
In enterprise-scale cloud systems, there are enough bug fixes, data corrections, user-privilege modifications, and access control updates that configuration change needs to be managed on an ongoing basis. And the right way to do that is by leveraging sandboxes,
