Agile and ITSM (at least he mainstream of ITSM) seem at complete odds with each other, and in fact, they really are. So if you’re a traditional ITSM practitioner, how do you maintain the regimented environment you’ve spent years creating? This post from the IT Skeptic provides six “tactics” for dealing with what Agile can potentially harm in the traditional ITSM world. One tactic is to keep standard change in place: All organisations that have change control should have standard change. if you don’t have standard changes and you face complaints and resistance over change processes, it serves you right. I tell all my clients standard change is mandatory from day one in order to facilitate cultural acceptance of any new change management regime. If you don’t have standard change and Agile is coming and you can’t ring-fence it, you have a major problem. If you do have standard change, then you only have a serious problem 🙂 Work with the Agile implementers to find as many procedures as possible that can be categorised as standard change. This is of course an ongoing process: after they’ve hurled a few releases out there, you can start assessing the procedure for eligibility as a standard change. And then you can work with them to adapt their procedures to meet eligibility. Another tactic is to preserve and adjust governance to account for agile development. Since it is moving much faster than traditional processes, the IT Skeptic posits that responding to the changes that agile can bring to an organization.