I was recently having a conversation with one of the QA's at Asynchrony about their role and treatment on their team. (A side note: in most places, QA stands for "Quality Assurance," but because we think the whole team is responsible for assuring quality and not just those in one role, we have decided that QA stands for "Quality Advocate" at Asynchrony.) He was a bit dismayed at the way QA's are treated on some of our teams: their opinions aren't as valued, the teams (including customers) sometimes discount what they ask for to get their job done, and they generally can feel like second-class citizens.
We talked for a bit about why that was, and how it's natural for developers in particular to feel that they are the most important members of the team and that everyone else is optional. After all, they write the software that is the point of the project; a QA or a designer can't create software without them, right? This can lead to a general perception that the people in those roles don't need to be regarded as highly, and their opinions and requests are given less weight. However, this way of thinking creates resentment and generally fosters an unhealthy team environment, so it got me to thinking about a similar "team" structure that doesn't seem to have these issues, and how we could learn something from it that could possibly help change these attitudes.
It Takes Four to Sing in a Quartet
You'll probably think it strange that the "team" I was reminded of was a barbershop quartet, but bear with me. I sing in a barbershop harmony chorus, and I am also regularly practicing with a quartet (we're not ready to sing in public yet). Barbershop singing is a great hobby and is very fulfilling in many ways, and although there are four parts that make up the quartet (tenor, lead, baritone, and bass), the opinions and contributions of one part are never seen as more significant than the others. However, just like in an Agile team, there is one part that is more "important" than the others.
The science of sound teaches us that two notes create harmony when they are played or sung at the same time, because the sound waves are complementary to each other. What's really fascinating is that the byproduct of this occurrence are "overtones," which are tone "echoes" of the notes at higher pitch (there are also "undertones" at lower pitch, but those are much harder for humans to hear). This means that multiple people singing together can actually create more notes than the number of singers. This has been known for hundreds of years, but in the 1800's in the USA men discovered that if four of them sang a particular chord arrangement (with a root, third, fifth, and seventh), that they could create some really loud overtones. This is incredibly fun to do, so they started singing entire songs with these chord structures and barbershop harmony was born. This chord (a major seventh chord) is so prevalent in barbershop singing that it is now known as a "barbershop seventh" chord.
Although these overtones can be created by instruments as opposed to voices, it's much harder to do, because to get the maximum volume and number of overtones requires a very exact tuning that involves singing some of the notes in the chord a bit higher or lower than their "true" tuning value. The members of the quartet have to be aware of what the others are singing and adjust accordingly in order to get the best sound.
Which Role Is More Important?
So, who is the most important member of the quartet? The "lead" part almost always sings the melody line of the song, and since you can't really appreciate a song that doesn't have a melody, it's probably true that the lead is the most important. In fact, the lead could sing their part all by themselves and be quite entertaining in their own right. What they can't do, at least to the same level, is create the overtones that barbershoppers love so much. This is why, although it's a critical part, there's not really a hierarchy in barbershop singing -- in fact, singing the harmony part can be a lot of fun and more challenging, and so many great singers would rather not sing lead.
So, how does this relate to an Agile team? What occurred to me is that the developers on a team are like the lead part in a barbershop quartet. The quartet can't really create their product without their lead, just as software needs developers, but the developer is completely capable of building software all by themselves, just as a lead could sing a beautiful solo. So why don't we staff teams with just developers?
When a software application gets above a particular level of complexity, and/or when there is a desire to get things done more quickly, other types of roles are brought in to help: QA, user experience specialists, DevOps, product owners, and coaches. All these roles have their part to play, even if they are not the ones writing the software. So are they all second-class participants? No, because what the team has in front of it to accomplish could not meet the requirements with only developers. Furthermore, just like a quartet can generate more notes and harmonies than the number of singers, an Agile team can generate a better software product than any of its members could working individually, because of the way ideas and accountability work when people cooperate together. It's also true that sometimes the non-developer roles can be more interesting and challenging than the development work, which is why people will choose those roles as a career.
Treat Your Team Like a Quartet
There's no good reason for team members in one role to devalue the members in another role. Although each person may not have the context or background to have the best solution to every problem, it's important to respect the skill sets and capabilities of everyone on the team. Developers need to appreciate the fact that having these other team members gives them many benefits: it takes them away from having to do non-development work, it brings different perspectives and backgrounds into team decisions, and it can make up for their shortcomings with skills sets they don't possess. These roles should be respected and time taken to make sure they are able to be as successful as possible; this will not only make them happier, it will increase the "overtones" that the team can generate.read more
In April of 2014, I was one of two Quality Advocates in Asynchrony writing automated tests. I'd worked with my team lead to create a process where I wrote automated regression tests in C# before they started a feature, and that body of tests would run with every code check-in, in addition to their unit tests. The effort paid off with a solid product where only 5% of our stories were bugs, and there were almost zero support requests once it was deployed at the client site. I wanted to replicate that success on other teams so I asked for an apprentice. My father had been apprenticed to a carpenter when he was just out of school, and he always spoke well of the experience. There's no college degree in software QA, and everyone I know learned some testing folklore from a QA veteran.
Finding the right apprentice required tweaking our normal interview process, because we were looking for how someone would think. They needed to be fearless and willing to try anything. We do a brainstorming exercise in interviews, and the best candidates would be on their feet and drawing on the white-board with us. Creativity and curiosity are part of our daily process, starting with the question "What would happen if I did this?" The desire to learn is essential for a quality advocate. People with an eye for detail and troubleshooting skills make good apprentices. It takes courage to come in and be the new person in a new field, doing things they've never done before, and a willingness to be taught and corrected.
My apprentice and I spent three months working side by side. Whatever I did, he observed, asking questions, and taking notes. On his first day, I walked him through altering a UAT and committing it into the source code repository, I was delighted when he came back the next day ready for more. He worked through a manual I'd written for new quality engineers, took some Code School classes, and coded exercises from a C# book. I spent most of the first month answering questions and walking him through the basics of object oriented programming, HTML, CSS, SQL, and how to use Firebug and JMeter. He learned why 10th October 1582 was a useful date to use in testing, how a web application responds when you hit it with 3000 simultaneous web requests, and why you should never use Comic Sans in a professional context. I got into the habit of asking questions to which I knew the answer, to help him work through to that same answer on his own.
It was a learning process for both of us. He found three UI bugs I'd missed because of over-familiarity with the application. Breaking down what I knew into bite-sized pieces helped me get straight what my own process was, and highlighted some deficiencies. I learned to let him do things I could do faster and better, and to wait for the right time to ask "Can you tell me why you did that?" or "What about this other thing?" or "What else should we test for here?" My apprentice's job was to listen and ask questions, even if they seemed stupid, because I believe the right dumb question is invaluable to the team in putting together a product that works well. You never know which dumb question is the right one until you ask it.
Where before there were only two teams with a quality advocate writing automated tests, we now have four, using three different languages and a variety of tools and technologies, and more teams interested in starting. We currently have two apprentices paired with senior QA staff. I have a weekly check-in with the apprentices and their mentors, and two months in, things are going well. I believe that part of the responsibility of being a senior is training juniors, whether that be quality engineers, programmers, or carpenters. Learning one-on-one from a senior in the field gives the apprentice hands-on experience in a safe environment, and gives the senior the chance to see their processes through new eyes. We're giving the apprentices the chance to try a new career, to learn from an expert, and to be involved in the whole life-cycle of software development, from design and UX through security testing and load testing, to final polish and delivery.read more