 |
There are several strategies which enterprise
professionals, such as enterprise architects or
enterprise data administrators, can adopt to become
agile. These strategies include: |
|
- Collaborate, don’t control. Agilists
collaborate with others to achieve their goals.
They inherently know that communication is critical
to their success and they do everything possible to
break down any barriers to communication which may
exist. They realize that the best use of their time
is to actively work with others, that trying to
control others from afar via defined procedures or
decrees is a futile effort at best.
- Focus on delivering working software on a
regular basis. Software development teams are
an important customer of enterprise groups, and the
primary goal of software development teams should be
to develop software. If you are able to help them
to this then you will be perceived as a valuable
resource to work with, otherwise you will be
perceived as an impediment to success and they will
find ways to go around you. Yes, project teams are
often narrowly focused on their own goals and are
usually under tight time constraints, but that
doesn’t mean you can’t help them to take enterprise
concerns into account without impeding their
progress. But it’s up to you to find a way to be an
effective member of that team.
- Focus on working closely with business
stakeholders.
Active stakeholder participation is a critical
success factor for any IT endeavor, be it a single
development project, a program of projects, or some
sort of enterprise modeling effort. It is easy to
forget this, or to convince yourself that you know
best and therefore can take on the role of
stakeholder, or to give up when your stakeholders
claim that they’re too busy to be actively
involved. The risk of building something which
doesn’t meet the true needs of the business far
outweigh the cost of obtaining active stakeholder
participation.
- Embrace change, don’t fight it. Change –
truly new requirements, an improved understanding of
existing requirements, or new/improved technologies
– is a cold, hard reality that we all face.
Agilists accept that change happens and find ways to
become efficient at responding to change. This can
be very difficult at first, particularly because it
involves the adoption of a new mindset and new ways
of working. In the end, isn’t it better to follow
an agile approach which reflects your environment
rather than a traditional approach which doesn’t,
even though you may not yet be comfortable or
familiar with this new approach?
- Be customer oriented. A primary goal of
enterprise architects should be to support and
hopefully guide both software development teams and
even the business. To do this effectively
enterprise architects must be customer-oriented and
that implies that they must find ways to work in a
manner which reflects their customer base. It is
important to recognize that a business modeling team
will very likely work in a different manner than a
team of seven developers taking an
Extreme
Programming (XP) approach who in turn will take a
different approach than a forty-person
Feature
Driven Development (FDD) project team. Therefore,
customer-oriented enterprise architects will find
ways to work with each of these groups in a manner
which reflects their unique situation. The
implication is that an enterprise group must be
flexible and prepared to work in ways which may not
be ideal for them.
- Focus on value. Agilists are constantly
asking the question what is the value of doing
something, and if there isn’t value then they
rethink their approach.
- Constantly ask if there’s a better way. Agilists
will also ask themselves if there is a better way to
achieve the same sorts of goals. For example, the
fundamental goal of holding a
review is to ensure that several people have
examined an artifact to ensure that it meets the
needs for which it was created and that it was of
sufficient quality. There are more effective ways
to achieve the same goal: the adoption of practices
such as collective ownership,
pair
programming, and
modeling with others ensures that several people
will work with the code or models respectively. The
point is that you need to question your assumptions,
many traditionalists will assume that you need to do
reviews because you can’t trust the work of
development teams whereas the real problem is that
people on the teams worked in relative seclusion
from one another and therefore were in a position to
create poor quality work that wouldn’t be detected
without a review. A side effect these practices is
that reviews are effectively held in parallel.
Context counts – reviews are best practices on
traditional projects that don’t promote
collaborative work, but they often prove to be
ineffective practices on agile projects which take a
highly collaborative approach.
I hope that you have noticed that my first four
strategies are basically rewordings of the
four values
of the Agile
Alliance (AA). The AA has some pretty good
advice to share with you, I highly suggest visiting this
site on a regular basis.
 |
|
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.
|
