How to Reduce Test Environment Conflict

Test environment conflict is when two projects or two releases require access to the same testing resources at the same time. For a Test Environment Manager this might mean that two projects need to test against the same database or deploy to the same environment at the same time, and for a release manager this might also mean that projects require services from the same QA or release engineering team.

Test environment conflict tends to delay every project in an IT portfolio at once as project schedules are interdependent and a delay in one part of the department can cause cascading schedule slippage. In the best case test environment conflicts happen rarely and teams plan far ahead, and in the worst case test environment conflict can paralyze an entire IT department.

In this post I focus on some solutions to test environment conflict. I’ve outlined some best practices that will allow you to avoid these conflicts in your organization.

Best Practice: Track Release Schedules in a Single, Consolidated Dashboard

This is what Plutora provides. Tracking all of your projects in Plutora gives you the ability to create a single, consolidated release schedule. You can track the effort required for environment setup and teardown and you can gather information about prior releases so that you can learn from prior incidents of test environment conflict.

When you have a single release schedule everyone is on the same page about the sequence of events. You can point both management and your own internal customers to this single, consolidated dashboard so they understand the larger picture. Without a single, consolidated dashboard you run the risk of miscommunication. If you track release schedules and project timelines in a series of disconnected Wiki pages or Excel spreadsheets these will grow inaccurate over time and you’ll spend up to 20% of your time in meetings trying to reconcile different sources of truth.

How can you avoid test environment conflict if you can’t even agree on a single release schedule? Use Plutora and you’ll fix that situation immediately. You’ll avoid test environment conflict because everyone will have the same view of the release schedule.

Best Practice: Dedicate Test Environments to Important Projects

The easiest way to get rid of test environment conflicts is to simply dedicate test environments to all of your important projects. If you are moving toward continuous delivery you are likely already doing this as projects that can be delivered at any time require dedicated test environments all the time.

If you are moving to the cloud or if you are practicing agile you should consider maintaining dedicated QA and staging environments for all of your projects.

Best Practice: Measure each Project’s Release Commitment Success Rate

Every project and every manager has something like a “batting average” for success. When a project makes a scheduling commitment you need to have a tool that allows you to keep track of this and measure how early or late a project is when they are ultimately ready to deliver software to a QA or Staging environment.

Every test environment manager understands the difference between what a project promises and what is ultimately delivered and test environment managers often take it upon themselves to adjust timeline commitments accordingly, but with Plutora you can start tracking this more accurately so that you can adjust your expectations on the project or person making a promise.

If a project is regularly on time or beating a schedule you should plan accordingly. On the other hand if a project is continually missing a delivery date by weeks or months you need to be able to factor this into your environment assignments and plans. Plutora gives you this insight and allows you to slice and dice past release commitment data to calculate a “batting average” for each project. This will allow you to make informed adjustments to avoid test environment conflict.

Best Practice: Be Transparent with Your Customers

Everyone should have access to immediate information about not only their project status but the status of other projects they depend on. With Plutora you can grant project managers and engineering leadership access to up-to-date dashboards that capture release-related timelines and risks without having to assemble this information into manual Wiki pages or Excel spreadsheets.

If everyone is able to see release risks evolve in real-time you don’t have to schedule meetings just to gather the data necessary to get an accurate picture, and you don’t have to wait to tell teams that they need to make adjustments. With Plutora, everyone is looking at the same data and when it changes they can react quickly. If one project provides an update that a critical timeline is going to be missed this information can make its way to other projects immediately. This level of transparency makes release and project management more agile and more immediate.

Best Practice: Be a Conduit for Communication, Not a Bottleneck

If you are a test environment manager or a release manager you’ll understand that it’s better to be a conduit for projects to communicate with one another than it is to be a bottleneck. In today’s fast-moving environments you want to enable as much “peer-to-peer” communication between projects as possible. The transparency I discussed in the previous item is part of this, but having a single repository of information is another.

With Plutora teams using disparate issue trackers or other systems to support planning can communicate with one another using a shared reference – a single source of truth. If a team needs to communicate with downstream dependencies it can use Plutora’s RACI diagrams to understand who needs to be involved in any given conversation. Instead of scheduling a meeting to figure out who needs to be involved in the next meeting, just check Plutora and generate a report including all of the responsible parties from a combination of RACI matrices.

If a project needs to communicate about a potential delay of test environment conflict they can leverage the tool to make sure the right people are involved in that conversation.

Best Practice: Justify Delays When Necessary

This is mostly directed at test environment managers. If there is a test environment conflict that requires a delay you are often in the unfortunate position of informing entire projects or departments that their critical timelines are about to be missed. You can say “don’t kill the messenger” all you want, but it’s very likely that projects will come to see test environment managers as part of the problem. Over time this will lead to more conflict, and you’ll start to be associated with the problems caused by other projects.

If there is a test environment conflict you can use Plutora to make the reasons for this delay known to all. If another project is running late and consuming shared QA resources you’ll be able to tell your project more about why a delay is necessary. If you don’t have Plutora you end up having to give projects a story about why they can’t proceed. Instead of doing that, why not provide them with data? They can then use this data to communicate with management. Without Plutora you’ll just end up getting blamed for constant schedule slippage.

Best Practice: Ask for More Resources When Necessary

If your organization is making a frequent habit of test environment conflict you should be asking for more resources. If you need more hardware or a larger quota on a public cloud, Plutora can supply you with the raw data you need to justify these asks. If you need more people to support release engineering and testing environment setup and teardown then Plutora is the tool that can supply this data.

Don’t just accept test environment conflict as something that has to happen. Strive to eradicate it from your department and use the metrics from Plutora to motivate management to give you the resources you need to succeed. In an ideal situation, a business understands that it can’t expect to both accelerate development schedules and force teams to share scarce testing resources. Using Plutora you can move your organization closer to the ideal of having a dedicated test environment for each of your important projects.

Best Practice: Make Test Environment Conflict Everyone’s Problem

Test environment conflict is avoidable, and it is your job to help educate everyone to why it happens. In most organizations test environment conflict is the test environment manager’s problem, and most people just assume that environment managers aren’t planning ahead well enough to avoid it.

As a test environment manager you understand the several competing factors that force you into unwinnable scenarios. You can either choose to allocate resources to one project or the other, and you are no stranger to being the brunt of blame when projects can’t meet timelines. Don’t just continue to operate in this mode, ask your internal customers to use Plutora and demand that they participate in these decisions as equals. If a project misses a deadline and forces you to change a release schedule use the tool to make it clear to your department that test environments are a shared responsibility.