Agile – Are These Diagrams Correct for RAD and Agile Methodologies?

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.

What's not clear is whether you're talking about Use Cases or UML.

Use cases:

With regards to use cases: with BPMN, you use those to develop the BPMN. In fact, to some degree, BPMN is meant to replace some of the use cases. Use cases are typically used to illustrate the business process to the developer -- but in this case, the business analyst/use case writer can put a lot of that "description" into the BPMN.

What's left over is maybe some detail about the BPMN process, which analysts can add in a document. But again, in that document, it needs to be clear that the BPMN is what's being described (and not that the BPMN is an addition to the text).

(This also depends on whether or not the analyst or the developer is writing the BPMN: if the developer is writing the BPMN, then obviously you need the use cases to help the developer define the BPMN -- but that's a little weird. In an effective organization, the business analysts know how to and can write BPMN and the developers can help double-check it. BPMN is, to some degree, meant to free developers from writing business logic code and get analysts to "write" it.)

The only use cases that should be left over should be cases that describe situations that are not fully covered by the BPMN. For example:

• Web page or UI interactions
• Technical use cases involving multiple systems
  • web service descriptions, for example.

The whole purpose of BPMN is to remove the business logic from your application (code). Use cases which describe business logic are often used to build business logic into an application. In short, if you're using both, you need to make rules about which one is the defining definition. (Otherwise, we get possibly conflicting descriptions of the same process/logic...)

UML:

With regards to UML: the BPM engine becomes an actor. Similar to how use cases should be used, it's important to not describe the same thing in both your UML and your BPMN. Otherwise, you may have two slightly similar but conflicting descriptions of the same thing.