Although UML is usually not associated with agile processes, there are two ways I think it can play a major role in an agile development project.

The first is a full adoption of a UML toolset, including full round-tripping through the entire implementation. In this case, UML becomes part of your programming language. It maps very well onto the constructs of Object-Oriented implementation languages, and there is nothing about it that will stop you from doing all of the things you do in an agile process (Simple Design, Test First, etc.) The benefit is that you have a up-to-date UML document at the end of the implementation (why you might want this, I’ll save for a future entry). I have done this with Rational Rose for C++ with great success, and if you want UML diagrams that actually match the implementation, this is the way to go.

The other use is to not even attempt to keep UML documents consistent with the implementation as it progresses, and just use UML to convey design ideas. This is more precise than a text description, and certainly a good supplement to one. Design Patterns by the GoF is a good example of a book that uses UML to convey design ideas. Martin Fowler’s Patterns of Enterprise Application Architecture uses it extensively as well, and he says this about the UML in his books.

Most UML diagrams shown in books, such as mine, are sketches. Their emphasis is on selective communication rather than complete specification. Hence my sound-bite “comprehensiveness is the enemy of comprehensibility”

Unless UML is the implementation language (where completeness is essential), then there is no need to include every detail in the drawing. In fact, inclusion communicates importance in this context.