I’ve been blogging about our Agile Transformation at Constant Contact for almost 2 years.

We applied a number of the lessons of the Scaled Agile Framework in our teams. And since February of 2015 I have blogged about focusing on our teams and their practices, instituting standard SCRUM practices. Today I am going to revisit one of my early posts on organizing the quality organization.

Two Options for Organizing QE

As I described in my previous post, there are two main options for organizing Agile teams with respect to quality engineers. 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 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 our organization continues to focus on quality at the individual team level in addition to 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 key questions below helped drive the decision:

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

In the end, we chose to organize using Option #2. Our Quality Engineers’ primary responsibility was to their Agile team, but we valued the benefits of the additional Quality focus and escalation paths over the pure Agile model. But as I suggested I might in my previous post, I wanted to revisit that decision.

Revisiting The QE Decision

As we continued to implement SCRUM, we found that our team dynamics started to change. (This is a good thing!) There were several observations that I made that told me it was time to re-evaluate. This would probably be a good list for anyone in the same position.

1. I started to see strong teaming behaviors and teams asking management to deal with situations where someone didn’t mesh. Sometimes an individual doesn’t mesh with a team, and that’s OK, but our job is to protect, grow, and support the team. When the teams are crafting their own behaviors, do you have the right organization to help them succeed?
2. The teams started taking responsibility for their own quality metrics. I saw real discussion about the quality of work being delivered. Teams were (without management) making arguments that their bug backlog was getting too high, and that they weren’t holding to a strong enough definition of done.
3. It became more obvious that the split management hierarchy was NOT helping the SCRUM team come together because they would get different messages or subtle differing direction and prioritization.
4. Our development engineers started realizing that they needed to be part of the quality effort for their teams. Led by the expertise of the QE on the team, everyone on the team was writing automation tests and looking at build systems and issues.

With these observations, it became clear that we were ready to make the organizational change from embedded QE folks within teams to QE’s reporting directly to the engineering managers for each team. Some in the SCRUM community would say this is an obvious step, and I would agree, but each organization is different. As leaders, we have to do what is right for the culture, people, and organization that each of us has in front of us.

Implementing the Change

Making an organizational change is always difficult. Luckily, we noticed other areas in the organization that needed help. We had some managers return to individual contributor roles, and we had others move on to lead other SCRUM teams.

Like any organizational change, it’s important to look at your goals, be transparent with the reasons and the metrics around the change, and explain what you are observing and what you hope to gain.

Thanks to the amazing engineers at Constant Contact and the way they have adopted the change, the organization adapted quickly, with many teams commenting that they thought I was slow in making the decision.

If you’re 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.

Mike Adler

VP, Engineering