 |
Table of Contents
|
|
Strategies for Working Together
AM’s practice of Active
Stakeholder Participation is an expansion of eXtreme
Programming (XP)'s On-Site Customer that
describes the need to have on-site access to people,
typically users or their representatives, who have the
authority and ability to provide information pertaining
to the system being built and to make pertinent and
timely decisions regarding the requirements, and
prioritization thereof. While this level of
participation is required to make your software
development efforts effective it often isn’t
sufficient in many organizations, particularly those
where politics and not reason are the order of the day.
Project success often requires a greater level of
involvement by project stakeholders – senior
management needs to publicly and private support your
project, operations and support staff must actively work
with your project team towards making your production
environment ready to accept your system, other system
teams must work with yours to support integration
efforts, and maintenance developers must work to become
adept at the technologies and techniques used by your
system.
It is clear that in order to be
successful all project stakeholders must actively work
with your team to achieve these goals.
There are several implications of this practice:
-
Timely decisions.
Stakeholders must to be prepared to share
business knowledge with the team and to make both
pertinent and timely decisions regarding project
scope and requirement priorities.
-
Inclusive modeling.
You need to adopt
inclusive modeling techniques, which are based
on
user-centered design (UCD) and participatory
design principles, which stakeholders
can easily learn and adopt.
-
Management requires IT skill and knowledge. For
senior managers to effectively support your project
they must first understand the technologies and
techniques that your team is using, understand why
your team is using them, and understand the
implications of using them.
With this knowledge their efforts within your
organization’s political arena are far more likely
to be effective at the right times in the right
ways. Senior
managers won’t be able to gain this requisite
knowledge simply by reading a weekly project status
report or by attending a monthly project steering
meeting. Instead,
they need to invest the necessary time to learn
about the things that they manage, they need to
actively participate in the development of your
system.
-
Production staff are involved from the start. Your
operations and support organization must invest the
resources required to understand both your system
and the technologies that it uses.
Your support staff must take the time to
learn the nuances of your system, the implication
being that they need to work with your system as it
is developed and/or your team will need to provide
them with training.
Furthermore your operations staff must become
proficient with both the installation and operation
of your system. You may choose to include one or two operations
engineers on your development team or once again to
invest project resources to train operations staff
as required. Regardless
of your approach, both your operations and support
organizations will need to be actively involved with
your project team.
-
Take an enterprise view. You need to
work with other
project teams if your system
needs to integrate with other systems.
For example, perhaps your system needs to
access a
legacy database, interact with an online
system, work with a data file produced by an
external system, or provide an XML data extract for
other systems. Integration often proves difficult if
not impossible without the active participation of
these developers: imagine how difficult it would be
to access the information contained in a large
legacy database if the owners of that database
refuse to provide any information about that
database. Some
initial architecture envisioning will help to
drive this.
-
Don't just hand-off to the maintenance team. Maintenance
developers need to work with you to learn your
system. When
the intention is to either partially or completely
hand-off the maintenance of your system to other
developers, it is common to bring in software
professionals skilled in maintaining and enhancing
existing systems to free up members of the original
development team, then your team must work with
these people so they can take over the system from
you. Even
when some original team members are still involved
an effort must be made to transfer the knowledge to
the new members of the team.
My definition of a project
stakeholder is anyone who is a direct user, indirect
user, manager of users, senior manager, operations staff
member, the "gold owner" who funds the project, support (help desk) staff member,
auditors, your program/portfolio manager, developers
working on other systems that integrate or interact with
the one under development, or maintenance professionals
potentially affected by the development and/or
deployment of a software project.
From this definition you can see
that business people, such as direct users and their
managers, aren’t the only stakeholders of a project.
As you know there is a wide range of people
potentially affected by a new system, therefore to
succeed you must understand and then synthesize their
requirements into a cohesive vision.
This is one of the things that makes software
development hard – each project stakeholder will have
their own requirements, their own vision, and their own
priorities – but it also makes software development
fun.
In this definition I have chosen to
exclude the developers who are working on the project.
This may seem strange at first because developers
clearly have an important stake in the projects that
they work on. Yes,
developers are definitely project stakeholders.
Why do I continue to distinguish between
developers and project stakeholders?
Because I want convenient terms to distinguish
them, I really don’t like “developer stakeholder”
and “non-developer stakeholder”, and because they
have different roles to play on a project.
My definition of project
stakeholder and developer may be different than yours,
or perhaps you prefer different terms.
For example,
XP discusses the
concepts of customer and programmer, not project
stakeholder and developer, and has slightly different
definitions because they use the terms differently than
AM does.
I used to talk about the rights and
responsibilities of project stakeholders, a concept that
I adopted from Karl Wiegers excellent book entitled Software
Requirements. Unfortunately,
I recently discovered that these rights and
responsibilities as written in
Agile Modeling weren’t as clear as I had originally
thought and were potentially even divisive.
So, after a fair bit of discussion on the AM mailing
list I've decided to reword the rights and
responsibilities from the point of view of everyone on
the project, not just the stakeholders.
The Rights of Everyone
-
To
be treated with respect.
-
To
produce and receive quality work at all times based
on agreed to project standards and principles.
-
To
estimate the activities you are actively involved
with, and to have those estimates respected by
others.
-
To
be provided adequate resources (time, money, …) to
do the job that’s been asked of you.
-
To
determine how your resources will be invested.
For people funding the project how the funds
will be spent and for people working on the project
(e.g. investing time) what tasks they choose to work
on.
-
To
be given the opportunity to gain the knowledge
pertinent to making the project a success.
Business people will likely need to learn
about the underlying technologies/techniques and
technical staff to learn about the business.
-
To
have decisions made in a timely manner.
-
To
be provided good-faith information in a timely
manner. Sometimes
this is just the “best guess” at the time, and
that’s perfectly all right.
This includes but is not limited to business
information such as prioritized requirements and
detailed domain concepts as well as technical
information such as designs and detailed technical
concepts.
-
To
own your organization's software processes,
following and actively improving these processes
when needed.
The Responsibilities of Everyone
-
To
produce a system that best meets your needs within
the resources that you are willing to invest in it.
-
To be
willing to work with others, particularly those
outside your chosen specialties.
-
To share
all information, including “work in progress”.
-
To
actively expand your knowledge and skillset.
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.
 |
|
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. |
|
