January 5, 2017 // By Paul Grizzaffi
In a previous posting, I discussed the automation audience, making a distinction between the directly interested audience and those indirectly interested. There is another, equally important segment of the audience, members of which might be directly interested or indirectly interested. Because they are not obvious audience members at first glance, I’ve dubbed them the extended audience. Members of the extended audience are typically members of support and strategic organizations; some segments of this audience are critical to our success in that without them we can’t deliver a valuable automation solution, or possibly any automation solution at all.
Here are some of the extended audience segments I’ve partnered with over the years, some obvious and some not so much so:
IT/OPs
This one’s pretty obvious, I think. This team helps us with myriad different things including equipment, networking, and credentials. Keeping them in the loop on what we plan to do helps them plan and helps us not develop things they can’t help us support. I’ve found it best to engage with them by explaining the technology need driven by the business need; this allows us to all partner together to come up with a business-appropriate solution.
>Security
Want a shared ID with generally known credentials for running automation scripts? Want to have our own mail server that will receive test emails? Want to open a port to External Service Provider X to handle some aspect of our automation strategy? We’ll probably have to work with our security team. In some organizations, this may be covered by the IT/OPs team; in others, there is a separate team with which we should build a partnership. This partnership is as important as the relationship with IT/OPs because we may need exemptions to security policies, or perhaps a broad interpretation of those policies, to meet our automation objectives. I suggest engaging them in a similar way as with IT/OPs.
The “Business”
Though I mentioned business leadership in my previous post on audience, this audience segment merits a mention here as well. The business team (product owners, product managers, etc.) can be a great ally in our automation initiatives. I’ve found it strategic to have a partnership with business leadership when it comes to product technology decisions. Often delivery teams get excited by new, bleeding edge technology and are in a rush to implement it in a product. Unfortunately our testing process and automation technology stack may not be ready for that new product technology. Sometimes adopting the new product technology is the correct business decision. If so, the automation stack will need to be updated as well. If not, explaining the situation in terms of value and impact will help the business make good decisions.
Release Management / SCM
Want to get our automated scripts executed on every build or deploy? This is probably the team that will help us do it. For extra points, if we are building our own framework, we can work with this team to get our code in the main repository and in the continuous integration environment. Doing this helps us understand the environment that the product teams are using and will prevent us from having to build and maintain our own CI environment.
Procurement
Frequently, we need to purchase software or engage with 3rd party vendors to obtain technology or services or our automation needs. By partnering with our procurement teams, i.e. the teams whose reason for existing is negotiating for goods and services, we can potentially secure a better deal because we engaged with the experts. There can be some serendipity as well; more than once when working with a procurement team I’ve said “oh, I didn’t know we already licenses for that”.
Legal
This one is not so obvious and didn’t become apparent to me until more recently. Our legal teams can be of immense help when it come to evaluating license agreements and 3rd party business arrangements. Each company’s tolerance for risk is different; working with 3rd party software, particularly open source software, can entail some amount of business risk. Our legal teams can help us navigate the legalese of license agreements and EULAs so that we don’t inadvertently put our companies at risk. It’s best to get ahead of any license considerations so we don’t have to change tool and technology direction.
Facilities
This is another one that is not so obvious. Need a rolling white board in a shared area? Need a couple of tables and a room to house 34 “repurposed” laptops being used as automation clients (not that I’ve ever done that oddly specific thing)? The facilities team is our partner for these kinds of requests.
Building relationships and partnerships with these and other supporting organizations, is essential to our success. I’ve found that automation teams need to do things other teams do not; we’re probably the first to be asking for some of these things. As an ancillary benefit, the partnerships we build enable us to become facilitators and expediters between all of our partner teams (e.g. between the testers and legal, between the developers and IT, etc.).
Let’s not squander these valuable opportunities work across business lines to help deliver our products!
Paul Grizzaffi is a Principal Consultant at Magenic. This post was republished from his personal blog and can be found here.