One of my colleagues recently asked me how I interview people who have agile experience listed on their resume. I gave him some pointers, and it got me started thinking, “How do I interview for Agile experience?”. So building on the thoughts I gave him here is what I do.
I start by looking at the position I want to fill. Different positions require different levels of agile experience, so it is essential to understand what level of experience is needed. This helps me get ready to talk to the candidate. During my discussion with a candidate, I try to get an idea of their experience and how the teams they have worked on implemented agile. If they have a good deal of experience, I drill down into that experience. I also look for people that put agile on their resume but have no idea what that means. It is also common for people to have worked on “Agile Teams” where no agile practices incorporated into the project, so I tend to ask about what specific agile practices they have experience with.
I expect beginners to be able to explain their process from the point of view of their role. Many have only done a daily standup and think that is Agile or Scrum. If they stumble over most of the basic developer and Scrum practices, then I would say they don’t have a lot of Agile experience. If I ask them simple, agile process questions and they look at me like they don’t know what I am talking about, I see that as a sign that they don’t have a lot or any agile experience.
If people are going to be team members on an agile team, I usually view agile experience as a plus. If the interviewee is going to fill an agile named role on the team, like a Scrum Master, Product Owner, or Coach I look more deeply at their agile experience and will take time to really drill down into their experience and how they have filled their role in the past. Since these roles are key to the day to day operation of an agile team, it is important to understand how they will approach problems and solve them in a project context.
When I start talking to the interviewee, I start with general leading questions and see where those go. The leading questions leave a lot of room for the interviewee to take the conversation in different directions. I find that people with a lot of experience can talk about these topics quite a bit. I like to see if the interviewee talks about their experience with enthusiasm and interest. Do they talk about the things they learned? How did they deal with problems? There is a huge difference between people that are invested in the work they have done and people that are just going through the motions. Some interviewees I have spoken to have been as enthusiastic about their experience as I have about going to the dentist. Others openly and freely talk about their projects and how agile was implemented at their organization.
Some of the questions I like to start with are:
- What agile practices have you used?
- What does your sprint/iteration cadence look like?
- What does your release process or cadence look like?
- What agile roles have you done?
- What technical agile practices did your team use?
- What does an average day, week, or sprint look like for your project?
If they answer those well, I drill into different practices to get their take on them. I like to understand how they approach these practices:
- Continuous Integration
- Continuous Delivery
- Pair Programming (either how they did it or what they did instead of it)
- Refactoring
- TDD (Red-Green-Refactor or something else) or Unit Testing
- Automation (all kinds of tests, deployments, etc.)
- Short feedback cycles (unit tests, daily stand up, sprints, sprint planning)
- How they participated in UATs, how they handled defects found in retrospectives
- How they participated in retrospectives, what kinds of retrospectives
- What they would change about their process if they could
- How they planned for the next sprint
- How they planned for the next release
- How they did planning for the bigger picture
Many good Scrum Masters and Product Owners can grow through that list of questions and give me good, well-considered answers. Depending on their background, I don’t expect non-technical people to have in-depth knowledge of technical practices. All people in leadership roles should be able to articulate the process they used and how planning worked in their organization.
Finally, I like to talk about how they dealt with problems, i.e., how they resolved issues in their teams and on their projects. Scrum Masters are supported to remove the issues that prevent their teams from doing work. Agile Coaches need to work with, sometimes reluctant, teams to adopt agile practices. This means that it is expected for them to encounter and resolve problems, issues, impediments, and blockers. Sometimes these are organizational issues, sometimes they are process issues, and sometimes the issue is the people that make organizational decisions. Often these questions have no right answer, and the goal of asking them is to see how the interviewee would approach such an issue.
Some of the experience-oriented questions I like to ask include:
- Tell me about a time where the Product Owner asked the team to change an estimate.
- Tell me about a time you had a disagreement within the team, what happened with it? Why did the team have it?
- Have you or your team ever been asked to reduce the amount of testing the team does?
- Have you or your team ever been asked to take on technical debt? How did you react?
- Have you ever been in the position where you are asked to come in a fix the development team?
- How do you handle getting management to adopt agile?
The goal I have in mind with all of this is to see how they answer the questions and to see their level of understanding of advanced agile project issues. This can help me understand what the responsibility they had in their organization and the level of agile transformation they worked in. I have found that agilists come with many different levels of experience, and learning how to assess them can help determine if they are right for any specific role on a team.
