As the name implies, AMDD is the
agile version of Model Driven Development (MDD). MDD is
an approach to software development where extensive
models are created before source code is written. A
primary example of MDD is the
Object Management Group
(OMG)'s Model Driven Architecture (MDA) standard.
With MDD a serial approach to development is often
taken, MDD is quite popular with traditionalists,
although as the RUP/EUP shows it is possible to take an
iterative approach with MDD. The difference with AMDD
is that instead of creating extensive models before
writing source code you instead create agile models
just barely good enough
that drive your overall development efforts.
AMDD is a critical strategy for scaling agile software
development beyond the small, co-located team approach
that we saw during the
of agile adoption.
depicts a high-level lifecycle for AMDD for the release
of a system. First, let's start with how to read the
diagram. Each box represents a development activity.
includes two main sub-activities,
envisioning. These are
done during Inception, iteration being another term for
cycle or sprint. "Iteration 0, or Inception", is a
common term for the first
iteration before you start into development iterations,
which are iterations one and beyond (for that release).
The other activities -
model storming, reviews,
and implementation -
potentially occur during any iteration, including
The time indicated in each box represents the length of
an average session: perhaps you'll model for a few
minutes then code for several hours. I'll discuss
timing issues in more detail below.
Figure 1. The AMDD
lifecycle: Modeling activities throughout the lifecycle
of a project.
The envisioning effort is
typically performed during the first week of a project,
the goal of which is to identify the scope of your
system and a likely architecture for addressing it.
To do this you will do both
requirements modeling and
architecture modeling. The goal isn't to write
detailed specifications, that proves
incredibly risky in practice, but instead to explore
the requirements and come to an overall strategy for
For short projects (perhaps several weeks in length) you
may do this work in the first few hours and for long
projects (perhaps on the order of twelve or more months)
you may decide to invest two weeks in this effort. I
highly suggest not investing any more time than this as
you run the danger of over modeling and of modeling
something that contains too many problems (two weeks
without the concrete feedback that implementation
provides is a long time to go at risk, in my opinion).
Through initial, high-level modeling you can gain the knowledge that you need to guide the project but choose to wait to act on it.
For the first release of a system
you need to take several days to identify some
as well as the scope of the release (what you think the
system should do). The goal is to get a good gut
feel what the project is all about. For your initial
requirements model my experience is that you need some
to explore how users will work with your system, an
initial domain model
which identifies fundamental business entity types and
the relationships between then, and an
initial user interface model
which explores UI and
inclusive modeling techniques which enable
active stakeholder participation.
The goal of the
architecture modeling effort is to try to identify
explore potential architecture-level
requirements which your system may need to support
one day. In
later iterations both your initial requirements and your
initial architect models will need to evolve as you
learn more, but for now the goal is to get something
just barely good enough so that your team can
get going. In subsequent releases you may decide
to shorten Inception to several days, several hours, or
even remove it completely as your situation dictates.
The secret is to keep things simple. You don't need to
model a lot of detail, you simply need to model enough.
If you're writing use cases this may mean that
point-form notes are good enough. If you're domain
modeling a whiteboard sketch or collection of CRC cards
is likely good enough. For your architecture a
whiteboard sketch overviewing how the system will be
built end-to-end is good enough.
Many traditional developers will struggle with an
agile approach to initial modeling because for years
they've been told they need to define comprehensive
models early in a project. Agile software development
isn't serial, it's iterative and incremental
(evolutionary). With an evolutionary approach detailed
modeling is done just in time (JIT) during
iterations in model storming
plan the work
To estimate each requirement accurately you must understand the work required to implement it, and this is where modeling comes in. You discuss how you're going to implement each requirement, modeling where appropriate to explore or communicate ideas. This modeling in effect is the analysis and design of the requirements being implemented that iteration.
With initial iteration modeling you explore what you need to build so that you can estimate and plan the work for the iteration effectively.
4. Model Storming: Just
In Time (JIT) Modeling
My experience is that the vast majority of modeling
sessions involve a few people, usually just two or
three, who discuss an issue while sketching on paper or
whiteboard. These "model storming sessions" are
typically impromptu events, one project team member will
ask another to model with them, typically lasting for
five to ten minutes (it's rare to model storm for more
than thirty minutes). The people get together, gather
around a shared modeling tool (e.g. the whiteboard),
explore the issue until they're satisfied that they
understand it, then they continue on (often coding).
Model storming is just in time (JIT) modeling: you
identify an issue which you need to resolve, you quickly
grab a few team mates who can help you, the group
explores the issue, and then everyone continues on as
before. Extreme programmers (XPers) would call
modeling storming sessions stand-up design sessions or
customer Q&A sessions.
During development it is quite common
to model storm for several
minutes and then code, following common Agile practices
Test-First Design (TFD) and
for several hours and even several days at a time to
implement what you've just modeled. For the sake of
discussion test-driven design (TDD) is the combination
of TFD and refactoring. This is where your team
will spend the majority of its time, something that
Figure 1 unfortunately doesn't
communicate well. Agile teams do the
majority of their detailed modeling in the form of
executable specifications, often
customer tests or development tests. Why
does this work? Because your model storming efforts
enable you to think through larger, cross-entity issues
whereas with TDD you think through very focused issues
typically pertinent to a single entity at a time. With refactoring you evolve your design via small steps to
ensure that your work remains of high quality.
of as a
You may even want to "visually program" using a
sophisticated modeling tool such as
Rational Software Architect (RSA). This
approach requires a greater
modeling skillset than is typically found in most
developers, although when you do have teams made up with
people of these skills you find that you can be
incredibly productive with the right modeling tools.
You may optionally choose to hold
model reviews and even code inspections, but as I write
Model Reviews: Best Practices or Process Smells?
these quality assurance (QA) techniques really do seem
to be obsolete with agile software development, at least
in the small. On larger teams, or in very complex
situations, reviews can add value because when they're
done right they provide excellent feedback into your IT
From a design point of view the
AMDD approach of Figure 1 is very
different than traditional development approaches where
you create a design model first then code from it. With
AMDD you do a little bit of modeling and then a lot of
coding, iterating back when you need to. Your design
efforts are now spread out between your modeling and
coding activities, with the majority of design being
done as part of your implementation efforts - in many
ways this was also true for many traditional projects,
the developers would often do significantly different
things than what was in the design models, but the
designers would often blame the developers instead of
question their overly serial processes.
AMDD is different from techniques
Feature Driven Development (FDD) or the use case
driven development (UCDD) styles of
Agile Unified Process (AUP) in that it doesn't specify the type
of model(s) to create. All AMDD suggests is that you
apply the right artifact but it doesn't insist on what
that artifact is. For example FDD insists that features
are your primary requirements artifact whereas UCDD
insists that use cases are. AMDD works well with both
an FDD or a UCDD approach because the messages are
similar - all three approaches are saying that it's a
good idea to model before you code.
implication of Figure 1 is that
it doesn't make sense to have people who are just
modeling specialists on your development team any more.
What are they going to do, model for a few minutes and
then sit around for hour or days until they're needed
again? What is really needed is something I call a
generalizing specialist, someone with one or more
specialties as well as general skills in the entire
lifecycle, who can both code and when they need to model
works for several reasons:
- You can still meet
your "project planning
identifying the high-level
requirements early, and by
identifying a potential
architecture early, you have
enough information to
initial cost estimate
- You manage technical
risk. Your initial
efforts enable you to
identify the major areas of
technical risk early in the
project without taking on
the risk of over modeling
your system. It's a
practical "middle of the
road" approach to
- You minimize wastage.
A JIT approach to modeling
enables you to focus on just
the aspects of the system
that you're actually going
to build. With a
serial approach, you often
model aspects of the system
nobody actually wants.
- You ask better
longer you wait to model
storm a requirement, the
more knowledge you'll have
regarding the domain and
therefore you'll be able to
ask more intelligent
- Stakeholders give
Similarly, your stakeholders
will have a better
understanding of the system
that you're building because
you'll have delivered
working software on a
regular basis and thereby
provided them with
There are three basic
approaches to applying AMDD on a project:
Simple tools, such as
inclusive models are used for modeling.
Inclusive models are used to explore
requirements with stakeholders, and to analyze those
requirements. Developers then use sophisticated modeling tool
detailed design, (re)generating source code from the
MDA-based modeling tools used to
create extensive models from which working
software is generated. At best this approach
Let Us Help
We actively work with clients around the world to improve their information technology (IT) practices,
typically in the role of mentor/coach, team lead, or trainer. A full description of what we do, and how to contact us, can be found at Scott Ambler + Associates.
This book, Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise
describes the Disciplined Agile Delivery
(DAD) process decision framework.
The DAD framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and provides the foundation for
This book is particularly important for anyone who wants to understand how agile works from end-to-end within an enterprise setting.
Data professionals will find it interesting because it shows how agile modeling and agile database techniques fit into the overall solution delivery process.
Enterprise professionals will find it interesting beause it explicitly promotes the idea that disciplined agile teams should be enterprise aware and therefore work closely with enterprise teams.
Existing agile developers will find it interesting because it shows how to extend Scrum-based and Kanban-based strategies to provide a coherent, end-to-end streamlined delivery process.
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2 is an important reference book for agile modelers,
describing how to develop 35 types of agile
models including all 13
UML 2 diagrams.
Furthermore, this book describes the fundamental programming and testing techniques
for successful agile solution delivery. The book also shows how to move from your
agile models to source code, how to succeed at implementation techniques such as
The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniquesbook.