More and more companies are turning to Agile to improve their project success rates and scrum is the most popular methodology. 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, a lot of the resources are not actually qualified to work within a scrum team, especially in transitioning environments.
That may sound a bit negative, but I’ve seen a lot of scrum team candidates in my time. After interviewing a scrum business analyst candidate claiming five years of experience 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?
1. 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 time-boxed development a sprint or an iteration, but both show knowledge.
Here are some other sample questions that should work for any team member you need:
- 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 resume come across my desk that said the scrum master candidate managed the “burnout chart”. The correct term is burndown chart. Although I have been on teams where burnout was an issue and a chart mapping it may have been a useful tool, the scrum prescribed burndown 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.
2. Ask about how their team works
If your candidate has passed the first step, it’s time to drill in a bit deeper. The next step is to determine if your candidate really knows how to work in a scrum environment. The tricky thing here is 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 environment, but many times these adaptations have nothing to do with scrum. Sometimes they are more of a waterfall adaption than a scrum adaptation.
To determine if 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, 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 that 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 type of resources, 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 this resource will need some adaptation time. When transitioning your environment to agile, stay away from these type of resources. You’ll want new hires to bring in strong scrum knowledge and these resources really won’t have it.
Another clarification would be to ask the candidate about their team make-up. Are they used to working with embedded business analysts? Are they working with a product owner participating in their team meetings? How are the stories defined? Do they work with UX resources? I’ve interviewed business analysts that 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 in 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 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.
3. Ask about how they work in 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 in their team?
A scrum master 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,” warning: you have a traditional waterfall candidate on your hands. Agile teams are supposed to be self-managed with scrum masters acting as servant leaders, not task checkers. PMs that 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 potentially shippable product, working with the business analyst and product owner to understand stories, self-organizing team, 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 where they could disappear for months on end to develop what they understood the feature to be.
Although not necessarily always a factor, you can also listen for words like “I” vs. “my team.” People who have worked on scrum teams for a while will adapt the “team” phrasing because individual efforts become team efforts. Of course it is an interview and the resource is trying to inform you on 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 the resource 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 re-training 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 scrum master in my scenario above had no more interviews because I knew she had no idea how to be a good scrum master.
4. What are their scrum observations?
Your candidate has done well up to this point and if you were hiring for a general scrum resource, 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, scrum master or product owner. How do you make sure 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 their 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. You’ll know when you hear these answers 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 resources transition from company to company. Hopefully these steps provide you with a framework to assist in your search.
AIM Consulting’s expertise in application development and product and project management covers the entire software lifecycle, from architecture to optimizing processes that ensure high quality outcomes with the most efficient delivery. To learn how we would deliver agile solutions to your organization, tell us about your challenge.