Around nine months ago, our engineering productivity (EP) team was in its infancy. We had just rebranded from QA, and our top priority was automation. I've touched a bit on our overall goals previously. This post isn’t about that. Today, I want to talk about a role we’ve never had before on our automation projects, and it’s one we have found to be indispensable—Meet the product owner (which leads to Automation Program Management).
Setting Priorities
A product owner for a team working on automation frameworks, you ask? They can’t just build a framework?
I don’t remember a time when we’ve had a dedicated product owner until we formed our teams within EP. This usually meant we had scrum teams, and someone within the team acting as scrum master (usually a development manager, who also acted as a PO—or, one product manager spread across way too many scrum teams).
While that approach may seem efficient, it can lead to bias. If you aren’t careful, you may tend to set priorities based on what the teams want to work on (especially if you are a direct manager of the people in the scrum team), which may not always be what the needs of the business are. As a product owner, I am able to step back, look at the work going on across the teams, set priorities, and work with the team to build a backlog that meets those needs.
That said, you may have many automation projects to handle. What do you do in that case?
Automation Program Management
That’s where the automation program manager comes in.
Since we haven’t mastered cloning (or really answered if it’s ethical), you may find you need POs sitting on a few automation projects. It could help to have someone who can assist with coordinating the broad goals, and work with those automation product owners to build towards the vision—I’ll call this person the automation program manager.
While tech stacks may vary across products or teams, there are some underlying similarities that the automation program manager can help POs with, working very closely with leadership to ensure all business priorities are considered. Automation teams tend to be very heads-down in their work. The product owners (and program manager) can help in several ways here:
Identify the business needs of all end users (be a PO! Interview your engineers! Talk to your test engineers!) to build the best framework for your situation.
Work with other leaders to know what is being built and when. Why ensure there is testing in place for one feature when feature teams are working on something else? (Especially when you are getting started, scrum teams may not be entirely up to speed with writing tests yet. You will need some examples.)
Work with product architects and experts to understand the vision, and help think about the plan and goals for your automation projects. Know what may be in the pipeline to ensure the automation frameworks can support that.
Evolving Roles in Testing and Automation
Almost every book or blog you read talks about the evolution towards test engineers and software engineers in test, and agile books talk separately about the product owner, but mostly from the perspective of a team building features for a client. I’ve found the PO very, very necessary in automation so far, as well as the need for Automation Program Management as we grow our teams and spread our mission. This is something we learn as we go, and if you have had success, I’d love to hear your story!
Ashley Hunsberger is a Fixate IO Contributor, Quality Architect at Blackboard, Inc. and co-founder of Quality Element. She’s passionate about making an impact in education and loves coaching team members in product and client-focused quality practices. Most recently, she has focused on test strategy implementation and training, development process efficiencies, and preaching test-driven development to anyone that will listen. In her downtime, she loves to travel, read, quilt, hike, and spend time with her family.
