I love agile methodology and extreme programming. I used to work in a team that loved it and lived by its core philosophy. To top it of we had a strong technical manager who was a certified scrum master and new the approach inside out. Life was good.
Then our manager left. We got a lot of new recruits, many who had never worked in a core agile environment. Our teams got shaken up. Ultimately, the loudest voices got heard. 6 months into it, we have sort of become a mess. To sort of patch up the mess, somebody suggested documenting processes, because to some people, agile meant chaos. Of course agile methodology minimises documentation. Its not that we hate documentation. But I hate certain kinds of documentation. Documentation of processes.
How can you encapsulate all the nuances about human activities - interactive communicative and effective procedures - into words? Documenting processes is like making humans machines. Without creativity or without thought. Processes always are evolving and no two situations can be asked to follow the same text. People need to think on their feet each time. Agreed - some process documentation come with a disclaimer that these are just guidelines and to use proper judgement before following them. Now a poor new recruit new to the agile world would ask - where is that documented?
I believe in mentor-ship and process mentor-ship that encourages and teaches the ideology behind thought. Perhaps putting this ideology into text would not be bad since it does just that - captures ideology.
Anyway, I do like documentation on one important aspect - requirements. Although requirements may change in the real world, they still need to be documented. Because requirements need to be translated into code, which a machine needs to understand. Quite unlike process documentation which a human needs to understand, assimilate and generate an effective action out of.
