I work as part of a scrum-like Agile team and a while ago, one thing we identified that the team should do is maintain good set of design documents for our code base. Because we are agile and do have good amount of discussion and communications, our designs are kept at a high level and are generally used for describing general layout of modules, including main classes and some of their interactions and. We also found them useful for discussion starting points since and also for reminding people that design needs to be considered before you jump into code.
So far, it was expected that everyone will update design specs on as needed basis. Design leads for each team are responsible for giving people advice on design in general, on what to update in the SDSs and also for reviewing the specs to make sure everything stays consistent.
The issue I'm seeing is that while everyone, especially new members find design specs very helpful when learning new components or even going back to components they haven't touched for a while, most people only update the docs for the sake of updating them (i.e. they are told they must do it and so they do it). So that we end up with one-liner descriptions which sometimes aren't even full sentences and when I tell them this needs to be updated and filled in, they add more but again, only because they are told. So now one-liners become 1.5 lines and there's still nothing helpful written down.
Obviously different team member skills/strengths will be different. So the question is, should certain team members on an agile team simply not be responsible for design and be reduced to just a coder? Or should it be design leads role to go back to those team members and make them rewrite the specs as many times as necessary (and this is really becoming painful) until they pick up enough skills to produce what's expected?
My basic guideline that I suggest to everyone: if you were sitting in a meeting or making a presentation about class diagram X, what would you say if your audience needed to know how your code works. Instead, half the time they simply restate what I can already see in the class diagram. "Class X implements interface Y". That would be entire class description.
Amendment:
I work for a large corporation with a very healthy appetite for outsourcing/contracting. The team I'm on has permanent members, it also has permanent members who are very new to the team (from recent merger). And we have contractors from India and Poland who will most likely be reassigned to other project after the current release. So different members have different buy-in at this point. Documentation is definitely important to those of us that have been on the project in the last release and will be on the project in the next release.
Best Answer
I'm not sure if you have read it, but I recommend reading Scott Ambler's article on Agile/Lean Documentation.
That seems somewhat contradictory. If the team members actually do find the documentation useful, that should be a motivating factor in keeping them up-to-date. If your development team isn't actively updating the documentation to capture decisions, perhaps some problems need to be addressed. Is the documentation relevant? Does the current format of the document facilitate communication? Are you trying to produce documentation that is too good or too formalized for the purpose?
Delegating design documentation updates to a single team member, in my opinion, goes against agile. Part of the point of agile is to reduce risk, and you do this by spreading responsibility around. Just like no one owns code, no one individual owns documents either. Rather than have team members rewrite specs, try something like pair programming to teach these people how to write better documentation or institute reviews on produced documents to provide appropriate feedback.