Is QA Seen as an Impediment in Your Organization? 

November 3, 2016 — Posted by Maurizio Mancini

Is QA (aka QC) seen as an impediment in your organization? If you answered yes to this question, then chances are your organization is in one of two camps:

1) QA is really an impediment


2) QA is actually ensuring that your organization is releasing quality software.

QA Is Really an Impediment

Some organizations still have formal QA departments that execute testing as a separate phase from the development team. While this may be a necessity in some industries due to laws and regulations, for most other organizations where this is not required, it is usually a sign of a QA team that is not ready to change. It is a sign that this QA team is not ready to meet the needs of a software team that is being asked to deliver software more frequently and keep the level of quality high.

Usually this is a sign that some members of this QA team are concerned about the obsolescence of their role as they see signs of the developers being able to do their jobs through automation.

However, if this is the type of team in your organization, then someone needs to make that team aware that the move of the majority of software organizations towards Agile, is an opportunity rather than a threat.

When we encounter teams like this we ask them; “Why would you prefer to do a job that is very repetitive and sometimes not valued, over a job that would challenge you and would be valued by the organization?”

There is a new role for QA in the Agile world! QA teams that are being an impediment just need to be shown what these new roles are. 

QA Is Actually Keeping the Organization Humming

With the ever increasing demands to release software more frequently, sometimes the QA people seem like an impediment but in reality, it is the QA people that are actually allowing the team to deliver the software. Deadlines are forever pressuring developers to write code faster and get it out. This constant pressure can cause developers to cut corners in an effort to “just get it out”. In this case, most developers actually find solace when their QA teammate helps remind them the implications of releasing code that’s just not ready. It is in this solace that the appreciation for their QA teammate is highest. At this point the developer and QA actually work together to ensure that a better quality software is released on time.

When this happens, it is one example of building in quality rather than trying to test in quality!

In this example the QA team member initially looks like an impediment but he/she is actually trying to ensure that the software is released with quality rather than working in a “Break/Fix” mode.

The concept of building in quality has been around for years. One of the best known advocates of building in quality is Philip Crosby. Mr. Crosby was one of the first people to advocate that if you build something of quality, then Quality is Free! He had many different ways of delivering this message to management but this was the essence of his message.

Most QA people in organizations have this kind of a mind set and try to advocate it but are frequently seen as signs that the QA person is an impediment to just getting it out! Remember that when a QA teammate provides their feedback on the state of a feature in the software, they just want to deliver the right features, at the right time with the quality that the end user would expect.

With the move to Agile, the decision to ship has now been moved to being a Team decision based on their Definition of Done. Even though QA is now part of the Team, it is still the QA person that will bring this quality mindset to the team. A mindset that must be shared across the Team.

If you are still thinking that despite a QA teammate’s good intentions, they are still an impediment, think of one more thing.

Delivering quality software means that you incur less Technical Debt, less Technical Debt means that the Team will be able to work on new features in future sprints rather than working on refactoring code and features.

Finally, these higher quality deliverables are essential if one of your goals is Continuous Integration and eventually Continuous Delivery. It will mean that your organization is able to respond quicker to market forces and it will translate into a competitive advantage for your organization. An advantage that will translate to savings and sales for the organization!

If you want to know more about how to ensure that your QA team members can help ensure higher quality deliverables, while meeting the fast moving software delivery train, please contact Exempio or Net Objectives for a consultation.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Maurizio Mancini

Maurizio Mancini is a leader in the quality and process industries with a sixth sense for Agile, quality, and business process. He is best known for cutting through the noise and getting to the heart of any organizational problem whether that problem consists of choosing the right software development process, implementing modern quality approaches, or just finding the right balance between people, process and tools. Maurizio’s approach consists of empowering people and teams so that the team's talent and creativity comes through naturally. This mindset favors the adoption of Agile values in any environment.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban