August 30, 2006

SQA: Coach

With audits, reviews and issue handling being the predominant responsibilities, an SQA responsibilities move towards mundane daily tasks. With time, role of the SQA is understood well and with understanding comes the predictability in the work. Organizations, SQA functions and the SQAs should seize this opportunity and raise the level of services rendered to the projects by ensuring that an SQA act as a process coach.

An SQA should spend much of the time in coaching the project teams on organization's software development processes. Although this approach is recommended in the Organizations where the process improvement initiatives are new, however, it is of equal importance to the mature organizations.

While in the immature organizations, where the process improvement initiatives have just begun, SQA can coach the project teams about the organizational process assets, the SQAs in the mature organizations can coach the project teams about the improvements areas with in the projects, while the mundane tasks like audits can be performed by project teams.

Thus with this approach, while the day to day tasks are taken care of, the thrust on improvement initiatives makes sure that the improvements keep happening the organization.

August 23, 2006

SQA: People Person

Let us have a look at the primary duties of an SQA.

The audits, the review meetings and the escalations to resolve any quality issues in a timely manner.

In brief, an SQA has to get things done, in time, from people with whom he does not have a reporting relationship. He has to ensure that the process violations are minimal even when he is not in charge of the projects.

Talk about project teams and you know you are talking about people who have less and less time, who have lots of deliverables to work on, who have deadlines and who keep this evergreen statement in mind, "Customer wanted it yesterday!!!".

SQA often gets to work with such teams and its these teams who have to ensure that the project has no non compliances and liaisons with PMs/PLs or TLs.

If one is not careful, tactful and sensitive about handling 'stressed' people, the resulting chaos may not be suitable for the project's objectives. SQA can easily be blasted, can get a sly reply, a ridiculing laughter or a blunt answer indicating a clear refusal.

It may be argued that, if a project team does not see any value in a process, it should be presented that way or a deviation could be sought. The argument is good, not practical, however. There are many factors that drive process/product compliance or non-compliances like deadlines, pressures, attitude, skills levels etc.

Moreover, many times, it becomes imperative for the project teams to keep up with the pressures from various quarters and thus they tend to ignore the compliance issues unless they have been directed by the senior management or the customers.

Therefore, it's highly recommended that SQA should empathise with the project teams, strive to understand their work and working environments and build better relationships in order to enthuse a confidence in the project teams about software quality processes.

Its not possible to do it without being a people person. Isn't it?