Introduction to Agile Modeling — Scott Ambler
pdf-download epub-downloadWhat is a Model?
A model is an abstraction that expresses important aspects of a thing or concept. Models may be visual (diagrams), non-visual (text descriptions), or executable (working code or equivalent). Models are sometimes called maps, roadmaps, runways, or boards within the agile community. In the software world a model can be something as simple as a sketch on a whiteboard or sticky notes on a wall. Models could also be captured using simple drawing tools such as Sketchpad or PowerPoint. Or they could be captured by sophisticated software tools such as LucidChart or erWin that may have the capability to round-trip engineer working software. The medium doesn’t matter, the key point is that models are abstractions.
Why Do We Model?
There are many reasons to model on a software initiative:
- Exploration. Sometimes we model to explore our stakeholder needs or to explore our architectural strategy. That collection of user stories that forms your product backlog is in fact a requirements model, regardless of the semantic arguments that agile purists may try to make.
- Collaboration. Other times we model to collaborate or communicate more effectively with others. One of the most effective ways to collaborate is face-to-face discussion around a shared sketching environment such as a whiteboard.
- Sensemaking. We also model to understand. It is common for people to sketch what they’d like to have built, or to explain how something works. Just the other day I was helping my daughter with her math homework and to do so we sketched on a whiteboard for a bit to work through what a question was asking.
What is Modeling?
Modeling is the act of creating a model. Modeling is sometimes called mapping. The activity of agile modeling is modeling performed in a collaborative and evolutionary manner.
Do Agilists Model?
Yes. Unfortunately, due to cultural issues with roots from the very beginning of the agile movement, many agilists don’t want to recognize this and some have even developed sophisticated semantic arguments to avoid doing so. You may have heard that agilists don’t model, although they do map. Or that user stories aren’t models, even though they’re clearly abstractions. Ugh. The only thing these arguments do is make it confusing for people to learn how to be effective with agile WoW.
As an aside, the cultural issues that I alluded to are the result of agilists pushing back against the heavy-handed traditional approaches to modeling and documentation at the time. It’s similar to agilist’s aversion to project management. It was easier to declare modeling, documentation, management, and other important aspects of our profession as bad rather than sifting through those domains for the many nuggets of value that they have to offer. The agile community still suffers from this prejudice, to its detriment.
What is the Agile Modeling (AM) Method?
The Agile Modeling (AM) method is a collection of strategies, WoW and ways of thinking (WoT), that focus on effective modeling and documentation on software development teams. AM addresses how to take an agile approach to requirements exploration, design, user experience, architecture, and documentation. AM is agnostic, its strategies are meant to be tailored into methods such as Scrum, SAFe, Kanban and others. AM strategies have been explicitly adopted and contextualized by the Disciplined Agile (DA) tool kit from Project Management Institute (PMI).
Why Do We Need Agile Modeling?
Many people are still struggling with fundamental questions such as:
- How does architecture fit into agile?
- How does business and systems analysis fit into agile?
- How does documentation fit into agile?
- How does design fit into agile?
- How does user experience fit into agile?
- How do models and executable specifications work together?
These are all questions addressed by the AM method. Most importantly, AM is not prescriptive. It doesn’t provide a single way of working, but instead provides options from which you can choose to pick the most appropriate approach for your situation. For example, a prescriptive strategy would tell you that requirements should be captured as user stories. AM instead says that user stories are one of many options available to you, a good option, but not the only option. Depending on the problem that you face, a user interface (UI) prototype or UI sketches might be better strategies for you, or perhaps data-oriented artifacts are (say for a business intelligence initiative). Or perhaps combinations thereof. Context counts.
Are Models Documents?
Sometimes, but usually not. Documents persist information over time, whereas many models are transient in nature. For example, many models are captured using inclusive tools, such as whiteboards and sticky notes. These models are created as you’re exploring or communicating a concept and then discarded once they’ve served their purpose. Some of them are retained for future use, and it is at this point that they become documentation. For example, you use your phone to take a picture of a whiteboard sketch, or you capture it in PowerPoint so that you can evolve it later, or you may even capture it in a software-based modeling tool (SBMT) as part of a sophisticated round-trip engineering WoW.
Where did Agile Modeling come from?
The AM method was originally published between 2000 and 2002, but has evolved since then. AM began as a column that I wrote in the Autumn of 2000 for Software Development magazine. Called eXtreme Modeling (XM) at first, the goal was to explain how modeling fit into eXtreme Programming (XP) projects, but it quickly became apparent that XM was more than just that. At the prompting of Bob Martin I renamed it to Agile Modeling and for a bit more than a year I ran workshops at software conferences around the world to develop the first version of the method. The first official “release” of AM came in the form of the Agile Modeling book via Wiley Publishing in the spring of 2002. Since then AM has evolved and been captured at AgileModeling.com (Note: At the time of this writing we’re in the process of migrating this site to Wordpress, so I ask for your patience).
What Are Your Take-Away Points?
I’d like to leave you with the following thoughts:
- Modeling and documentation are important aspects of agile software development.
- The Agile Modeling (AM) method captures agnostic strategies that you can tailor into your WoW to improve your effectiveness.
- Most models are simple and transient in nature, created using inclusive tools.
- Agile modeling is collaborative and evolutionary in nature – modeling is so important you will do it all the way through the lifecycle.
- Some agilists struggle to recognize that they do in fact model.