Cockburn points out that while many methodologies
define the roles that developers may take on a software
project, as well as the types of tasks people in those
roles perform, what they often don’t do is define the
type of people who are best suited for those roles.
For someone to be effective in a role they should
be a reasonably good fit for it – they may not have
all the requisite skills but they should be able to grow
into them. My
experience is that an effective agile modeler exhibits
most of the following traits:
Team player. First and foremost, agile
modelers actively seek to work with others because they
recognize that they don’t have all the answers and
that they desperately need several points of view to be
development is a lot like swimming, it’s dangerous to
do it alone.
is no “I” in agile (Canadian spelling, eh).
Agile modelers have good communication skills –
they can present their ideas, they listen to others,
they actively seek feedback, and they can write
reasonably well when needed.
Agile modelers should be practical.
They should be able to focus on fulfilling the
needs of their users and to not add unnecessary bells
and whistles (something often referred to as gold
plating) to their models. They should be satisfied with producing the simplest possible
solution that gets the job done.
Inquisitive. Agile modelers enjoy
exploring the problem domain as well as the solution
Agile modelers do not take things at face value
but instead ask further questions, exploring an issue
until they understand it sufficiently.
They don’t assume that a product or technique
works according to it’s marketing literature, instead
they try it out for themselves.
Agile modelers should be humble enough to know
that they don’t have all the answers, and sufficiently
cautious to recognize that they should prove their
models with code sooner rather than later.
Agile modelers are willing propose an idea, to
model it, and then to try to prove it with code. If it doesn’t work they then try to rework their approach
or even discard it as appropriate.
It takes courage to offer your ideas to your
peers and then to try to validate them.
Agile modelers should be willing to try new
approaches, such as applying a new (or old) modeling
should also be open to agile software development
techniques in general, and be willing to go against the
grain of conventional wisdom when needed in order to
validate ideas such as reducing the amount of
documentation on a project.
It takes constantly follow the practices of agile
very easy to say to yourself “adding this extra
feature isn’t going to hurt anything” or “I know
better than my project stakeholders” and then act
discipline to stay on the agile path.
What happens if you don’t exhibit all of
these traits, yet still want to become an agile modeler?
worry, you can grow into the role with a little effort.
Believe me, I’m not practical or realistic 100%
of the time and very often I can become very
is going to exhibit all of these traits to the maximum,
instead people will exhibit these traits to some extent.
Everyone is different, and it’s these
differences that brings strength to agile development
some people being inquisitive comes naturally, other
people need to consciously work on it.
We’re only human.
A critical issue that you need to
address when recruiting members to your team is the
ratio of generalists to specialists that you wish to
answer this question you need to consider the nature
of modern software development.
The lifecycle of the
Unified Process (EUP) depicted in Figure
process workflows listed along the left-hand side hint
at the potential complexity of software development
– you may need to business model, gather
requirements, analyze and design your system, and so
on – and this is clearly just the tip of the
phases, Inception through to Production, listed across
of the diagram, are indicative of a changing focus
throughout your project that requires different skills
at various times.
The point to be made is that software
development is clearly very complex, an effort that
requires significant skill and experience.
It is important to understand that this
complexity is inherent in software development in
general, not just in the EUP – project teams taking
Agile Unified Process (AUP), DSDM,
approach also need to
deal with these complexities. Although their lifecycles may not depict it as explicitly as
the EUP’s project teams following these methods
still perform configuration management activities,
still perform management activities, and so on (albeit
in different manners).
The lifecycle for the Enterprise Unified Process
Many organization’s first
reaction is to build a team of specialists.
The basic idea is that specialists are very
proficient at a specific task and are therefore more
efficient, so to become efficient at software
development all you need to do is put together a team
of specialists who work on their part of the project
and hand-off their work to other specialists who
evolve it from there.
This is effectively the “assembly-line”
school of thought, which works very well if you are
mass producing cars but in my experience does not work
very well when you are attempting to hand-craft
this approach is geared towards larger teams – if
there are X distinct tasks required to develop
software then you need at least X specialists
following this approach.
How big is X? Twenty? Fifty?
One hundred? Depends on how finely you define the specialties, doesn’t
you are of the single artifact developer mindset then
just to handle modeling alone you may need over twenty
specialists, there are that many artifacts listed in
modeling artifacts article, and if you are of the single role
developer mindset then you have eleven roles on an EUP
project just to cover the workflows.
Specialists often have difficulties working
with others, either they lack the humility to
recognize that people with different specialties than
their own have something of value to add or they are
so narrowly focused that they don’t realize that
what they are doing is causing someone else later on
to do significant rework (or perhaps the work that
they are doing is simply being ignored).
Another problem with specialists is their
skills may not be very good at all, even in their own
high rate of technical change within the IT industry
provides an environment where developers can work with
a new technology for several months, become reasonably
familiar with it, and claim to be an expert because
few others are available with the same level of
there is a problem with building a team from people
who are only specialists.
So how about building a team of
only of generalists?
Everyone would have a fairly good understanding
of how to develop software, but unfortunately
wouldn’t have the detailed knowledge required to get
the job done. Your project will need people intimately familiar with the
techniques and technology that you are using.
If you’re working with Enterprise JavaBeans
(EJB) then you want developers with expertise in Java
programming as well as in EJB development.
A team working with Oracle on the backend will
also want someone with Oracle database administration
experience, and a team developing software for a
brokerage will want people that understand the nuances
of stock and bond trading.
My experience is that neither
extreme works well, that instead what you want is
something in the middle. One approach is to build a team with some people who are
generalists and some who are specialists, the
generalists provide the glue within the team and focus
on the bigger picture whereas the specialists focus on
the detailed complexities of your project.
This works well because the strengths of
generalists balance the weaknesses of specialists and
vice versa, and it is often quite useful for a
generalist to pair with a specialist because of this
better approach would be to build a team comprised of
people who are generalists with one or two
generalizing specialists. For
example, I would claim that I am a generalist, I have
a pretty good handle on how it all fits together, yet
I have specialties in business application software
modeling, object persistence, and Java programming.
One of my current co-workers is a generalist
with specialties in modeling, EJB development, and
testing whereas another is a generalist with
specialties in telecommunications networking and Java
programming. The advantage of building teams from
generalists that have one or more specialties is that
they quickly find common ground with their co-workers,
they’re all generalists after all, and have the
necessary background to appreciate the importance of
The main disadvantage is that these people are
often very senior, it can easily take ten to twenty
years to gain sufficient experience to become a
generalist, and thus are difficult to obtain.
You’re very lucky if a portion of your team
is formed by people such as this.
It's important to recognize that
novices often specialize at first. People who
are new to development are typically overwhelmed by
the vast range of knowledge that they need to gain,
that’s only natural.
Most people will start out by focusing on one
or two aspects of development, perhaps programming in
Java or gathering user requirements, and then using
that experience as a base branch out from there.
As time goes on they’ll slowly build up their
skillset with experience, perhaps gaining a specialty
or two in the process as well as a better
understanding of how it all fits together.
It's also important to understand
that many developers specialize to their detriment.
Because of this inherent complexity of software
development a common trap is for developers to fall
Single Artifact Developer anti-pattern
where someone defines himself as a person
that works on one type of artifact (e.g. code, a use
case model, or a data model) or into the Single
Role Developer anti-pattern where someone defines
herself as a person that performs one kind of task
(e.g. modeling, testing, or coding).
In other words the person is specializing in a
specific role, a tendency that is often encouraged
within large organizations following prescriptive
processes (if they’re following any process at all).
The problem is that developers who fall into
this trap are too narrowly focused to be productive on
an agile software development project, although if
they are willing to expand their horizons this issue
can be swiftly overcome.
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
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
(TDD). 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 Techniques
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
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
architect, and then
design your system in an agile manner.
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
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.
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 W.
Ambler + Associates.