Agile Attitudes- Tear Down the Wall -- Do SQA First

[agileattitudes at agilerules.com]

Agile Attitudes
Volume 1, Issue 11                                     Nov. 4, 2004
                 A free bi-weekly email newsletter
                        Brought to you by
                     Agile Rules consulting
                       www.agilerules.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Welcome to Agile Attitudes, a newsletter of ideas, insights and
technical tips that help people find better ways to develop
software. Feel free to share this with anyone - just be sure you
send or print the whole thing, including the copyright notice.

Directions for managing your subscription are below.

                         O><O><O><O><O><O

Ron Morsicato will be discussing agile software development at
the next meeting of the New England M User's Group. Damon Carr
of Agile Factor will be the main speaker. The meeting is Tuesday,
November 9 at 6:00 PM. For more information and directions see
http://www.nemug.org/nov04mtg.html

                         O><O><O><O><O><O
                Tear Down the Wall -- Do SQA First
                         by Ron Morsicato

A few years ago I was audited for conformance to a particular
industry standard. The first question the auditor asked me was
whether or not development and SQA were separate organizations
within the company. Having several military contracts, I was
able to answer to the affirmative on the behalf of the company.

This was a very telling question. It supposed that in order to
do business with my company, the auditor had to make sure that
SQA could in the future become his proxy, conducting audits. The
result would certainly lead to an authoritarian relationship
between SQA and development. It seemed like the premise of the
question was that some structure has to be in place to make sure
developers do the right thing (whatever that is!) not because of
their beliefs, but because they would have to answer to their
company's "process police."

This kind of relationship produces conflict, whereas agile
practitioners try to foster collaboration. We at Agile Rules
have often pointed out that the development pattern for testing
one's code is in the exact reverse of typical industry practice -
we write unit testing code first, and then go on to write
production code that passes the test. Similarly, the agile
outlook on the role of SQA involves doing things in reverse of
the conventional wisdom. Rather than tossing the code "over the
wall" for SQA to test after it's written, SQA develops the
acceptance test for the code prior to it being written.

Good things happen when you do this. First of all, how often have
you seen a "throwback" of the code by SQA because of disagreements
on the interpretation of requirements? If you've been around as
long as I have I wouldn't be surprised if your answer is "All too
often!" When SQA writes acceptance tests first, a development team
is charged with "Write code that passes this test" rather than
"Write code that meets this requirement." The task is clearer and
a potential major stumbling block is avoided. Everyone benefits
when success can be objectively determined.

Another good thing is involvement. A common complaint among SQA
personnel is that they have difficulty seeing whether the software
behaves as advertised internally when there is no visibility into
its internal workings. When SQA and development collaborate from the
start, development can provide a "tester's view" into the software.
Without such a view, it is more likely that software with an
internal bug will be released into production.

So next time you're confronting that "release engineering" process,
anticipating it as where the trouble begins, remember that there's
an alternative that just might help you get better working code out
the door sooner.
 
                         O><O><O><O><O><O
More articles on Agile software topics at http://www.agilerules.com
    Within our company we have a sub-specialty in embedded systems.
    Our site has articles on embedded XP and we support a discussion
    list focused on the use of agile methods for building embedded
    software. The list signup info is at
    http://www.agilerules.com/mailinglists.phtml

                         O><O><O><O><O><O
To help you get started with in-depth research into Agile Attitudes
    topics, we have added a Library section to our web site at
    http://www.agilerules.com/library.phtml
    Order using our links and receive discounts up to 30%!

                         O><O><O><O><O><O
If you enjoyed this issue or found it useful, forward it to a
    friend! Help spread the word about better ways to build software.
    Invite your friends and colleagues to join our growing reader
    community at http://www.agilerules.com/mailinglists.phtml

                            O><O><O><O><O><O
Looking for a speaker for your next corporate or society meeting?
    We present dynamic, informative programs on topics of interest
    to managers and technical staff in their transition to more
    flexible, robust ways to create software.

                         O><O><O><O><O><O
Want to reprint this issue in your company or society newsletter?
    For permission to reprint any of the articles, contact us at
    info at agilerules.com.

                         O><O><O><O><O><O
Your feedback is welcome! Send feedback to info at agilerules.com

To manage your subscription:
    http://www.agilerules.com/mailman/listinfo/agileattitudes

                         O><O><O><O><O><O
            Brought to you by Agile Rules consulting
              162 Marrett Road, Lexington MA 02421

                 Copyright (c) 2004 Agile Rules
                       info at agilerules.com

                         O><O><O><O><O><O
Privacy notice: We will not release a subscriber's address to any
third party for any reason. This is a strictly opt-in newsletter.
No one is ever subscribed without their explicit request.