|
Guerrilla SQA
By: Bret Pettichord
Abstract
Adequate resources and senior management commitment are oft-cited prerequisites to
successful process/quality improvement activities. What if you have neither? The metaphor
of guerrilla fighters seems appropriate for the inch-by-inch “underground” effort which can
characterize in-the-small process/quality change attempts. This paper suggests how to
introduce software quality assurance (QA) and measurement practices where they might
most easily be accepted without taking mainstream development tasks head-on.
The paper begins by describing an in-the-small, limited resource (“guerrilla”) approach and
the context in which it is applied. QA and measurement practices are recommended which
support one another and encourage data-centered decision-making. Implementation
behaviors to avoid are noted to reduce the resistance faced when introducing such
practices flow. A connection is also made between these practices and project risk
management since they complement one another.
The “Guerrilla” Approach –
Guerrilla fighters, as opposed to a formally recruited and supported force, have to replace
resources with dedicated belief that what they are doing is worth the sacrifice. The armed
force likely has the authority of “government” (corporate management) behind them while
the guerrilla can, at best, hope for benign neglect from the formal hierarchy as long as they
don’t seem to be in the way of “real work.” The guerrillas often encounter resistance from
the mainstream “ruling party” (development organizations) who, in all fairness, are given
other priorities and whose leadership (middle management) has, indeed, been rewarded
for succeeding with the behaviors now in place.
The guerrilla fighters learn to “live off the land” finding the things that feed people’s desire
for change/improvement. Because resources are limited and because those they seek to
help are usually less adventurously inclined, the guerrilla fighters’ “weapons” (methods and
technology) have to be simple. These restrictions also mean the effort must achieve results
through “quick strikes” (short-term) not lengthy “campaigns.” And to sustain the gains
achieved, a “power to the people” philosophy has to be adopted since the guerrilla fighters,
as they move on to the next “encounter,” will have to leave behind (technology transfer) the
ability for the people to carry on themselves with few resources and basic technology.
Finally, guerrilla fighters come to understand that not all coups are successful and not all
guerrilla leaders become heroes.
Context for Introducing the “Guerrilla” Approach –
The guerrilla approach is based on in-the-small activities which build up, bit by bit, over
time into evidence of some “better way” of doing things. If you listen to people talk or read
what they write about in-the-large success, one thing becomes clear: an essential element
of the success was making it mandatory. One way or the other, management is given the
message that being a part of the program is a requirement for staying with the organization
(i.e., a “condition of employment,” as one senior manager put it in a process conference
keynote talk last year). Even with such support, there will often be resistance from middle
management who have “heard it all before” through various flavor-of-the-month programs
and who have learned over the years how to weather the political tides in corporate
existence to achieve what they perceive to be the “real work” expected of them.
The guerrilla fighter must be sure that, no matter the size of the organization, someone
feels that things are not “fine as they are.” Dissatisfaction with the status quo which is
identified and accepted above middle management will usually get the resources and
support (or at least pressure applied) to make something happen with formal
organizational visibility. The guerrilla fighter deals with the “local population” (line
management and staff) who sense a problem but cannot get the attention and resources to
attack it head-on.
Development groups produce the fundamental deliverables to make a software system
“happen,” i.e., the executable code and related system elements. They often receive the
largest share of project resources (e.g., people, funding, schedule) though they are
regularly asked to do with fewer of them. They also usually have the most technology
support for what they do because of years of industry focus on source/executable
deliverables and the automation potential inherent in such deliverable formats. On the other
hand, they are usually faced with the most unpredictable technical situations, constraints,
and choices. All this inclines them to be reluctant to have “outsiders” tell them how they
“should be doing things.”
Therefore, the guerrilla approach recommends a path which bypasses such “strongholds”
in favor of working with areas in the company which may receive less attention, fewer
resources, and little technology support: requirements management, project tracking,
system (independent) testing, and client (hot-line) support. All of these areas are critical to
how the customer is likely to perceive the end product, its support, and its evolution (i.e.,
viability over time). From a customer perspective, the assurance of software product
quality is likely to rest with these organizations.
Focusing Attention On SQA and Measurement –
A large part of the software industry has come to equate QA almost exclusively with
activities related to testing code and, upon hearing the word “metrics,” envisions counting
lines of code (LOC) or function points (FP). Given this view, the broader range of QA
activities may either not be performed, performed consistently, well-coordinated, or
monitored for effectiveness while metrics/measurement programs are seen as requiring
development staff and management to take on data collection and reporting tasks with little
return for the time invested.
Fundamentally, software QA and measurement are about achieving quality through greater
visibility and more deliberate communication about how the customer’s requirements are
transformed, bit-by-bit, into a functioning software product. Despite the significance of the
role of testing in the development of software, it is an after-the-fact QC function which
identifies errors that already exist in the software product. Test personnel can have
important QA impacts earlier in the lifecycle which will be discussed, but the activities
related to testing code fit the QC function not a QA one. QA is foremost about trying to
prevent, not detect, errors and uses detection (QC) results to that end. Measurement
provides support for evolving a data-centered approach to focusing QA and improvement
efforts.
Though it sounds strange on the face of it, “depersonalizing” quality is an important first
step in reorienting thinking about software quality. By “depersonalizing” is meant, not
removing personal responsibility for quality or for what is produced, but removing a too
individual view of project deliverable ownership. If individual egos and personality become
identified with specific deliverables, not overall results, it will be difficult to achieve the
necessary visibility and improved communication for effective QA and measurement to
grow. Unless there is a shared responsibility for the quality of the transformation from
requirements through testing, problems may be viewed as purely matters of individual
competence and performance, leading to a focus on the deliverer rather than the
deliverable. Because of the culture of many organizations, the guerrilla approach of
avoiding mainstream development activity is often the line of least resistance in beginning
to make this point.
It will also be important to develop the understanding that QA is about more than testing
code since this is what large portions of the industry, fueled by recruiting advertisements,
define it to be, especially in commercial product development and in-house information
technology environments. For this reason as well, focusing attention away from
mainstream development helps to develop a broader view of what QA (both validation and
verification) should mean to an organization in “building the right product right.”
A broader view of QA should also be a way to encourage the development of a project
culture based on data-centered opinions. The practice of collecting and using data to
provide objective background for decision-making is constructively introduced through
guerrilla QA. Guerrilla QA includes data collection for immediate, local needs, which can
become the basis for eventually providing information of use in the mainstream
development lifecycle.
Finally, the link between QA, measurement, and risk analysis and management needs to
be made. Effective QA and measurement contribute to risk management by providing
feedback on how a project is progressing and where potential problems may be
encountered. Developing confidence in the predictive value of such feedback ultimately
leads to a willingness to take on more aggressive project goals with greater confidence. In
return, risk analysis helps establish specific quality-related goals which provide the visible
needs to which QA/measurement practices can be applied and by which broader
application of practices can be justified.
The V-Shaped Model –
Making some of these points about software QA and measurement may become easier
using a V-shaped lifecycle model of the software development process common in Europe
over a decade ago. Its main purpose at that time was to make the link between major
software product deliverables and the validation (testing) activities associated with them.
Adding a few elements to the original diagram makes the context of the guerrilla approach
and its QA/measurement philosophy more clear.
The original model was the “V” with requirements, design, and coding positioned to
represent higher to lower levels of specification which parallel unit, integration, and system
testing representing internal logic, interface, and external functional validation of the
product. Elements added to the model for the sake of this paper include labeling the Build-
Verify-Validate aspects of the lifecycle, the quality assurance-control (QA-QC) scoping, the
positioning of review processes, key measurement areas, and the dividing line between
mainstream development tasks and those likely to be conducted “independently” of
development organizations.
Full article...
Other Resource
... to read more articles, visit http://sqa.fyicenter.com/art/
|