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.
For a long time, I’ve been wanting to write a series of posts about those little activities that are a critical part of Agile and Lean, but somehow seem to slip by the wayside even on the most competent teams. This series is entitled “I’d Rather Be Coding,” and recognizes that the team is trying to do their best but sometimes needs a reminder about what is important.
Developers really hate writing things that aren't code. They have good reasons for this distaste, however.
If it's not code, it can't be run through a compiler to make sure it makes sense.
If it's not code, it doesn't get executed, so it may never be used to accomplish anything.
If it's not code, it can't have tests against it, so there's no way to prove that it is truthful and correct.*
Agile even de-emphasized documentation in the Manifesto:
On Monday, February 18, Asynchrony held our company meeting. As well as being our first company meeting in the new office, we were able for the first time to bring in guest speakers. We chose two great voices in the Agile world, James Shore and Arlo Belshee, to help remind us of Agile values and to inspire us to keep striving for technical excellence.
James and Arlo started off the day with "Bloody Stupid Johnson Teaches Agile," a farcical send-up on how Agile is tried and fails when the commitment isn't there to really change the culture. We were reminded about all of the roles that can pop up as an organization tries to be Agile, from the consultant who promises the world, the Agile religious zealot who only knows how to tell people when they aren't Agile, and the "certification trainer" who offers something really enticing and easy, but without much real benefit.
After Bob Elfanbaum and the sales team openly presented our financials and sales pipeline to all employees (as has been our custom since starting the company), Arlo and James spoke on "Virtuoso Technique," the value of reaching a level of skill in your craft that lets you do the right things without even thinking about it, so you can concentrate on the problem at hand. Quality is a constant conversation at Asynchrony, and an area we never feel we have totally mastered, so it was a good reminder on how practice is required to really make these skills second nature.
At this point, the group split into two, as James and Arlo had a session to dig deeper into the Virtuoso Technique concepts by guiding developers through refactoring in their own project code bases. Our own Stephanie Greytak and Jason Tice led another group in a presentation called "Everyday Agile Values," where values inherent in Agile ideals were illustrated through exercises and games.
After lunch, Asynchrony had a time of employee recognition, where those who were new to the company were asked to stand one at a time (35 since last October, so this took a while!) so that other Asynchronites could put names with faces. We also renewed our tradition of giving out company-logoed jackets to those who had been with the company for five years (temporarily on hiatus as we got jackets with our new logo), and bobble heads for those who have been around for ten, a duplicate of which will be displayed in the case in our lobby.
This was also the time that Bob Elfanbaum, our general manager, introduced the Asynchrony Culture Committee concept. As our company grows and the management team gets more and more occupied with everyday operations, it's important to us to hold on to the culture that makes people want to work at our company and that allows us to do amazing things for our customers. This grass roots team will help keep us on track by advising changes and roles in the company to help us continue to promote an open, accepting environment of empowerment, creativity, achievement, and learning.
Arlo also gave a short but inspirational talk on how brain chemistry affects the learning process. It was useful for even our most experienced developers to understand the chemical reactions that allow us to learn, and how we need practice to retain what we learn.
After a lively "Agile Caucus," where James and Arlo represented the various goals we fight for on our software projects, we broke into teams and played an Agile project simulation that helped emphasize how the engineering and planning disciplines of Agile can help make teams successful in their development goals.
We concluded with an Open Spaces discussion where employees were encouraged to propose topics that they were passionate about discussing concerning Agile and life in Asynchrony. I saw talks on developing leadership, various development practices, and how culture should really be retained to be successful (should it be leadership doing it, or the employees?).
Asynchrony for so many years has worked not because of what management does but what our employees do to make us great. This company meeting was an effort to show support for our employees and inspire them to continue to emphasize discipline and quality, and to come up with the new ideas that will keep us successful. We hope hearing Arlo and James helped to solidify the reasons we do what we do the way we do it, and that many of our employees had the chance to talk to them and each other to take a little something away they can use in the future. We sent out a survey about the meeting and will be reviewing the feedback to see how we can do something even better next time.
Thanks to Matt Sebek for the great photos!
I've been thinking about having a company game night for quite a while, and I decided to just jump out there, even at the risk of looking silly. I sent a message out to the company with what I was thinking, with the caveat that if we got at least ten people interested we'd go ahead and have it.
The response was fantastic. People stopped me in the hall and on the way into work, or dropped by my office to say that they were in. I set a date, had my talented brother put together a great-looking sign that I posted around the office, and waited for the day to come.
My hope was that there were people in the office who love playing board games, but can't find a big enough crowd of people to play with them, and so would be willing to come in. My inspiration was the first JoCo Cruise Crazy in 2010, where a room was set aside for nearly round-the-clock board game activities. I thought this would be a great way for people in the office to get their "game fix" and spend time with each other outside of work.
Last Friday night, we had our first Asynchrony Game Night. There was a great crowd there; employees brought their families and friends along and got the gaming started right away.
I saw Carcassonne (and got to play for the first time), lots of Ticket to Ride, Settlers of Catan, Clue, Set, The Logo Game, Smash Up, Forbidden Island, Zombie Dice, some game about beans that Amos was really excited about, and others.
Then there was the raucous group that went into the Adult section (our Zanzibar conference room) and played Cards Against Humanity. Yes, we have all of your names, and some pretty incriminating hidden camera footage.
I didn't get an exact count, but we consumed 17 pizzas (ordered using a new group pizza ordering algorithm that I thought of that worked pretty darn well, I must say), so I'm guessing we had at least 30-40 people there. Most of the crowd had cleared out between 9 and 10, but there were a hardy few of us who closed out the night playing Rock Band on the big screen in Downtown North (I got my "Love Shack" fix in, so I'm happy).
Thanks to everyone who came! I had several people stop by to tell me what a great time they had. We will definitely do this again!