When I persisted and suggested that requirements and architecture deliverables should be updated as part of the maintenance process, I had another protest. “All that writing? We don’t have time for that!”
I recently suggested to a team that they could make good use of Macroscope documentation in maintenance. There was instant skepticism. I was politely told that I was being naïve – everybody knows there is almost never any existing documentation and what there is will be out of date and can’t be trusted. And so there is no point in creating any new documentation – nobody would use it.
When I asked what they rely on to help with their maintenance work, I heard:
I was recently teaching a Macroscope Foundation course, and sharing my zeal with the principle that the business participants should take a driving role on many aspects, when one person finally spoke up with, “I have never, ever seen it work that way.” In his experience, it had always been IT (and IT consultants) pushing everything.
I gave two quick answers:
