Engage Quality Assurance

In a recent project there was a lot of discussion how to introduce Quality Assurance (QA) into an "agile" project. One key learning from the sprint retrospectives was that more formalism and more "process" would be required to achieve the desired quality of the product. The challenge was to find the right balance between needed formalism and unwanted organizational overhead and bureaucracy on one side and responsibility of each individual and non-effective & proven not-to-work selforganized QA by the development team itself on the other side.

Many discussions were going on with the customer and within the team and I was lucky to read a book by Coplien/Harrison (Organizational Patterns of Agile Software Development) by that time that brought my personal opinion to the point.

I would like to share the core statement with some personal additions and remarks here:

The engagement of the customer, requirements engineering and development is the key element of QA!

Developers might feel that they got everything right, but "a good dose of customer reality" can help them to bring the perspective that development of 100% perfect software is impossible.
It happens too often that organizations defer quality until "later" or make the mistake to equate QA with testing, which occurs later in the development process. The production of high quality work and early feedback is key to address fundamental quality problems and finalize a project successfully.

Remember: QA is not equal to Testing!

It is very important that developers perform their own testing but it is also a fact that they get blindsided very often by their own design thinking in terms of what needs to be tested. Further, they may use testing as their quality criterion. In contrast to the ideals of XP, test development shouldn't be blindsided by the developer perspective and QA needs to be seperated and independent in the interest of objectivity.

Remember: You can't test quality into a product - you can only build a product and test its quality!

QA needs to be established as a central role and needs to be legitimized by the organization. QA organization should be outside the context of development but needs to be tightly coupled with development as soon as development has something to test. The test plan creation can be done in parallel with the coding.
The planning and reporting of tests should not be accountable to the development organization. The sense of accountability for the development organization is to deliver a quality product that is free of bugs (minimized the bugs) that an QA organization might find.

Remember: Developers declare the system to be ready for testing!

QA needs to work closely together with architecture and requirements engineering as well in order to understand the needs and challenges the system will face in future. The QA people need to have the skills and the experience to "look behind" the things expressed explicitly in requirements/needs and specification documents and identify the core of the needs/pains and requirements and make sure that this is reflected in the system.

Remember: QA should be engaged early in the project. The system of quality is prevention, not appraisal!

In order for a separate QA to be effective, it must have frequent and positive interaction with develoment. It is not just the developers' responsibility to engage the testers - but the testers must reach out the developers as well.

Remember: Quality is free ... :-)

Yours,
Wolfgang

Business Ethics: Code of Conduct

I had a very interesting discussion with a former collegue of mine a while ago about business ethics, honesty & loyalty at work and the propable conflicts with the goals to achieve a maximum revenue, be ahead of your competitors, survive on the markt and sometimes even make the customer happy ...

Where he stood for the point that in the end the success (also including happy customers) counts and in critical situations "everybody is it's own best friend", all other things and business behaviour are a "matter of style", I personally believe that you are never succsessful if you push business ethics aside, no matter if the results turn out to be"successful" (even from the point of view of a happy customer). If you act otherwhise you even put the reputation of the customer at risk!

I asked him: What is the price for failing (e.g. unhappy customer)? What if the things that are done in the "grey zone" come to the surface? What are you willing to do to keep these things invisible? Can you see all the impacts? Where should the thin line be drawn and who can be the judge?
Well, the price is too high in my opinion - you not only put shame on yourself but you put shame on the company you work for and probably the whole profession.
My thinking goes the other way ... why don't we explain to our customers that we think (a lot) about these topics and that we are committed to ethical behaviour and think that this is an important enough thing to mention. Actually, this could be the "small thing" that makes you different from others ( if service portfolio is equal ;-) ). The important thing here is that you HAVE to believe in what you preach and to keep what you promise!

I can hardly remember when these questions were on an agenda or slide for a sales business presentation ;-)

Well, as an example I personally signed the PMI Code of Conduct after my certification and when I went to customers or spoke with potential partners I always made sure that these principles count for me. After the first strange looks at me, my feeling was always that this not only helped me to put down a baseline for the key rules to work together, but also built up trust on the other side which is essential these days when we think about the responibility and trust that needs to be given to us as consultants and service providers.

I think that it is a good idea to make it explicit (e.g. write it down and hand it over) as a professional that you are committed to business ethics and that your work should be judged by the compliance to this comittment.
I would like to lend some quotes from Stephen R. Covey that go something like this: “While we are free to choose our actions, we are not free to choose the consequences of our actions.” and "... private victories are the ancestors of public victories."

As an example you can find below the PMI Code of Professional Conduct that can be applied in a similar way to other professions ... (in short is says you will not lie, not betray anybody and you will take responsibility for your actions):

------

As a PMI Project Management Professional (PMP®), I agree to support and adhere to the
responsibilities described in the PMI PMP Code of Professional Conduct.

I. Responsibilities to the Profession 
A.Compliance with all organizational rules and policies 
1.Responsibility to provide accurate and truthful representations concerning all information
directly or indirectly related to all aspects of the PMI Certification Program,
including but not limited to the following: examination applications, test item banks,
examinations, answer sheets, candidate information and PMI Continuing Certification
Requirements Program reporting forms.
2.Upon a reasonable and clear factual basis, responsibility to report possible violations of
the PMP Code of Professional Conduct by individuals in the field of project management.
3.Responsibility to cooperate with PMI concerning ethics violations and the collection of
related information.
4.Responsibility to disclose to clients, customers, owners or contractors, significant circumstances
that could be construed as a conflict of interest or an appearance of impropriety.
B.Candidate/Certificant Professional Practice
1.Responsibility to provide accurate, truthful advertising and representations concerning
qualifications, experience and performance of services.
2.Responsibility to comply with laws, regulations and ethical standards governing professional
practice in the state/province and/or country when providing project management services.
C.Advancement of the Profession
1.Responsibility to recognize and respect intellectual property developed or owned by others,
and to otherwise act in an accurate, truthful and complete manner, including all activities
related to professional work and research.
2.Responsibility to support and disseminate the PMP Code of Professional Conduct to
other PMI certificants.

II. Responsibilities to Customers and the Public 
A.Qualifications, experience and performance of professional services 
1.Responsibility to provide accurate and truthful representations to the public in advertising,
public statements and in the preparation of estimates concerning costs, services and
expected results.
2.Responsibility to maintain and satisfy the scope and objectives of professional services,
unless otherwise directed by the customer.
3.Responsibility to maintain and respect the confidentiality of sensitive information obtained
in the course of professional activities or otherwise where a clear obligation exists.
B.Conflict of interest situations and other prohibited professional conduct
1.Responsibility to ensure that a conflict of interest does not compromise legitimate interests
of a client or customer, or influence/interfere with professional judgments.
2.Responsibility to refrain from offering or accepting inappropriate  payments, gifts or
other forms of compensation for personal gain, unless in conformity with applicable
laws or customs of the country where project management services are being provided.