How to Build More Effective Relationships with Your Developers

Whether you are struggling with a recent blame-filled, post-mortem or in the middle of a sprint riddled with conflict, we all know the human stressor costs that come with poorly aligned communication across software quality teams. Furthermore, in a recent study, researchers attributed poor communication to costing U.S. businesses a $1.2 trillion annual loss or nearly $12,506 per employee every year.

How do agile delivery leaders and testers effectively build more effective relationships with their software development teams, while improving communication, output, and software quality? In our latest Agile TD Zone conversation, Lisa Crispin, Co-founder of the Agile Testing Fellowship, and Larissa Rosochansky, Senior IT Executive & Quality Leader, shared concrete strategies and solutions for helping software testers work to a whole team approach to quality.

Read on to learn how to unlearn testing strategies that haven’t served you, leadership strategies for helping your dev teams rethink their approach to quality, and how to become the QA darling of your organization. You can also enjoy a recording of the event here.


How to unlearn strategies that haven’t served you (and your teams)

“You must unlearn what you have learned.” - Yoda 

Whether you are a seasoned testing expert or just starting your software quality career, we know that testers working in less agile or less modern environments may have been trained to not do any testing on something unless the coding is done. Testing twice can be seen as a waste of time resources, and furthermore, as Lisa notes, the mindshift between bug prevention over bug detection can be taxing, and also make it challenging for them to influence the efficiency benefits of testing earlier and more often with their software development teams.

Unlearning the traditional testing silo approach can also be daunting for more seasoned testers, notes Larissa, who have long heard the tale of never looking into code. Quality practitioners must first focus on building more healthy relationships with their development teams by looking inward. While online memes can sell software testing consultant clicks on social media, participating in a QA vs Dev approach is not only hindering your team communication, but software quality too. Changing mindsets with your developers actually starts with you.

Software quality practitioners need to get involved earlier in user stories to avoid conflict down the feature development road. “Hey, when you are about to check in your changes for that user story, would you mind spending a few minutes walking me through what you did and how it works now?” These types of simple and direct lines in a “show me” approach, sometimes called desk checking, notes Lisa, is an important communication tool for building positive collaboration earlier in the testing process.

Your team value cannot be determined just by the number of test scripts you write or the number of bugs found as a QA, but in the whole team value of the features that you have delivered to your customers.


How to help developers create a test-first team approach 

As quality professionals, asking effective probing questions can help get your developers to share areas of their code with you that they may feel less confident in. It’s especially easy to fall into a test fast, early, and often approach when joining a new team, but how are you building a foundation of trust that can only be built over time.

“I find it helpful to ask them to show me parts of the code that might have more risk,” notes Lisa, “and then [use] this to where we should focus more testing.” In addition, Larissa notes that testers must begin to get into the practice of asking what parts of the code you think are the most challenging to test and what areas may require additional testing, code review or attention from QA leaders. We must start with asking about the assumptions that developers made when creating their code, and then start the investigative process for better quality assistance.

Now maybe you are still experiencing pushback from your developers and need to go back to your influence framework toolkit. Larissa shares that dev box testing, where a QA validates, tests and verifies a feature in the scope on the developer’s machine, can be a simple and effective way of better partnering with your devs, as well as continually closing the gaps of miscommunication. If there appears to be a consistent error, ask gently probing questions to gauge if the issue happens frequently and then leverage as a way to encourage more testing earlier in the next feature development cycle. However, you cannot move forward with your testing earlier interventions as a software tester if you do not have buy-in from your senior leaders and/or those that have influence on the team. 
 

How to rethink cross-functional agile strategies in an evolving DevOps-first culture

We say agile, but 20 years after the original agile manifesto was published, many cross-functional teams are still caught in the usual waterfall-era game. Furthermore, agile principles can often be misconstrued as a negative by professionals in the software development industry. Shifting left only is not a viable option for teams producing high quality software, and we must have engaging testing activities throughout the infinite software development life cycle. 

Having partnered with and coaching global clients for decades, Lisa shares that recently she has seen much more success when teams encourage a whole team transformation to a DevOps culture. This transformation requires getting operations specialists such as SREs and platform engineers to collaborate with delivery teams, while helping everyone see the value of doing smaller, more frequent deployments to production. And to do that, claims Lisa, “we need things like a strong suite of automated unit-level regression tests and at other levels as well.”

This does not mean abandoning agile principles, but recontextualizing their application in modern DevOps cultures, and as Larissa shares that this means more frequent and earlier feedback. “I remind my teams that “a defect found in production costs 140 times more than one found in the requirements phase (if we are talking waterfall). Agile means earlier feedback, which means less cost, and when considering leveraging SREs”, Larissa notes that software testers must consider a production readiness review, where your developers, testers, and tech leaders meet with SRE teams to, “define error budget and actions that should be performed that could decrease the error, and therefore grant the team to deploy whenever instead of those dreadful late deploys.”

Furthermore, when working to align your software testing KPIs to your software development teams, before designing experiments, start by asking your developers what quality means to them and what’s the largest obstacle getting in the way of their delivery? While DORA metrics can be a good way to measure developer output and productivity, one can also leverage some of these measurements to the production of quality. 

A low deployment frequency could indicate that testing or code review processes are failing to discover broken builds early enough or simply slowing down the code release process. Or perhaps your teams decided not to deploy frequently due to the origin of business. For example when considering mobile, what updates need to be downloaded - your team can measure CR appointments or broken builds. When reviewing lead time for changes measurements for your quality practices, evaluate if the testing process is causing bottlenecks in the CI/CD process and how you are monitoring automation rework. 

For change failure rate, consider measuring through a lens of traceability or amount of existing coverage, and while mean time to recovery is hard to contextualize in a DORA metrics context, Larissa notes that teams can still have a robust rollback process in place. Testing teams can conceptualize this metric in time down site down affects customer experience, and could mean that testing teams are not adequately testing the continuous integration, delivery, and deployment process.

When working to build more effective relationships with your developers, we must start by unlearning strategies that have not served our teams, as well as re-framing applied agile principles in a modern DevOps culture. We encourage our readers to listen to the entire recording for additional tips on interpersonal relationships, insights from community guests, and more.

💡 If you want to join me and these incredible speakers at Agile Testing Days USA this year, make sure to use my 20% discount code Tristan_20, to be added at the last step of your registration.