 |
Topics:
|
|
Agile Modeling isn’t going to work for
everybody, it isn’t a panacea that works in every
situation. Nor
is it guaranteed to work even in situations where
conditions are perfect – you can still make mistakes
implementing AM within your organization.
Having said that, my experience is that AM has
the potential to be effective when the following factors
hold true:
1.
You are
taking an agile approach to software development.
AM isn’t a complete methodology, it is
presented under the assumption that it will be applied
within the scope of another process.
For this to work successfully there must be a
conceptual fit between AM and this other process,
otherwise you will be forced to hobble one or more of
AM’s techniques and therefore not truly be doing AM.
2.
You are
working iteratively and incrementally.
Effective communication and feedback, two of
AM’s practices, require an iterative and incremental
approach to software development.
3.
Uncertain
or volatile requirements.
Martin Fowler, in The
New Methodology, points out that if your project is
exploratory in nature, and many are, then it is very
likely that an agile approach to development is best
suited. When
your requirements aren’t certain, or actively
changing, then you need to follow a software process
that reflects this fact.
AM deals with changing requirements by embracing
change, but taking an incremental approach to
development, by seeking rapid feedback, and insisting on
active participation of project stakeholders so that the
requirements may be quickly and effectively explored.
4.
Your
primary goal is to develop software.
This is one of AM’s core principles,
something that is not always the case for many projects.
For example, sometimes a project team’s primary
goal is to make money from your customers (often the
case in outsourcing situations) or simply to specify the
system so it can be given to another team to implement.
Even worse, some development efforts are simply a
political exercise with no intention of delivering
anything more than a perception that something is being
done. The
goal of software development should be to produce
systems that meet the needs of their users in an
effective manner – if you are doing anything less then
AM is not for you.
5.
You must
have active stakeholder support and involvement.
For
agile software development
efforts to be a success you should have the active
support and involvement of your
project stakeholders. A
project stakeholder is anyone potentially affected by
the development and/or deployment of a software project.
This includes direct users, indirect users, managers,
senior managers, operations staff members, support (help
desk) staff members, testers, developers working on
other systems that integrate or interact with this one,
and maintenance professionals.
To be successful with AM you need to know who
your project stakeholders are, you must have access to
stakeholders on a daily basis who are able to provide
information and make decisions in a timely manner, and
have full management support for your project.
6.
The
development team must be in control of its destiny.
Agile software development, and Agile Modeling is
particular, is new to most organizations.
Adopting agile approaches will be difficult at
best for many organizations because it is a
significantly new way to work for most people.
To be successful my experience is that project
teams must be given the opportunity to succeed or fail
on their own merits. The must be in a position to try new techniques and be given
the resources, including time, to let them run their
course. Your
organizational environment must have minimal politics,
implying that both management and other groups within
your organization need to get out of your way.
7.
A true
champion for AM exists.
Whenever you adopt something new there will
always be challenges.
People don’t like to change, they are often
happy working in the non-agile way that they are used
to. Others
see things differently than you, or simply don’t
recognize the problems that you are trying to address by
adopting AM. Perhaps
they are promoting their own pet approaches to
development, approaches that don’t fit well with AM.
Perhaps AM threatens the current power structure
within your organization.
Regardless of the situation there will always be
people who will fight change.
To be successful at change someone must exist
that champions the new cause, in this case adoption of
AM, someone willing garner support of project
stakeholders and to protect and nurture AM efforts as
they take root within your organization.
Change takes time, and champions buy you that
time.
8.
You
require responsible and motivated developers.
Agile software development requires
developers that have the discipline to work together to
develop quality software, and who are often
generalizing specialists. The implication is that you
need a healthy team environment, one in which people
trust one another and help each other to succeed.
Contrary to what many of the detractors of agile
development will tell you, my experience is that you
don’t need people that can walk on water instead you
simply need people who want to get the job done and who
have the ability to work with others effectively.
9.
You have
adequate resources available to you.
You will see that agile modeling requires people
to work together closely.
The implication is that you need “co-location
space(s)”, such as a dedicated modeling room to work
in, a public wall to display your models on, and ideally
even shared workstations for pair development efforts.
Furthermore you need access to modeling tools
such as whiteboards, index cards, markers, and CASE
tools as necessary.
I’ve seen lack of basic resources such as
decent chairs, tables, food, drink, and top-notch
workstations dramatically hamper software development
efforts. If
your project team is being nickel-and-dimed to death
then I have to question if your project is important to
your organization – if it isn’t cancel it now and
invest your efforts on something more productive.
So what do you do when one or more of
these factors does not hold true?
Try to change your situation.
No champion for AM exists? Then
become the champion.
Not allowed to work iteratively and
incrementally? Negotiate
with senior management, convince them that there are
better ways to work, ask them to give you a chance to
prove it to them. Don’t
have adequate resources?
Communicate the importance of this to your
management. Once
you’ve changed the situation the best you can, if
you’re still missing a few factors then you need to
choose one of the following options:
1.
Partially
adopt AM. You
can adopt as many of the principles and practices of AM
as possible, you won’t be truly doing AM but you will
likely be more productive as a developer.
Once your organization discovers that there are
better ways to develop software perhaps they will be
more willing to change the factors required to fully
adopt AM. In
other words, ease into agile modeling.
2.
Give up on
AM within your organization.
Personally, I don’t like this option but I have
to admit that it’s a valid one.
The reality is that AM isn’t for everyone and
perhaps your organization is one where AM simply isn’t
a good fit.
3.
Start
looking for employment elsewhere.
There are a lot of organizations out there that
are choosing to succeed at the software development
game, organizations that are more than willing to hire
motivated software developers.
I suspect that you are likely to run into
trouble with Agile Modeling in the following situations:
-
One
or more of the factors listed above isn’t there.
-
Your
organizational culture is geared towards
prescriptive processes. There are many organizations that simply aren’t interested
in taking an agile approach to software development. These organizations are happy with the status quo and
that’s fine by them.
This likely includes organizations such as
Government agencies, large established firms (banks,
insurance companies, telecommunications firms, …),
and consulting firms that specialize in serving
these organizations. This isn’t to say that it’s
impossible to adopt AM in these organizations, but
it is likely that an extraordinary effort such as an
off-site effort will be required to be successful.
-
You
have a large and/or distributed team.
Agile modeling works very well on teams that
are co-located in the same work area, particularly
when the developers are co-located in a shared work
room (often called a “tiger team” room).
You can attempt to apply AM on large or
distributed teams, I discuss this very situation
with respect to architectural
modeling, but you will find that communication
challenges quickly get in the way.
I would also be
leery of applying agile modeling to develop
life-critical systems, such as an air traffic control
system or patient monitoring system, simply because I
don’t work on such projects and have no insights into
how well AM will work on them.
Similarly, I don’t work on embedded software
and therefore have never had a chance to apply AM
techniques on these types of projects.
I highly suspect that AM is applicable to
embedded software development but this is just
speculation on my part.
I look forward to hearing about your experiences
in these situations on the
Agile Modeling mailing list.
See also
When
is a Model Agile?, What
Is(n't) Agile Modeling?, and When
Are(n't) You Agile Modeling?
 |
|
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.
|
