Chances are pretty good that you
think that there is something to the
philosophies and techniques described at
there is a big difference between reading about agility and actually becoming
agile. You've already taken the
most important, you've decided to consider new ways to do things, now you need
to follow through and actually internalize them.
I have three critical insights for
becoming an agile software developer:
don't have to be superhuman.
really just a mindset.
a generalizing specialist.
1. You Don't Have to be Superhuman
site describes a wide range of skills that agile software developers, in
Agile DBAs although
Developers should also have these skills,
should have. These include an
a formidable list. Am I asking too
much of you? It clearly isn't
realistic to expect you to become adept at all of these things overnight, but it
would be reasonable to expect you to pick up these skills over time.
After perusing this site, which provides a very good overview of all of
these issues, how long do you think it would take you to become reasonably
adept? My experience is that many
IT professionals can become adept at agile database techniques, when given the
opportunity, in several months. The
secret is that you need to be actively involved with a project and working with
others who already have some of these skills (or at least closely resembling
them). For example many Java programmers are familiar with some if not most of
the techniques listed for working with relational databases, although they might
not be aware of all of their options or the implications of each alternative.
Many DBAs may already be quite adept at evolving a database schema
although may not have taken it to the next level encompassed by database
refactoring. The point is that it
isn't as hard to pick up these new skills as you may think, you just need to
software development, in particular the
Modeling (AM) and
basics of object
modeling, and the object-relational
database techniques including
regression testing, and other
techniques such as mapping
objects to relational databases, database
transaction control, security
access control, referential
integrity, and effective
use of XML.
2. Agility is Really Just a Mindset
does it mean to be agile? Agility
is more of an attitude than a skillset. In
my experience, the common characteristics of agile software developers are:
how I didn't say that they program in a specific language, or that they have X
years of experience with JUnit, or that they are a certified DBA.
Technical skills are definitely important, but they aren't what
determines your agility. It's
your mindset that is the determining factor.
To help you grow into each of the four
roles defined by the
Data method, Table 1 provides some specific suggestions
that you should consider.
1. Recommendations to Become More Agile.
open minded and therefore willing to learn new techniques.
responsible and therefore willing to seek the help of the right person(s)
for the task at hand.
to work closely with others, pair programming or working in small teams as
to work iteratively and incrementally.
some experience as an application developer so you understand the
issues that they face.
basic DBA skills, reading Craig Mullins'
Database Administration is a good start, and enhance them with the techniques described
at this site.
that there is more to agile software development than
some database experience, often by working closely with your team's
that you're in a support role to agile project teams.
that you must be prepared to work in an evolutionary (iterative and incremental)
some experience as an agile developer and/or agile DBA to learn the
tools, techniques, and technologies that they work with on a regular
actively involved with agile development projects.
Enterprise Administrator (e.g. Data Management)
that you're in a support role to agile project teams.
that you must be prepared to work in an evolutionary
mentoring, and getting actively involved with, people on projects as
opposed to simply reviewing their work.
The books Who
Moved My Cheese and
the Winds of Change are both short,
well-written resources for anyone struggling with change, and
Change describes a wonderful pattern language for effective change.
The first book will help you to identify four common personality types
and their ability to handle change and both books provide advice for accepting
and embracing change in your day-to-day working life.
concept is 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.
is someone with one or more technical specialties who actively seeks to gain new
skills in both their existing specialties as well as in other areas, they have a
general knowledge of software development, and a good understanding of the
domain in which they work. 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.
When you do this you evolve from being a specialist to being a
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 the have the skills to get
anything done. In short, I believe that generalizing specialists are much
more effective than specialists or generalists.
My experience is that the best developers are generalizing
specialists, or are at least actively trying to become so.
There is still room for specialists within your IT departments, they can
often act as internal consultants to your development teams, but as IT
departments become more agile we will see fewer specialists surviving over time.