Modeling in the Agile era: what does the expansion of agile teams need in addition to code?

Agile methodologies have become the mainstream of current software development, and working code (and automated testing) is considered to be the most important output for the team.

So is it no longer necessary to model it? Is the UML really dead? I don't think so.

In this article, I will explore how the modeling approach still works and plays a key role in the agile era. Especially after the expansion of the development scale to more than one team, the whole system of "big picture" to reach a consensus will become very critical.

Where is the "design" in agile?

Although the code shows the facts, it does not represent the full –grady of the facts Booch

In the opening section, I'll describe a streamlined process for an agile team that uses scrum. Figure 1 shows an intentionally streamlined process that retains only the key parts.

Enumerate the "User requirements" in "Product Backlog".

The development team picks up some requirements from the list and implements them in a shorter iteration (or a sprint) time.

At the end of each sprint, the team creates "working software" (or "incremental content"), which behaves as "Product Code" and "Test code."

Figure 1, a simple scrum framework

In this most streamlined framework, the team is aware of the "User Requirements" on "product Backlog" and outputs the "working software" presented by code ("Product Code" and "Test Code"). This is not an explicit description of the design results between the two. Ideally, this sprint's design intent, as part of the team's output, is already reflected in the final release of the code. But some information is not directly expressed in code. Scrum itself is a process framework that is not intended to represent any part of the design, but there are still a variety of design tasks in the team.

As Grady Booch said, "The code shows the truth, but it doesn't show the whole truth." So if some information cannot be expressed or communicated in code form, where do we keep the knowledge wealth? This is the question that this article tries to answer.

Isn't it agile to write a document?

Modeling is for dialogue –craig Larman and Bas Vodde

One answer to the above question may be: "In our minds!" ”。 Daily meetings, pair programming, design research, and so on, interactive practices continually belongs the minds of team members in a synchronized fashion. But when teams start to expand, or distribute in different geographies, or when members leave the team, the contents of the "model in mind" are quickly forgotten. We need to preserve the consensus of the system in the form of documentation to share information that is not easily retained and communicated in the form of code.

The agile approach clearly illustrates the idea that a conversation is worth more than a document, so writing a heavy design document (which often repeats the information expressed in the code) is not the right approach. The approach we should take is to write only those documents that make the dialogue more efficient, and it should keep the simplest collection of models as much as possible, complementing the code.

One aspect of a model that is better than the code is its visual representation. In other words, in some cases, words are a bad medium of communication. Figure 2 shows a situation in which the text exchange fails (thanks to Jeff Patton for recommending this book for me).

Figure 2, the failure of text communication

I suspect that this "tragic" cake was caused by a misunderstanding of the cake maker's phone answering machine (the original intention of the Subscriber is to add "We'll miss You" below the "best wishes Suzanne" sentence (underneath that), If the Subscriber is able to express his intentions with a simple picture (with words), it can certainly avoid this tragedy. Sometimes, it really is "a picture wins thousand words".

So, how do you use the model effectively in an agile team to achieve your goals?