I believe that to become an agile software developer that
you need to move away from being a narrowly focused specialist to
become more along the lines of what I like to call a
generalizing specialist (a concept I discussed in the book
Agile Modeling although I introduced the
term in the book
Agile Database Techniques).
This article is organized into the following
sections:

When you
get your
first
job as
an IT
professional
it is
often in
the role
of a
junior
programmer
or
junior
DBA. You
will initially focus on becoming good at that role, and
if you're lucky your organization will send you on
training courses to pick up advanced skills in your
specialty. Once
you're adept at that specialty, or even when you've
just reached the point of being comfortable at it, it is
time to expand your horizons and learn new skills in
different aspects of the software lifecycle and in your
relevant business domain. When you do this you evolve from being a specialist
to being
a
generalizing
specialist.

Figure
1 depicts a fictional
skills assessment of an IT professional, showing how it
evolves over time. In this example, the person has
solid skills in Java development, and some initial
skills in modeling, testing, and
database
administration (DBA). Then, two years later,
they've improved all of their skills, including their
Java programming skills. They may have achieved
this through
training & education,
mentoring, or collaborative techniques such as
modeling with others or
pair
programming. Then, three years later their
skills have improved further, although it's interesting
to note that focus on a new skillset (.Net programming)
may have motivated the person to let their Java
programming skills go stale. It's incredibly rare for someone to become "super skilled" at everything, more on this later, although it is quite common for a generalizing specialist to become more skilled than either a generalist or a specialist.

Figure 1.
How a
generalizing
specialist's
skills
may
evolve
over
time.

As an
individual
it's an
incredibly
good
strategy
to
become a
generalizing
specialist.
The
greater
your
skillset,
the more
likely
that
you'll
be in
demand
and the
easier
it will
be for
your to
gain
employment.
Furthermore,
you'll
likely
get
better
jobs
than you
would
have
because
of your
greater
productivity
and
versatility.
Just
like you
wouldn't
have a
stock
portfolio
with a
single
stock in
it
(that's
an
incredibly
risky
investment
strategy)
you
shouldn't
have a
skills
portfolio
with
only one
specialty.

Just like multi-disciplinary teams are a good idea,
so are multi-disciplinary people.

There are several reasons why you should
prefer to build teams from generalizing specialists:

Improved
communication
and
collaboration. A generalizing specialist is
someone with a good grasp of how everything fits
together. As a result they will typically have a greater
understanding and appreciation of what their teammates
are working on.They are
willing to listen to and work with their
teammates because they know that they'll likely learn
something new. Specialists,
on the other hand, often don't have the background to
appreciate what other specialists are doing, often look
down on that other work, and often aren't as willing
to cooperate. Specialists, by their very nature,
can become a barrier to communication within your team.
Another
challenge with specialists is that they
have difficulty working together effectively with others
because they
don't have the background to understand the issues
that the others are trying to deal with.

Less
documentation.
Specialists are often motivated to create
far more documentation than is required, when all you
can do is write use cases then those use cases will end
up including information that could be better recorded
elsewhere, and very likely require reviews of said
documentation when they provide it to other specialists.The implication is that the same piece of
information will often be captured by several
specialists because they're afraid that they'll lose
that information.It's
quite common on projects dominated by specialists to see
a business rule captured in a user interface
specification, in a business rule specification, in a
logical
data model (LDM), in a UML
class diagram, in
acceptance tests, and in source
code. Clearly
there's a chance that the business rule will be
described inconsistently (thereby motivating more bureaucracy
in
the
form
of
traceability) let alone the obvious overhead
involved with reviewing and maintaining each version of
it. A generalizing specialist will write less
documentation than a specialist because they have a
greater range of options available to them.Instead of having a user interface specialist
capture the rule in a screen specification, the data
specialist capture it in an LDM and so on the
generalizing specialist will instead capture it in the
most appropriate place(s).In this case that could be in the form of one or
more acceptance tests as well as in the source code.In short, a generalizing specialist can choose
the best artifact to to capture the information in one and one only place.The implication is that a team composed of generalizing specialists
will be more effective than one composed of specialists.

Improved
flexibility.
In his
discussion
of
integrating
usability
specialists
onto an
agile
team,
Paul
Hodgetts
discusses
several
practices
which
result
in
productivity
loss
which
are
motivated
by
having
specialists
on your
team.
Specializations
forces
the team
to
pre-assign
tasks to
individuals,
thereby
hindering
the
team's
ability
to
dynamically
allocate
tasks as
new
circumstances
emerge.

Less
risk. Specialization
drives
teams to
break
down
their
iteration
tasks to
accommodate
each
person's
specialty,
resulting
in
finer-grained
tasks
and more
points
of
hand-off
between
people.
This
can
be
seen
in
the
diagram
of
Figure
2
where
each
specialist
does
their
work,
handing
it
off
to
the
next
specialist.
The
problem
is
that
every
time
there
is a
hand-off
between
people
there
is
information
loss,
documentation
is
the
worst
option
for
communicating
information
between
people
(see
discussion
about
the
CRUFT
calculation),
thereby
increasing
overall
project
risk.
Figure
3
shows
how
an
agile
team
would
be
organized
--
instead
of
throwing
artifacts
"over
the
wall"
to
one
another
agile
team
members
instead
share
the
artifacts
between
them,
working
together
to
evolve
the
artifacts
as
needed
and
when
needed,
learning
from
each
other
as
they
do
so.
This
lowers
overall
risk
because
there
is
less
information,
greater
knowledge
of
the
system
amongst
individual
team
members,
and
growing
skills
amongst
team
members.

Fewer
bottlenecks.
Specialists
become
bottlenecks,
reducing
overall
team
efficiency,
when
work
queues
up
for
them.
For
example,
a
single
database
administrator
(DBA)
is
assigned
to
support
four
development
teams
due
to
lack
of
database
expertise
amongst
other
people.
This
would
be
perfectly
fine
if
the
four
teams
generated
less
than
one
person's
worth
of
data
work
in
total,
but
in
most
organizations
as
soon
as
it
was
recognized
that
the
DBA
had
slack
time
available
to
them
they'd
likely
be
assigned
to
one
or
more
other
teams
until
they
finally
had
no
more
slack
time
available
to
them.
So,
because
work
load
isn't
consistent
work
will
queue
up
for
them
sometimes,
which
means
that
the
teams
which
they're
supporting
need
to
wait
for
them
to
get
the
work
done,
reducing
overall
team
efficiency
as a
result.
The
specialist
in
effect
becomes
a
bottleneck.
Sadly,
assigning
experts
to
multiple
teams
is
perceived
by
traditionalists
as
efficient
because
they
look
at
it
from
the
point
of
view
of
resource
allocation
instead
of
the
point
of
view
of
overall
team
effectiveness.

The
Whole
Team
practice,
popularized
by
Extreme
Programming
(XP),
recommends
that you
include
everyone
on the
team
with the
skills
and
perspectives
required
for the
team to
succeed.
Furthermore,
it
recommends
that
everyone
on an
agile
team
contributes
in any
way that
they
can.
If
people
are
generalizing
specialists
then it
becomes
much
easier
to form
whole
teams
because
it will
be
easier
to find
someone
with the
skills
that you
need.
If
people
are
specialists
then
you'll
find it
much
more
difficult,
and
you'll
often be
forced
to have
a single
person
work on
multiple
teams
because
those
teams
need
someone
with
their
specialty.

A generalizing specialist is more than
just a generalist. A generalist is a jack-of-all-trades but a master
of none, whereas a generalizing specialist is a
jack-of-all-trades and master of a few. Big difference. A team of generalists can easily flounder because
none of them have the skills to get things done.
Similarly, a generalizing specialist is more than just a
specialist. A specialist is narrowly focused on a
single topic, making them very effective at that topic
but not at others. Specialists will often be blind
to the issues which other specialists focus on, and as a
result will struggle to work with those other
specialists effectively. As Figure 4
indicates, people who are generalizing specialists are
in the "sweet spot"
between the two extremes of being either just a specialist
or just a generalist, enjoying the
benefits of both but not suffering from their drawbacks.

Figure 5 compares people following different skilling strategies -- in this case I'm showing only four potential skills (S1 to S4) to make my point, but in the real world you would consider much more than just four. There are three important points that I hope to make with this diagram:

Generalizing specialists are not just generalists. Time and again I've found that people confuse the concept of a generalizing specialist with that of a generalist, but as you can see a generalizing specialist has a much different skills profile than a generalist. Remember, a generalizing specialist has a general knowledge PLUS one or more specialties, whereas a generalist just has general knowledge.

Generalizing specialists are typically not "super skilled". Although a generalizing specialist will eventually become more skilled than either someone who is just a specialist or just a generalist, that doesn't mean that they are an expert at everything. The IT industry changes too quickly so that someone can become expert at everything (regardless of what their ego may be subconsciously telling them) so it's clearly unrealistic to expect this of someone.

Generalizing specialists are not just specialists. A specialist is someone who is narrowly focused in a single skill, although will likely have minimal skills in a few other domains as you see in Figure 5.

The
quick
answer
is yes,
depending
on the
context.
There
are two
categories
of
situation
where
your
team may
find the
need for
specialists:

Short-term
unique
activities.
For
example,
your
team
may
find
that
it
needs
to
setup
and
configure
a
database
server.
Although
you
could
figure
it
out
yourselves,
it's
probably
easier,
faster,
and
less
expensive
if
you
could
have
someone
with
deep
experience
help
your
team
for
a
few
days
to
work
with
you
to
do
so.
This
person
could
be a
specialist
in
database
administration.
These
one-off
situations
often
occur
at
the
beginning
of a
project
or
at
the
end
of
the
project,
what
Disciplined
Agile
Delivery
(DAD)
would
refer
to
as
the
Inception
or
Transition
"phases"
of
your
project.

In
scaling
situations.
At
scale
you
may
find
that
the
complexities
you're
dealing
with
may
require
specialists
focused
on
addressing
those
complexities
in
an
ongoing
manner
throughout
your
project.
The
scaling
factors
called
out
in
the
Software Development Context Framework (SDCF)
can
help
to
make
this
a
bit
clearer.
For
example,
your
team
may
find
itself
in a
situation
with
high
technical
complexity,
which
in
turn
makes
your
build
so
complex
that
you
need
someone(s)
specifically
focused
on
being
"buildmeisters".
In
situations
of
domain
complexity
or
organizational
complexity
you
may
bring
one
or
more
business
analyst
specialists
onto
the
team
to
help
you
explore
the
problem
space
you're
working
in.

Bottom
line is
that it
it isn't
a black
and
white
world
and you
will
need
specialists
from
time to
time.

Conclusion

In many ways a generalizing specialist is
simply a
software craftsperson. The
reason why I don't use the term "software
craftsperson" is that it is a loaded one that is
likely to turn off a large number of traditional
developers that prefer something along the lines of
"software engineer". I
believe that generalizing specialist is more
palatable.

In short, my experience is that
generalizing specialists are much more effective than
either specialists or generalists. The best developers are generalizing
specialists, or at least actively are trying to become
so. There
is still room for specialists within your IT department, they can often act as internal consultants
to your development teams, but as IT departments become
more agile I suspect that we will see fewer specialists surviving over
time.

Robert
A.
Heinlein
said
it
best:
"A
human
being
should
be
able
to
change
a
diaper,
plan
an
invasion,
butcher
a
hog,
conn
a
ship,
design
a
building,
write
a
sonnet,
balance
accounts,
build
a
wall,
set
a
bone,
comfort
the
dying,
take
orders,
give
orders,
cooperate,
act
alone,
solve
equations,
analyze
a
new
problem,
pitch
manure,
program
a
computer,
cook
a
tasty
meal,
fight
efficiently,
die
gallantly.
Specialization
is
for
insects."

Share with friends:

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.

Recommended Reading

This book, Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprisedescribes 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 forscaling agile.
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.