Information Technology Reference
In-Depth Information
you do real work in your organization. You don't need to make the final deci-
sion for process packaging at the start of your process improvement effort. In
fact, the brainstorming within TWGs may lead to the identification of
processes that should be broken out separately, and processes that should be
consolidated.
At BOND, the
Te c h n i c a l S o l u t i o n ( T S )
TWG broke out two distinct
processes referred to as Design and Implementation. Verification and Vali-
dation were consolidated into one process, which is common in Agile
organizations because the practices Agile organizations use for Verification
and Validation tend to have significant overlap. This is because a common
Agile technique is to develop complete slices of functionality in short incre-
ments, often leading to product demonstrations to the customer. As a
result, Verification and Validation techniques tend to blend in such envi-
ronments.
There was significant discussion over Project Planning (PP) and Project Mon-
itor and Control (PMC) at BOND. The TWG ended up keeping these
processes separate, although in other Agile organizations I have seen these
consolidated. The factors to consider when making the decision to keep PP
and PMC separate versus consolidating include the maturity of your organi-
zation's planning and project management activities.
In organizations where the project planning, monitoring, and control activi-
ties are sound and institutionalized, it can be more efficient to consolidate
and train these processes together. This is because the expected practices
under PMC align closely with those under PP and therefore can naturally be
packaged and trained together. PMC expected practices revolve around
monitoring and taking appropriate action associated with each of the items
in your project plan. However, if your organization is just learning how to
develop a project plan, it might be more effective to maintain distinct
processes so each gets its proper focus.
Risk Management (RSKM) is usually broken out into its own process area,
although in implementation in most Agile organizations it is frequently
integrated with project planning, monitoring, and control. For example,
most Agile organizations do not have distinct risk management review
boards. The risk management reporting is usually integrated with project
monitor, control, and reporting to Senior Management. Refer to Table 4-2
for an example of an Agile organization's eleven process descriptions and
how they could provide coverage for all eighteen CMMI level 2 and 3
process areas.
