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.
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 , 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.
One Agile method, Feature-Driven Development (see references [3 Chapter 16 (Intentional Architecture).] and ), 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 (). 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:
- 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.
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.
This collaborative approach suggests the following usage of the models in different contexts:
|Business Epic Kanban||At the evaluation stage, the process of sizing business epics and assessing their possible technical risks is simpler in the context of its architectural models. Use cases and domain models helps the team assess logical dependencies.|
|Architecture Epic Kanban||Architectural views help understand which programs and teams will be affected by a new epic. The domain model helps in understanding the impact on the system itself.|
|PSI Briefings||Different model views are useful to communicate the intent behind larger epics and features when presenting Vision content to the program.|
|Backlog Grooming and Sprint Planning||It is easier to estimate a user story and break it into smaller pieces when the team has different model views of the system to reason with.|
|Architecture/System Design CoP Meet-up||Understanding new initiatives is easier in the context of a defined and described system.|
|Ad-hoc Requirements or Design Workshop||All of the above methods are useful in the everyday work of Agile teams and system architects.|
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.
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
 Cockburn, Alistair. Writing Effective Use Cases. Addison-Wesley, 2001.
 Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.
 Palmer, Steve, and John Felsing. A Practical Guide to Feature-Driven Development. Prentice-Hall, 2002.
 Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley, 2003.
Last update 15 January, 2013
© 2010-2013 Leffingwell, LLC.