Have you ever wondered what it would be like to have a full-time QA person on your agile team? If so, you've probably immediately wondered what that person would do on the first day of the sprint.
I like to fight for as many QA resources as I can get, so this has become a frequent topic of conversation around the Three Five Two Gainesville office. But last week I was at a technology meetup, and someone asked me, "How can you have a full-time QA person as part of your scrum team? What do they do in the first part of the sprint?"
Clearly, I'm not the only one asking how development teams can make sure their QA resources are used to maximum potential.
It is a really good question, and I asked my Scrum trainer, Tom Mellor, how to keep the QA members of my team busy on the first day of the sprint. He looked at me with a blank stare. You know the one: mouth slightly agape that comes with the unsaid, "Son, are you stupid or just plain dumb?"
I choose to believe it wasn't the dumbest question he's ever heard, but after he composed himself he responded with another simple question.
"How can it be the first day of a sprint and one of your team members is already out of work?"
Any rational person, such as myself, would respond, "In the first 10 seconds of any sprint, there's no way that any stories have already been completed and gone to QA, so the QA person wouldn't be out of work, but he or she also wouldn't have received any work yet either." Right? Seemed pretty logical to me.
Not how QA starts each sprint.
That's totally valid, but it is missing an enormous point. We're talking about Scrum! We are fortunate to have the Scrum guide to help us navigate these questions, and it's something that we all review on a regular basis. [Editor's note: No, we don't. You nerd.] But just in case you've been a little distracted lately, let's take a look together. These excerpts are direct copy/paste out of the Scrum guide. I'm not making this up.
Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule. - The Scrum Guide
Just for simplicity's sake, I'll enumerate all of the allowed titles for team members here: 1. Developer
Notice how exhaustive the list is? Was QA on it? So why do you have a designated QA person in the first place? Everyone is a developer, and they contribute to the development of the project. Simple.
Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule. - The Scrum Guide
If the first point wasn't obvious enough, this explicitly states that there are no sub teams "like testing"... which means QA. But what if your QA team is a highly-trained bug-finding force. Too bad, "no exceptions" (see what I did there?).
Now that we are all on the same page, you're probably thinking, "That's not realistic," or "We can't do that in my organization." I'm here to tell you that you both can and should, and later I'll give you some practical advice to make it happen. But first, another word from the Scrum Guide...
Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole. - The Scrum Guide
Your team probably consists of people who specialize in making pretty things and others who can write awesome queries. I'll refer to them as "experts." All of the members in your team are an expert at something, but that doesn't mean it's the only thing they can do. Your artist might never write a complex join statement and your DBA may never design a button, but there is always a way to pitch in on any story. Always. Even if it's just sitting side by side to talk through the problem (pair programming anyone?). They might even learn some new valuable skills.
We talked last week about developers growing their QA skills, so why can't the reverse apply to your QA analyst? There are no special passes here. You probably have a QA expert in your organization, but if a lot of stories need QA, everyone else on the team pitches in, right? Well, they should! Not just the QA experts; every member of the team is responsible for every story at every step towards completion. Even the QA step (Oh, yes I did).
The goal is to drive everything to Done. A person may be 10x slower, but if they have free time, they need to add their 10% effectiveness and improve their skills. "That's not my job" doesn't exist in a Scrum team.
Practical Application
This is fine in theory, but how can you really implement this? Even with politics and egos out of the mix, the solution isn't always obvious. So here are my tips to help your QA expert deliver value from the first minute of the sprint:
- Have stories to create automated tests & load tests. They are important; train your PO and get it in the backlog.
- Make sure all stories are really small. My team typically has stories ready for QA on the same day as sprint planning.
- If a large story takes an entire sprint to complete, how on earth will that get QA'd and fixed before closeout? It won't, and it needs to pass QA to be shown at closeout. So break it up. And then break it up some more.
- Encourage your QA person to learn new skills to help move stories to QA. Options include:
- Learn to program
- Do some design work
- Perform some user tests
- Server setup and management
- Give shoulder rubs
Scrum teams seem to be really great at making everyone on the team an equal... as long as we don't talk about QA. They either have a "QA Person" or, even worse, they are in a completely separate QA department. Since your definition of Done should include passing QA (please say it does) and you shouldn't be showing anything at your closeout without QA, it's reasonable to say that if you have a separate QA team, you're just doing it all wrong.
But in terms of QA, remember that you don't have a QA person any longer. You have a person who specialized in QA but has numerous other talents to pitch in on day 1. My QA expert can write HTML, is learning javascript, and can hit a mean tennis serve. Tell me what yours can do in the comments below.
