 |
Presentations to project
stakeholders are a reality on most software projects:
senior management wants to keep track of your status,
stakeholders who are not directly involved on a
day-to-day basis need demonstrations of the current
version of the system, and other development teams
working on systems that integrate with yours need to
understand how it works.
You could provide documentation for these groups
but this often isn’t very effective – if you’re
traveling light you may not currently have the
documentation that they need. Furthermore, as you’ll read in
Agile
Documentation, documentation is a very ineffective approach to
communication.
|
|
The
bottom line is that you need to be prepared to give
presentations to project stakeholders, and agile models
can and should be a part of your presentations.
Here’s how to be more agile:
-
Minimize the number of
presentations that you give.
The best presentation is the one that
wasn’t held.
Presentations should have a clear purpose, a
well-defined audience (it should be clear why each
person is there), and a justification for why it is
required.
-
Try to find an alternative. Perhaps a quick telephone conversation, a face-to-face
conversation in the hallway, or an email will do.
-
Turn the presentation into a
working session.
You have project stakeholders in the room so
put them to work.
Work with them to identify new requirements,
delve into existing requirements, or prioritize your
upcoming efforts.
-
Make project stakeholders
aware of the costs.
Everybody loves fancy slides, but do they
realize how much effort it takes to put them
together? Do
they realize that the time invested in making fancy
slides could have been spent on developing software?
-
Project stakeholders decide
whether they wish to have a presentation.
Like documentation, the decision to hold a
presentation to project stakeholders is a business
one that is the purview of your project
stakeholders.
-
Keep it simple.
Are your stakeholders interested in the
system that you are building for them or in your
Microsoft PowerPoint skills?
Many people make the mistake of investing
significant time preparing “pretty slides” for
their presentations.
I used to spend hours transcribing hand-drawn
diagrams into a drawing tool to make them suitable
for inclusion in presentations.
Then one day I ran out of time and was forced
to simply include a scanned drawing in a
presentation. Nobody cared.
The world didn’t end.
Since then I’ve included more and more
hand-drawings in my presentations, and invested
fewer effort in transcribing the diagrams, and the
world still hasn’t ended.
The few times when I’ve received any
comments regarding this approach I tell my project
stakeholders point blank that I had to decide
between spending my time drawing pretty pictures and
building software, so I naturally choose to build
software. Nobody
ever complained.
In short, apply the principle maximize
stakeholder ROI and be smart about what
you do.
-
Minimize the number of
people involved in preparation.
Do not distract the entire team with the
creation of a presentation, it doesn’t have to be
a committee-based effort.
-
Minimize the number of your
people attending the presentation.
Everybody on your team doesn’t have to
attend every single presentation.
-
Remember that you need to do
more than simply
present. You also need to
prepare for the presentation and often follow-up
after it.
Presentations can and should be effective
communication opportunities for your project team, if
you choose to keep them simple.
 |
|
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.
|
