If your objective is a “sense of urgency”, or maybe “time to value”, please don’t think this gives you carte blanche to push patchy, chewing-gum-and-bailing-wire solutions out into production. Expect the expectation that the production systems’ availability level must be maintained.
It’s possible, of course, you just need to practice a little discipline. Pay attention to the spirit, not the letter, of the “law”. So how to reconcile the two ideas?
- Fast, iterative Push-to-Test: If you’re in a complex production environment (like an ERP), use the Test environment to get your iterations in front of your end users / testers. You can get the ideas out there, people can see what you mean, but the ultimate push into production only happens after a thorough, hopefully regressive, test.
- Segment your Content: If you have decent change management capabilities, you can segment low-risk changes to production (like HTML and PDF files on a web page) from high-risk changes (like DTS scripts that process financial transaction imports). Fast-track the low risk stuff; better yet, completely automate it!
- Formal Change Management Process: This may seem like old hat to the larger IT groups, but for those smaller organizations that have not experienced the pleasures of SarbOx … a decent change management system (or even a hack one) should track all changes, keep a log of who and when, and make back ups of the before and after – so you can put things back they way they were.
I think, however, the most valuable thing you can do before claiming to be an Agile adherent is to Read the Definition of Agile: Please don’t make the mistake that incremental releases skip or shortcut the testing process!