I have been writing for the last several months about our adoption of the Scaled Agile Framework at Constant Contact.   However, I was recently challenged to think about a more core Agile question of how to best organize and manage our Quality Engineers.  Working through organizational structure as a leader within an organization is always a challenge but in this case I had to spend time balancing the “book” answers, with the needs of the organization, the staff that we have in place, and our current quality metrics.  This was made easier by the fact that we have already made the transition from Quality Assurance to Quality Engineering (QE).

Our Quality Engineers

All of Constant Contact’s Quality Engineers are real engineers, real people who write and understand code.  This isn’t a surprise given the Agile practices that we have in place, but does make it make the options much more flexible.  Our Quality Engineers spend time contributing to their teams by:

• Helping to define and write acceptance criteria for our features and stories.
• Defining the Test Strategies for each feature and story.
• Writing the automation tests for each feature and story.
• Providing Risk assessment for implementations and defect resolution.

Quality Engineers form one of the 4 legs of the Software Development stool that we like to have in place for every team.  The 4 legs of the stool are Product Owner, Development, Quality, and User Experience.  Each team has strong representation from each of the legs, and each leg has the ability to stop ship or escalate any issues coming out of the team if they can’t be resolved in the team.

Two QE Organizing Options

The decision of how to best organize and manage our Quality Engineers boiled down to two main options.  In option #1, the Quality Engineers report directly in to the Development Managers that are responsible for each Agile team.  In option #2, the Engineers report directly to QE leaders mapped to our Agile teams.

Option #1 is most in line with the most pure Agile management philosophy.  We could easily craft our organization in that mode, creating teams to handle our Automation Frameworks, our performance/scale and integrated systems test infrastructure and our metrics reporting.

Working for Option #2 was the fact that we continue as an organization to not only focus on quality at the individual team level, but also at the complete system level.  Each Quality Engineer’s primary team is their Agile team, but having them managed by someone who is focused on Quality Engineering, Quality Management, and Quality career paths is a strong benefit. The following key areas of thinking helped drive this decision:

• How complete is the transformation to automation from manual testing?
• How strong is each Agile team’s quality initiative?
• Do you have other Center’s of Excellence that the teams benefit from being mapped to?
• How strong is your existing Quality Management and Leadership?
• How interdependent and interconnected are your various Agile teams?

The Decision

In the end, we chose to organize using Option #2.  Our Quality Engineers primary responsibility is to their Agile team, but we value the benefits of the additional Quality focus and escalation paths over the pure Agile model.  As we move closer to team independence, stronger team quality initiatives and further mature our automation frameworks, we may  revisit this decision.

If you are an engineer who is looking to work in a dynamic empowering engineering organization that cares about making itself great, check out our open positions at www.constantcontact.com/jobs.

How have you organized the QE in your Agile team? Let us know in the comments section below.