Project Management – Programming with a Group of People You’ve Never Met

Actually, I would suggest that you do not need a branching model, but rather a complete comprehensive approach to deal with the multi-dimensional constraints with regard to the system without branching. In practice, I believe it will always be a problem to maintain multiple systems that have some commonalities but will evolve differently in branches, so it is better to turn everything into a single system that will evolve as a whole, but consists of different configurations. This may appear to be too simplistic, but there is extensive research in this area, with a lot of successful industrial applications.

The name for this approach is Software Product Lines or sometimes Product Line Engineering. From CMU SEI's Software Product Lines page:

A software product line (SPL) is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.

The key idea is that every requirement, every milestone, every feature (a key term in this domain) is part of the complete system at the highest level. The actual systems deployed at various customers is essentially a collection of features. Each feature however is not just a physical component mashed into the system, it is defined as depending on or enabled by other features (so that by picking a feature, you may automatically include its dependencies, etc.)

Instead then of maintaining all these branches, you end up maintaining one system along with a set of customer-specific configurations.

It may be difficult or even impossible in practice to migrate to such an approach with a very large system, but even then it will be useful to investigate the approaches used in SPL in order to assess what approaches used there can at least be (partially) integrated in your work.

Some additional useful links:

• Wikipedia: Product Line Engineering
• Case Studies by CMU SEI
• Software Product Lines, a site with a lot of introductory material.

I'm not sure if you have read it, but I recommend reading Scott Ambler's article on Agile/Lean Documentation.

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).

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?

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?

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.