Agility and the Higher CMMI Level Practices - Integrating CMMI and Agile Development - page 45

Program Manager:
I believe there is an opportunity for some significant improvements in the
way we manage our core product development. Whenever we finish an
update, my developers come to me with great ideas to improve the product.
These ideas are fresh in their minds because they just finished an update and
know where the trouble spots are. They often have good ideas about where we
need to work the product to make it more reusable to achieve real savings
during the next product update. Unfortunately, no one is listening to them
at this time. Then when it comes time to do the next round of updates to our
product, someone from Systems Engineering gets involved and spends sig-
nificant resources diddling in DOORS 13 trying to come up with the
requirements for the next update. But unfortunately, the Systems Engineers
who are assigned don't understand the products we use to achieve many of
the customer's requirements. The way I see it, most of the work they end up
doing is just a rehash of old requirements and usually provides little real
value. We should be reusing more of the requirements and just making
updates that make sense from the customer perspective and where we know
we can improve the product. But unfortunately we spend huge sums of
money continually reinventing and diddling in DOORS and we don't get
the value from this effort that we should because the Systems Engineers
aren't talking to the developers who understand our products.
These comments hit at a common problem I see in many large organizations.
Senior Management wants more effective cost and schedule management. I
hear Senior Management in Engineering in many product-oriented organi-
zations driving for increased visibility and accountability of work effort from
a product perspective. There is often a business-driven objective to gain
more reuse and increase visibility of the relationship between cost expendi-
tures and product functionality achieved.
When I see this common pattern, I have often suggested that the measures in
that organization should be better aligned with the goals I am hearing. Fre-
quently in these cases, the measures being reported are functional department
measures rather than product measures.
What you measure drives what you focus on in your organization.
If an organization has this product perspective as a goal, they need to align
measures correspondingly. As an example, one of the best measures of prod-
uct functionality is tests passed versus tests planned (this is a common Agile
13. DOORS is a popular commercially available requirements management tool.