 |
A common challenge within the IT
management right now is to understand the
implications of
disciplined agile software development. A critical
step to understanding agile development is to
observe an actual Agile team in action and see
the results for yourself. Unfortunately
there is no official criteria for determining
whether or not a team is Agile, and worse yet
there are many "code & fix" teams claiming to be
agile. I often run into traditional IT
professionals that are confused about Agile
either because they mistake code & fix
approaches for Agile ones. Worse yet they
then propagate their misunderstandings to
others, compounding the problem.
|
|
At the time of this writing there is no official
definition of what Agile is, and many people want to use
the values and
principles of the
Agile Manifesto as the definition. Although I
respect this opinion, and wish it were that simple, my
observation is that the values and principles are too
vague for determining whether or not a project team is
taking an agile approach. When I "evaluate" a
project team, here's what I look for:
- Is the team is doing
developer regression
testing, or better yet taking
a test-driven approach to
development?
Minimally developers should
be testing their code, to
the best of their ability,
at least daily in a
regression manner. With
test-driven development
(TDD) you write a single
test before writing just
enough code to fulfill that
test. This can be done
at the requirements
specification level as well
at the design level. I
will ask a team to show me
their test suite. I
want to see it run, but
anyone on the team, and I
want to see the actual
source code. I
typically look for a roughly
50-50 split between testing
code and production code,
although 60-40, or 40-60 is
also reasonable depending on
the situation. If I
see an 20-80 split then I
know there's a problem.
There are no hard and fast
rules, of course.
- Are stakeholders
active participants in
development? Your
project stakeholders can and
should
actively participate in
the development process.
Minimally stakeholders
should be involved on a
daily basis, they should
provide information in a
timely manner and make
decisions in a timely
manner. I should be
able to ask the team to
introduce me to their
stakeholder(s) and they
should do so right there on
the spot, or at least
respond with something along
the lines of "that would be
Beverley, and she's in a
meeting right now and can't
meet with you until 11am."
- Is the team
producing high-quality,
working software on a
regular basis? The
team should be able to show
me the working software that
they've built to date as
well as the source code.
The code should be
consistent because it will
have been written to conform
to a common set of
guidelines and the team will
refactor whenever
appropriate to ensure that
it remains of high quality.
If it is early in the
project, say the first week
or so, then I wouldn't
expect to see much. If
they're at least a few weeks
into the project then I
would definitely expect to
see some software. If
the team is several months
into the project then I
would also expect to see
evidence of a track record
of producing working
software.
- Is the team is
working in a highly
collaborative,
self-organizing manner
within an effective
governance framework?
Agile teams employ the most
effective
communication strategies
available to them, this
often means that they don't
write detailed
specifications and throw
them over the wall to each
other, and they
plan their own efforts
instead of having a project
manager do it for them.
But just because they're
self-organizing doesn't mean
that they're out of control
doing their own thing.
They must perform their work
within the context of an
effective
governance framework
which guides and monitors
their efforts.
- Is the team improving
their process on a regular
basis? A common
practice on agile project
teams is to hold a
retrospective at the end
of each iteration to
identify potential ways to
improve their software
process. More
importantly they act on one
or more of their issues the
next iteration, improving
their approach throughout
the project. Really
disciplined teams make the
effort to track their
progress over time and share
their ideas with other
teams.
You might find my articles
Examining the Agile Manifesto
and
Agile System Development Lifecycle (SDLC) to be interesting
introductions to agile
software development.
Also, my
various agile surveys provide some insight
into the how Agile is being adopted within
organizations.
 
Other Recommended Resources:
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.
|
