A day back our Customer initiated a change to their integration solution. Based on our and Customer's documentation the solution was a simple batch file transfer using SFTPS for transportation and XSLT for data transformation. Our developer was lost for a while when the solution in production turned out to be two web service calls with XSLT transformation between. It was completely different from what the documentation said it to be. 

Well, other integrator had made several well justificated changes to solution and transformation as well. No need to say that only thing that was missing was the documentation update. Nevertheless, I do not blame the other integrator for not documenting  the changes - they might even done that, but the documentation were not available at the Customer. 

Experience shows that an integration solution is not a very static object. It may need to be changed several times after its initial production use. This may occur for example as a result of a new business need or a change in the interface or as a result of a bug fix. Some of our customers tend to follow a development pattern where all integration cases are too small to form an independent project or they are implemented based on a one/single Use Case.

Therefore, it is mandatory to choose and dismount processes for change management and maintenance. Being agile does not mean that documentation can be discarded.

We have designed few separate models based on scrum and scrum-ban for managing work related on constant changes, maintenance and other smaller yet independent tasks. I shall discuss these models in my forthcoming blog posts. Meanwhile - make sure that you have a process and a documentation that is up to date.