Frantic activity is no substitute for analytical thought.

–Sir Alastair Pilkington

Agile Analysis Abstract

As Agile makes its way “across the chasm” to enterprise-class development, we are using it to build ever larger and more complex systems. That’s OK; after all, the purpose of SAFe is to provide a framework of organizational and development patterns that have emerged from successfully deploying Agile at scale. But building really big systems requires bigger tools, so we need additional tools in our toolkit. In this section, we’ll describe three that enterprises use to assure their success: Intentional Architecture, Use Case Modeling and Domain Modeling. We will also describe what’s different about these methods when used in the context of Agile development. For that purpose, we will consider how Just-In-Time Elaboration is applied in Agile modeling, describe some key collaborative and visual techniques , and finally, we’ll describe how to continually refactor the models to reflect an emerging understanding of the domain.

Details

Intentional Architecture

Agile was developed in the context of small teams and small systems. One assumption was that architecture emerges as a natural outcome of a rapid iteration cycle, the implementation of prioritized, value-driven user requests, and a continuous refactoring process. That works fine – up to a point. But when we consider larger systems, systems that involve ten or more Agile teams (we have seen up to 100 teams) working on the same codebase, architecture can indeed emerge, but some of it needs to emerge intentionally. And because all software systems age and grow decrepit over time as a result of changing demands and changing technologies, it will eventually be necessary to re-architect major portions of the system. To do that, we’ll also need a common architectural vision, strategy, and governance model. We describe the result of this process as the  architectural runway, system infrastructure which supports the flow of new business epics into the system.
In order to “build” and maintain the runway, some architectural activities must be performed continually: coordinated system refactoring, extending current platform and infrastructure capabilities, supporting new non-functional requirements, etc. These are examples of architectural epics – larger intentional initiatives that are further broken down into architecture features and stories – something that programs and teams can work on within their iteration or PSI timebox. Within this process, ideas come from all directions. At the portfolio level, this intentional effort is systematized by enterprise architects. At the Program Level, it is driven to implementation with the help of system architects working with the Agile teams who implement the system.

Use Case Modeling

In Agile Software Requirements [1 Chapter 19 (Use Cases). Chapter 20 and 21 (Architecture)], we described Use Cases and Use-case Modeling as useful tools to aid in understanding the system’s behavior and its interactions with users, devices and other systems. Cockburn [2], a signer of the Agile Manifesto, has also applied use cases extensively in the Agile context. The use case model provides the broader context for user stories and elaborates on how the system features achieve the user’s greater objectives. Use cases can be used to describe this larger end-to-end behavior, and the main and alternate success scenarios of each provide an effective mechanism for discovering and implementing user stories.

Domain Modeling

One Agile method, Feature-Driven Development (see references [3 Chapter 16 (Intentional Architecture).] and [4]), achieved some popularity for a time. One of the eight best practices of that method was domain modeling, which is the primary mechanism for describing the larger system. Another good domain modeling approach is described in Domain Driven Design ([5]). The domain model describes the system from the perspective of real world objects (people, devices, other systems, other entities) that the system must support. It is used to identify the relevant objects in the system, in addition to the static and dynamic elements of system behavior. As such, the domain model gives a “big picture” view of the system as a whole, and provides an important context for everyone implementing the system. For this reason, many programs consider the development, maintenance and communication of the domain model to be an important element of their Agile process.

For further information read the Domain Modeling article.

Just-In-Time Model Elaboration and Refactoring

Agile welcomes change – a tenet that we accept unconditionally, even when scaling Agile methods to the enterprise. We support this by continuously updating and refining our understanding of the system as follows:

• The results of the initial analysis are captured at a high-level of abstraction (typically only at the cloud- or kite level in terms of use cases; high-level entities, services and aggregates of a domain model; high-level architecture views).

• More detail is elaborated upon reaching the PSI and then even more at the iteration boundary.

• Once further elaborated, a more detailed view of the model may persist, or it may be abandoned by the group once it has served its purpose.

Figure 1. The team sketches a quick flow diagram, which will exist only until they acquire a sufficient understanding of how to estimate and implement the current user story.

Models can’t talk or interact. No matter how well elaborated the model may seem, inconsistencies and ambiguities can only be resolved by communication between the people involved in different aspects of the process. That is why, even though models may eventually persist in electronic form, the best way to develop a model is by simply using a whiteboard. A few quick photos, and the team has a reference point it can refer to during implementation.

Figure 2. A whiteboard sketch illustrating an approach.

This collaborative approach suggests the following usage of the models in different contexts:

Table 1. Examples of the usage of models in an Agile enterprise.

In Agile, we start simply with an initial understanding of the domain and the context for the requirements. As the system evolves, we get better insights and understanding of the domain, so we need to evolve our models along with it.   In other words, we have to continuously refactor the model to reflect our improved understanding of the reality. This, in fact, means that crucial defects and design flaws should be treated not only as an impediment to its correct functionality, but also as a learning opportunity for organization to improve their analysis models and thus, their fuller understanding of the solution domain.

Learn More

References

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
[2] Cockburn, Alistair. Writing Effective Use Cases. Addison-Wesley, 2001.
[3] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.
[4] Palmer, Steve, and John Felsing. A Practical Guide to Feature-Driven Development. Prentice-Hall, 2002.
[5] Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley, 2003.

 Last update 15 January, 2013

© 2010-2013 Leffingwell, LLC.