Information Technology Reference
In-Depth Information
topics that turn out to be noncritical. I am not saying order is unimportant, just
that often areas where we think we have order dependencies turn out to be
“soft” order dependencies at best. Any “hard” order dependencies can always
be added later.
A good example of order dependencies I refer to as “soft” is project planning.
When I teach planning, I talk about the “what,” “who,” “when,” “how,” and
“how much.” There are certainly order dependencies here. I can't fully
define the “who” (resources I need on the project) until I know the skills I
need, which depends on the “what” I need to produce. I can't complete the
“how much” it will cost until I have figured out all the other pieces to my
plan because they all imply some level of cost. Nevertheless, I can provide a
project plan template to be used as a great aid to help people plan without
telling them which sections they must fill in before others. Such dependen-
cies are best communicated through training, rather than captured through
formal documented process descriptions.
4.25 Do I Need to Make Sure Process Descriptions Are
Not Redundant?
Often I hear people in TWGs arguing over whether a certain activity should
be included in some process document. For example, in the technical solu-
tion TWG there was considerable discussion related to whether the design
process should refer to requirements development at the start of the
process. I tell working groups that it is okay to include words about an
activity that might be in another process if it adds to the understanding of
this process. Many processes are closely connected, such as requirements
and design. Because of the way most Agile teams work—iterating closely
between requirement, design, implementation, and test—it makes sense to
describe this process as it is executed in your organization. This is another
reason why it is best not to get too hung up on order. The traditional order of
requirements followed by design followed by implementation followed by
test isn't the way Agile teams work. While at a high level this view still
might make sense, the activities Agile teams follow during a given day
might appear to jumble this order.
The bottom line is that we want to capture the activities and products produced
that relate to our processes. If it helps to describe closely related activities that
are also included in another process document, it doesn't hurt to say it again.
