Rants
Questions
Soapbox
Best Practices
Apply today for a FREE subscription to CIO Magazine!
Wed, May 9, 2007 22:47 EDT
|
Posted by: mtnygard in Best Practices Topic: IT Organization Management
Current Rating: |
The Agile Manifesto is explicit about it. "We value individuals and interactions over processes and tools." How should an Agile team---more specifically, an XP team---respond to the IT Infrastructure Library (ITIL), then? After all, ITIL takes seven books just to define the customizable framework for the actual practices. An IT organization usually takes at least seven more binders to define its actual processes.
Can XP and ITIL coexist in the same building? Or, is Extreme Programming just incompatible with ITIL? In short: no.
ITIL and agile methods are not fundamentally incompatible, but there will definitely be an interface between the XP world and the ITIL world. Whether this interface becomes an impedance barrier or not depends entirely on the way that your company chooses to implement ITIL.
I'll run down the Service Support processes and identify some of the problems I've encountered. (I'm focusing on Service Support because businesses tend to implement these processes first. Few of them get far enough down the road to really attack the Service Delivery processes. It's a shame, because I see a lot of value in the Service Delivery approach.) I will cover the service delivery processes in a future article.
Service Desk
An effective service desk can be a great asset to any team, including an XP team. Getting accurate feedback on issues your users are having can only benefit your development efforts and ultimately, the users themselves. The key here is to make sure that the service desk is well-prepared to accept responsibility for support calls on your app.
I strongly recommend that you start working with the service desk at least six weeks before your first application release. If the service desk is mature, they'll have job aids for capturing app support needs. These will provide the minimum initial information needed for the knowledge base. The service desk personnel will augment that knowledge base over time with whatever solutions, rumors, superstitions and folk remedies they come up with. Be sure you have access to the knowledge base, so you can help weed out the "false solutions."
You also want to get on the distribution list for ticket reports from the service desk. These will tell you what issues your users are encountering. Commonly recurring or high-impact issues should become cards for consideration in your next iteration. This feeds your interface to the Problem Management process.
If the service desk is not mature, you haven't prepared them
All in all an interesting synopsis, but I took exception to the comment about developer's providing support to incident management as being a "crappy job" is probably the greatest reason behind why it is considered a "crappy job": perception.
In reality, the developmental (learning) opportunities in the support function are far greater than doing pure development work. Discovering the real-time business needs of an application, delving into the logic (and associated problems) of code, and working with front-line operations staff are some examples of the great learning opportunities.
Organisations need to promote this role, instead of perpetuating the "crappy job" view. In the organisations I have been involved with, this role was desired, as it was normally filled with the best developers, who were regarded as the "gurus" by the other developers.