Is UML Still Relevant Today? How Is it Used in an Agile Environment?

I’ve seen a lot of questions about Unified Modeling Language (UML) that center around “Is UML still relevant today?” and “How is it used in an Agile environment?”. I will try to address these questions in this blog post.

What is UML?

UML stands for “Unified Modeling Language”. Here is a definition of UML:

” The goal of UML is to provide a standard notation that can be used by all object-oriented methods and to select and integrate the best elements of precursor notations. UML has been designed for a broad range of applications. Hence, it provides constructs for a broad range of systems and activities (e.g., distributed systems, analysis, system design and deployment). “

“In 1994, Jim Rumbaugh, the creator of OMT, stunned the software world when he left General Electric and joined Grady Booch at Rational Corp. The aim of the partnership was to merge their ideas into a single, unified method (the working title for the method was indeed the “Unified Method”). “
Visual Paradigm website

What’s the primary purpose of UML?

The Visual Paradigm website summarizes the primary goals of UML as follows:

  1. Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models.
  2. Provide extensibility and specialization mechanisms to extend the core concepts.
  3. Be independent of particular programming languages and development processes.
  4. Provide a formal basis for understanding the modeling language.
  5. Encourage the growth of the OO tools market.
  6. Support higher-level development concepts such as collaborations, frameworks, patterns and components.
  7. Integrate best practices.

UML is typically used to simplify a lot of written documentation. It provides a visual model of how a system works and how it is designed.

UML is intended to satisfy a broad variety of interests. It consists of a number of different diagram types that show the system from different perspectives. Those diagram types can be grouped into two major categories:

  1. Structure Diagrams – “Structure diagrams show the static structure of the system and its parts on different abstraction and implementation levels and how they are related to each other.”
  2. Behavior Diagrams – “Behavior diagrams show the dynamic behavior of the objects in a system, which can be described as a series of changes to the system over time

For further detail on UML diagrams, the Visual Paradigm website is a very good source.

How Does UML Fit Into a Software Development Process?

UML diagrams are heavily-associated with what is called “Big upfront design”. That is typically what is called a “Waterfall process where:

  • The requirements for the process, as well as
  • The design of the software to satisfy those requirements can be defined in some level of detail upfront prior to the start of the project.

In that kind of environment, UML diagrams are a way of presenting a visual, diagramatic view of what is in the requirements documents and how the design will be implemented and that can be particularly useful for large, complex projects.

UML obviously works best in a sequential Waterfall process as shown here:

Are UML Diagrams Still Relevant?

In this type of process,

  • The requirements definition phase would typically take place first
  • Then, UML behavior diagrams might be used to define the most critical behavioral characteristics of the system from a user perspective
  • Those diagrams might then serve as input to the design process where the design of the system would be laid out to satisfy those requirements
  • Once the design process is complete, UML structure diagrams might be used to define the expected overall structure of the system from a design perspective
  • Those diagrams might then serve as input to the development process to implement the design of the system

In this type of environment, the UML diagrams provide two different kinds of value – UML:

  1. Provides a communications mechanism to summarize the information that is in various project documents. That is useful to transition that information from one phase to the next
  2. Can also be used for support purposes after the project has been completed. refer back to how the design of the system was created
  3. Can potentially play a role in defining and standardizing the system architecture of the solution. That can be particularly important in large, complex, enterprise-level projects where it is important to have a clear and consistent architecture for solutions

Is UML Still Relevant Today? What Is the Role of UML in an Agile Development Process?

Many companies are moving to an Agile development process for software development which raises the question: “Is UML still useful in an Agile environment?”. In an Agile environment,

  • The requirements for the project and the design of the software are normally not defined in detail prior to the start of the project
  • Both the requirements and the design typically evolve and are further extrapolated as the project was in progress
  • In an Agile environment, there is also normally much less reliance on formal project documentation

The difficulty of using UML diagrams in that environment should be obvious:

  • There is typically insufficient information at the beginning of the project to define the requirements and the design in detail prior to the start of the project
  • It might require a lot of effort to continuously update UML diagrams as the project is in progress to reflect any changes
  • It raises questions as to who would benefit from maintaining and updating those UML diagrams and how they would benefit from it

The general rule I use for any kind of documentation is that:

  • We shouldn’t create documentation for the sake of creating documentation
  • Documentation should create some kind of value for someone and
  • That value should be sufficient to overcome the costs of creating and maintaining that documentation

Overall Summary

Agile is redefining how software is developed and raises some significant questions about “Is UML still relevant today?”.

The value of UML diagrams in an Agile environment is limited and the effort required to continuously update the diagrams as the project is in progress may not be worth the effort. However, there are a couple of reasons why UML diagrams might still be useful:

  • Support – There might be some value in having UML diagrams as an aid for supporting the system once development has been completed
  • Architecture – There might also be some value in using UML to define and standardize the architecture of the solution

Both of those functions would depend heavily on the complexity of the system, the criticality of the business functionality it provides, and the overall support strategy for the system.

Additional Resources

You can find further information on how an Agile/Scrum development process works and the advantages it provides in these links:

You will find much more detail on this in my Online Agile Project Management Training.

What Is an Agile Developer? How Is the Role Different?

The role of an Agile Developer is not well-understood and many developers may have difficulty making this transition.

In a traditional plan-driven environment (aka “Waterfall”), a developer might be able to sit in his/her cube with their headset on listening to some cool tunes. And, he/she could be fairly isolated from the rest of the world and simply write code. That isn’t possible in a true Agile environment.

What is an Agile Developer?

Agile Developer Role

The role of a developer in an Agile environment is significantly broader than that and includes:

AreaAdditional Responsibility
Task/Project ManagementTaking responsibility for estimating, planning, and managing all of his/her own tasks and reporting on progress.

This role is essentially what a project manager might do on a very small scale.
Effective TeamworkCollaborating closely with all the other members of the team to take shared responsibility for the overall efforts that the team has committed to.

This role is also similar to what a project manager might do but rather than being done by a single person with the title of “Project Manager”, the responsibility is distributed among all members of the team.
Software QualityTaking responsibility for the quality of the software the developer produces.

Instead of turning over some code to a separate and independent group for testing, the team, as a whole, takes responsibility for the quality of the work they produce.
A developer may or may not do the testing himself/herself but the key point is that the quality of the code is not someone else’s responsibility.
Understanding User NeedsInteracting with users as necessary to clarify requirements.

Developers will typically not be given a well-defined set of requirements. More often, the developer will get some general user stories that are intended to be a “placeholder for conversation” and the developer will be expected to interact with the Product Owner and users as necessary to better define what is needed.

This is essentially equivalent to a Business Analyst role on a very small scale.

Overall Summary

The role of a developer in an Agile environment is significantly different. Developers have additional responsibilities in an Agile environment that go beyond simply writing code.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.