More and more companies are turning to Agile to improve their project success rates, and Scrum is the most popular method. The problem is that as you transition your company to a Scrum environment, it is a challenge to find candidates with a legitimate Scrum background. Due to the flexibility of Scrum and the eagerness of many to obtain Scrum experience, many people are not actually qualified to work within a Scrum team, especially in transitioning environments.
That might sound a bit negative, but I've seen a lot of Scrum team candidates in my time. After interviewing a Scrum business analyst candidate who claimed five years of experience yet who couldn't tell me what a "story" was, I've become skeptical. So how do you find the right people who are going to move your company forward?
Test the terminology
The easiest and most basic way to determine how much experience a candidate has is to have them feed you some of the terminologies. I spent a good 15 minutes with the aforementioned business analyst asking her, in multiple ways, "How are business requirements captured in a Scrum environment?" Ask questions that force the candidate to give you the terminology. They may give you different answers, like calling the timeboxed development a sprint or an iteration, but both show knowledge.
Here are some other sample questions that should work for any team member:
- What are some of the artifacts in the Scrum process? (Answer: sprint backlog, product backlog)
- How is team progress measured? (Answer: velocity)
- How are increments of work sized? (Answer: story points or T-shirt sizing)
If they're using the terminology, make sure they're using it correctly. I once had a résumé come across my desk that said the ScrumMaster candidate managed the "burnout chart." (The correct term is burn-down chart
.) Although I have been on teams where burnout was an issue and a chart mapping it might have been a useful tool, the Scrum-prescribed burn-down chart is more effective.
A candidate with experience should have no problem with this test. If they do, they haven't worked in Scrum. You really don't need any more evidence before moving on to the next candidate.
Ask about how their team works
If your candidate has passed the first step, it's time to drill down a bit deeper. The next step is to determine whether your candidate really knows how to work in a Scrum environment. The tricky thing here is that many times the candidate doesn't realize they haven't
worked in a real Scrum environment.
With so many companies wanting to say they're Agile, you'll find there are many different flavors of Scrum being used today. It's good that companies and teams are able to adapt the Scrum process to their environments, but many times these adaptations have nothing to do with Scrum. Sometimes they are more of a Waterfall adaptation than a Scrum adaptation.
To determine whether the candidate is right for your company, you'll want to understand how the candidate's current environment works. Many companies say they're doing Agile, but they're really just doing some kind of iterative development. As a development team, they're soft-planning a time increment with no product owner, no artifacts, and no demos. All the team has done is added a time increment to their delivery without any of the other processes.
For companies looking for development resources, this is a real caution. Hiring a developer for a Scrum team who has been working in a Scrum environment that is less strict is almost the same as hiring someone with no experience. When Scrum processes are placed on these types of employees, they'll have to adjust to the transparency and reporting that will be required. If all other factors are positive, you'll need to be aware that such a person will need some adaptation time. When transitioning your environment to Agile, stay away from these types. You'll want new hires to bring in strong Scrum knowledge, and these really won't have it.
Another clarification would be to ask the candidate about his or her team makeup. Are they used to working with embedded business analysts? Are they working with a product owner who participates in their team meetings? How are the stories defined? Do they work with user experience (UX) teams? I've interviewed business analysts who have no idea how to work within a Scrum team, and developers who couldn't tell you who their product owner was. This question actually helps you on two levels. You'll understand if they have worked on a legitimate Scrum team and also to what extent. Not all companies have been able to incorporate their UX and business analyst resources. This question will let you know their experience with that.
This category is not as easy to use to eliminate a candidate, but you need to know where you'll need to supply more support. If there's too much extra time required, maybe another candidate would be more suitable.
Ask about how they work on their team
Your candidate has flown through the first two filters, but there's still one more hurdle for Scrum resources: How do they work on their team?
A ScrumMaster candidate should say something like, "I work with the product owner to develop a plan and remove roadblocks." If they say, "I make sure all tasks are completed," here's a warning: You have a traditional Waterfall candidate on your hands. Agile teams are supposed to be self-managed, with ScrumMasters acting as servant leaders, not task checkers. Product managers who can't step away from managing all the details and pull back to removing roadblocks don't translate well into Scrum.
When interviewing developer candidates, they should talk about things like a potentially shippable product, working with the business analyst and the product owner to understand stories, self-organizing teams, relative sizing, etc. Developers who don't mention the way the team works and how the product is delivered differently could also potentially be coming from more traditional project environments in which they could disappear for months to develop what they understood the feature to be.
Although not necessarily always a factor, you can also listen for such words as I
versus my team
. People who have worked on Scrum teams for a while will adopt the "team" phrasing because individual efforts become team efforts. Of course it is an interview, and the resource is trying to inform you of their skills, but if they're also using "my team" to describe their contribution, you'll know they're on a team that was unified, which might make them a good candidate.
Determining the nuances of the candidate's background can be difficult, but each filter will help you determine more about how well he or she will succeed. Come up with questions to assist you in understanding how the candidate will fit in your environment. If you find candidates lacking in this category, you're going to spend time retraining them in how to work within a Scrum team. They've potentially been trained incorrectly, or they are just not a good fit for Scrum. The ScrumMaster in my scenario above had no more interviews, because I knew she had no idea how to be a good ScrumMaster.
What are their Scrum observations?
Your candidate has done well up to this point, and if you were hiring for a general Scrum employee, you'd already be working on the offer; however, for this role, you need a bit more. You are looking for a resource to take a leadership role in the team. This may be a development lead, ScrumMaster, or product owner. How do you make sure that they have "that something more" that can bring a lot of value to the team? Ask them about their Scrum observations. This is a chance for the candidate to really show his or her experience and commitment to Scrum.
Here's where you'll hear things like:
- "Scrum enables my team to plan better by . . . "
- "To help us manage scope within iterations, we . . . "
- "Our product owner is not engaged with our team, and that causes . . . "
I really enjoy the responses to these questions. I get to hear how the different disciplines see things from their perspectives. When you hear these answers, you'll know how strong a leader your candidate would make.
Finding the right candidate is never easy, but Scrum requirements put a unique spin on what is needed. The flexibility that companies appreciate also creates challenges, as these employees transition from company to company. I hope these steps will provide you with a framework to assist in your search.