Last week we dove into how DL organizes agile teams to fully utilize QA. Now let’s focus on tackling QA integration from a team and company philosophy perspective.
Team Philosophy
It takes a village to build a quality app
Everyone who interacts with the app should be able to file a bug report including developers, designers, delivery leads, the business client, and, of course, QA. If a non-QA person finds a bug, it doesn’t necessarily mean the QA isn’t doing a good job. Every app will have bugs. It’s the nature of development. Every piece of software that’s released to the world has bugs. But, with a village mindset we can find more of them.
Bugs aren’t always a lower priority than story cards
It’s easy to focus primarily on creating new features while deferring bug fixes to a later time. This can be a fine strategy for minor bugs, but normal to critical bugs should be prioritized along with new features. It can be demoralizing to put a lot of work into finding a bug only to have it backlogged and never see the light of day. Plus, it’s faster for the developer to fix the bug right away while the code is still fresh in their mind. Think of it this way: would you rather have a fully completed app that’s full of bugs, or a half-completed app that’s amazing? A complete app with tons of bugs can be useless. A half-done app with very few bugs can still be useful for half of its features.
QA’s schedule is held to the same expectations as other teammates’
Working late and on weekends should be avoided unless you’re approaching a hot and sweaty deadline. I’ve heard horror stories where developers would send the new features to QA at the sprint deadline of 5 p.m. on Friday. Then the QA team would work all weekend to test the code to have the bugs reports ready by Monday morning! Even beyond working hours, QA should have the same freedom to take hack time to develop their skills and learn new things.
Company Philosophy
Changing your team’s organization and philosophy is relatively straightforward. But changing the company culture toward respect and genuinely liking one another is far tougher. How do you get your team to like and respect each other? Now that’s a helluva question. If this were a game show all the lights and buzzers would be going off. This is the closest thing DL has to a special sauce. Here’s what I think the recipe is.
Constant experimentation
Everyone should be involved in finding better ways to report bugs, communicate, and build quality software. That may include building specialized tools to distribute builds more effectively or changing the testing process to make it easier on developers and testers. As an example, developers at Detroit Labs built a Jenkins plugin to more easily distribute builds to QA. Likewise, QAs have experimented with posting bug comments within GitHub pull request notes, where developers are used to seeing code reviews to make it easier on them. Every team should work together to find better ways to build quality apps.
Working on relationships
We dedicate a lot of effort to working on our interpersonal relationships by having weekly team retros, biweekly all-company retros, team-building events, and monthly all-company social events. It’s easy to genuinely like your coworkers when you spend social time together inside and outside of work.
Continually improving communication
We spend a lot of time working to communicate better. We address how we talk to each other at almost every all-company retro, hold lunch and learns about how to give and receive feedback, and explore new tools for communicating more effectively. We don’t have all the answers, but one of the best things we do is continually work on our communication.
Very careful hiring process
Every company takes hiring very seriously, but Detroit Labs has a unique approach. We eschew resumes in favor of what we call a “Get to Know You” (GTKY). This is a series of essay response questions to get to know who you really are, beyond resume-speak. We’re trying to have a meaningful interaction from the very onset to see if you’re a good fit. The next steps in the hiring process are more standard in-person interviews to learn about the candidate’s personality and skills. However, when you submit a GTKY to Detroit Labs, everyone in the company has the ability to read it, giving a voice to all employees to make sure anyone we interview further seems like a good fit.
Maintaining a deeply held belief that all aspects of development are equal
At the core of Detroit Labs’ company philosophy is the belief that every member of our team is equal. No role is more important than another. This included developers, designers, delivery leads, business developers, company founders, and QA. Our flat hierarchy and no-titles policy is a big part of this mindset. To value everyone equally, it’s important to think about all the considerations that your organization gives to each role. Are you respecting all teams — or team members — the same way? Employee burnout is a common concern, but how often do you consider QA or designer burnout? Do your delivery leads and business developers have the freedom to use hack time to grow their skills? When a QA gives input on app design or user interface, do you listen as closely as when the same ideas are offered by a developer or designer? This is the toughest change to implement in an organization because it requires a true openness that can be uncomfortable and disruptive to the established structure. However, hopefully the points listed throughout this blog series are a good starting point.
Did I miss anything? Does your company have a unique or inspired way of integrating QA? I’d love to hear about it!
