 |
Sometimes you find yourself in a
situation where you can't easily
model storm a
requirement or
design issue for a few
minutes on a just-in-time (JIT) basis.
Perhaps your stakeholder(s) aren't available
100% of the time, perhaps they don't fully
understand a difficult issue, or perhaps you are
so tight for time that you don't mind
potentially wasting money on over modeling for
the sake of shaving a week or two off your
schedule. In these situations you may
decide to have someone "model a bit ahead" of
the developers on your team, gathering
information, exploring requirements, and
thinking through the detailed design before you
actually implement the software. This
modeling is done in parallel to the development
effort, often a few days or weeks before the
information is actually needed. |
|
Motivation
There are
several reasons why you might
want to model ahead:
-
Stakeholders are only available
at certain times. I once worked
on a project where the business
stakeholders were available for
one-to-three days per month and
specific individuals had to be
scheduled two months in
advance. During these modeling
sessions we would first address
any domain questions which we
had identified since the last
modeling session, then we
started exploring new concepts
which we believed we would run
into during the coming
iteration. Scheduling
challenges forced us to model
ahead.
-
Stakeholder time is valuable.
You may want to prepare for
modeling sessions with these
stakeholders so as not to
waste their time by not
understanding the
fundamentals of what they're
talking about. Your
goal would be to understand
their area of expertise and
therefore be able to ask
more intelligent questions.
Unfortunately, you risk
coming to the table with
preconceived notions or
having a firmer
understanding of the issue
because the stakeholder
hasn't yet done the
requisite thinking, so be
careful.
-
Sometimes a requirement or
technical solution is very
difficult. One of my
clients implements very
difficult financial business
rules, and some of these rules
are so complex that the expert(s)
need to work through them first
before trying to explain them to
the developers. The
stakeholders know what they’re
talking about, many of them have
PhDs in the subject matter, and
the developers have a solid
understanding of the domain as
well; even so, it is still more
efficient for the stakeholders
to first work through the logic
of the business rule with a
modeler before they discuss it
to the developers. The
stakeholders are still available
to work with the developers to
answer their questions on a JIT
basis, but they first work with
the modeler for several hours to
coalesce their ideas.
Another example is that in
some large organizations it
takes time to come to some
sort of agreement regarding
the nature of their source
data (my advice: you need just
good enough data for
your situation, not a
perfect
"one truth").
-
You
need to integrate with a
poorly documented legacy
asset.
Legacy analysis is often
a difficult and time
consuming effort. If
your architecture indicates
that you need to interact
with such an asset, and the
requirement to do so is fast
approaching, you should
consider doing this analysis
just before you need the
information.
-
Usability issues need to be
considered. Many
user-centered design
techniques, such as doing
user research, require
up-front work, even on agile
teams. Sometimes
you require specific
resources such as usability
labs, or access to specific
people, both of which must
be scheduled in advance.
In other words, you may need
to do usability modeling a
bit ahead of the actual
development of the UI
aspects of your system.
-
You
can speed up development.
Some
project teams like to quicken
the pace of development cycles
by getting a head start by
modeling upcoming requirements.
During iteration N they model
various aspects of iteration
N+1, increasing their
understanding of what needs to
be built and thereby enabling
them to more accurately identify
the work to be done. By
parallelizing development
activities like this they
decrease their overall
schedule. Furthermore,
when the customers/product
owner come prepared to the
iteration planning/modeling
effort at the beginning of
an iteration you can reduce
the time required for this
activity substantially,
leaving more time in the
iteration for development
activities.
-
There are differing
stakeholder opinions.
Most projects have a wide
range of
stakeholders, and one
result is that they often
don't agree. So, it is
common to model a bit ahead
in these situations, at
least an iteration ahead, so
that the team doesn't have
to wait for the stakeholders
to come to agreement.
Figure 1. The AMDD
lifecycle: Modeling activities throughout the lifecycle
of a project.
Solution
As Figure
2 indicates, agilists work
treat requirements (and other
types of work item for that
matter) as if they
existed on a
prioritized stack which changes
to reflect the current needs of
the stakeholders. With “agile modeling a bit ahead”
your team does just enough
modeling to understand
a requirement which has been
assigned to some point in the
near future, such as an upcoming iteration
or even just later in the
current iteration.
This modeling will potentially
go down
to the design level, although
you will rarely need this level
of detail (remember, you should
still only model
just barely enough to meet
your exact needs). Most
commonly, you look ahead to the
next iteration to explore
upcoming requirements. To
remain agile you want to model just
the complicated requirements of
the coming iteration, not every
single one. In other
words, apply this
process pattern sparingly.
Figure
2. Agile
requirements
change
management
process.
Some teams will choose to
employ a
business analyst (BA) who
models a bit ahead of the rest
of the team, gathering the
domain information before the
team needs it. The
primary danger with this
approach, of course, is that the
BA will filter the information
(often inadvertently) which is
presented to the team. This
person may even act as the
primary customer to your team,
or product owner,
representing your
project stakeholders to your
team while working with them
behind the scenes to gather the
requisite information.
| |
|
A
BA is a poor
substitute for
developers who
have both ready
access to actual
stakeholders and
agile modeling
skills.
Remember, BA is
also the
abbreviation for
band-aid |
|
Consequences
On the one hand, with model a
bit ahead
you clearly run the
risk of modeling something you
eventually don’t need to build:
your stakeholders might decide
to drop or radically change a
requirement between the time you
model it and the time you go to
implement it. In
short, the further ahead that
you model, the greater the
chance of falling victim to the
problems surrounding
big modeling
up front (BMUF).
Furthermore, you risk forgetting
the information the greater the
period between modeling it and
implementing it, motivating you
to write more
documentation and thereby
slow down your overall effort.
On
the other hand, modeling a bit
ahead
provides the opportunity to
streamline development efforts
during the coming iteration by
ensuring you have the detailed
understanding that you need to
build the software effectively.
In some ways this is the
equivalent of recognizing that
the road that you're traveling
has a few potholes coming soon
and sending someone ahead of
your team to fill in the
potholes so that the rest of the
team doesn't get into trouble
when they hit them. The software development game is
a series of trade-offs, and you
need to make the right ones for
your situation.
Some agile developers will
tell you that modeling ahead is
heresy, but frankly I’m more
interested in strategies which
work in practice than with
conforming to religious dogma.
There is a big difference
between agile modeling ahead and
taking a BMUF approach. With
BMUF you attempt to do all of
the modeling early in the
project and then recording the
results via comprehensive
documentation. Yes, you
definitely want to avoid the
disadvantages of BMUF, which
include an inflexible approach
to development that often
results in significant wastage,
over-investment in
documentation, and lower
productivity due to
over-specialization of IT
professionals (if you hire good
modeling specialists, they’ll
create a lot of good models
whether you need them or not).
Acknowledgements
I'd like to thank Paul
Oldfield for his feedback
regarding this article.
 |
|
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 techniques
of the
Full Lifecycle Object Oriented Testing
(FLOOT) methodology to give you the fundamental
testing skills which you require to succeed at
agile software development. The book also
shows how to move from your agile models to
source code (Java examples are provided) as well
as how to succeed at implementation techniques
such as
refactoring and
test-driven development
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
object/relational mapping,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
book. |
|
|
|
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
modeling and
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
XP, the
Rational Unified Process (RUP), or the
Agile Unified Process (AUP), to streamline your
modeling and documentation efforts. Modeling and
documentation are important aspects of any software
project, including agile projects, and this book
describes in detail how to
elicit requirements,
architect, and then
design your system in an agile manner. |
 |
|
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
guidelines
for creating effective
UML diagrams. They are based on sound, proven
software engineering principles that lead to diagrams
that are easier to understand and work with. These
conventions exist as a collection of simple, concise
guidelines that if applied consistently, represent an
important first step in increasing your productivity as
a modeler. This book is oriented towards
intermediate to advanced UML modelers, although there
are numerous examples throughout the book it would not
be a good way to learn the UML (instead, consider
The Object Primer). The book is a brief 188
pages long and is conveniently pocket-sized so it's easy
to carry around. |
I actively work with clients around the world to
improve their information technology (IT) practices as
both a mentor/coach and trainer. A full description of
what I do, and how to contact me, can be
found here.
|
