5 Important Agile Interview Questions

5-important-agile-interview-questionsIf you are looking to recruit someone new in your company whether it’s for a new Agile implementation, or to replace someone who left, it’s important to get specific Agile interview questions asked up front during the recruitment and selection process.

Below we’ve outlined some basic yet relevant questions that you can ask a potential candidate, and gauge whether or not they are going to be a good fit for your department, team, or organization. That is not to say that your candidate should answer all of them correctly to be considered the perfect member to add to your team, but they should be within some level of understanding on why these questions are being asked.

1 – What does Agile mean to you?

For this question,  you should be looking for closely related Agile principles and values. It’s important to see how close your candidate can get to mentioning and explaining those values of:

A. Check whether your candidate is referring to how they like to interact in groups, looking to share ideas and solutions while promoting team building and servant leadership. If they tend to emphasize the processes and tools, this might not be such a bad thing but you should try to steer them into more group dynamic and group transparency based topics. If they don’t respond or get sidetracked to following orders and making sure everyone in their surrounding work environment must conform to process, this might be a less suitable candidate. However this is not the only basis on which to make your decision.

B. Many who try to impress in an interview, tend to throw ideas out of which documentation they would create and use throughout an agile project. It’s important to see if your candidate sees the value of delivering a working product. If they are the type of person that is trying to make sure everything works around the product except for the actual delivery of the product as necessary, it’s important to see if they are making this distinction.

C. If your candidate is more concerned about how many contracts they can get out of the customer, they might not understand the importance of the other aspect of Agile values which is to try to gain as much customer collaboration as possible. You wouldn’t want interactions with the client to be about how to draft a new contract every step of the way. Remember it’s the soft stuff (people skills) that’s the hard stuff, so your candidate should be able to demonstrate how they are able to engage the customer into problem solving discussions and come to mutually beneficial agreements.

D. If your candidate seems to be more concerned about project plans and gantt charts, they may be stuck in a waterfall mindset. These plans in an Agile setting are a distraction to actually executing the process of developing actual product. For this you should be trying to see if your candidate is looking solely to write-up a plan and make sure everyone follows it (command-and-control) vs. being able to point out the inherent importance of having a team self-manage and create a product based on prioritized features that a market is ruling as important for ROI.

2 – What types of Agile processes have you implemented before?

With this question, you should be able to get the candidate to point out if they’ve actually implemented Agile methodologies whether they are Scrum, XP, Lean, etc.. Key words that you can look for are those found from the beginning to end of the cycles. Words like Sprint Planning, Kanban Board, Burndown Charts, Retrospectives, etc.. You should be able to check and see whether they have an understanding of the ceremonies and events that occur through iterative cycles. More importantly, they should be able to point out why those processes exist and how they fit together to make a fully Agile environment possible.

3 – What is your idea of an Agile mindset?

The character and personality of your candidate fundamentally must be a good match to the agile mindset if they are to practice Agile. Common sense, right? however you might come across some who think they know what it means to be Agile but portray a completely different mindset. You may want to have a look at our other related articles that shed some light on what qualities an Agile Mindset has (or does not):

4 – How often must Agile be practiced during a project?

The answer to this one is simple: at ALL times! If your candidate starts to mention which aspects of agile should or shouldn’t be implemented, as if to compare switching it on or off like a light switch, this person may not actually understand the importance of synergies built over time through agile principles. This question is best answered in a holistic overall “outside the box” sense. Agility is not to be pulled apart and peeled only for certain parts and principles. This leads us to our next question.

5 – Can Agile be tailored?

This is a very important question as the candidate should be able to read between the lines. In practice it’s well-known that you should not be tailoring Agile right from the start unless you have many years of Agile experience. Many of the reasons why Agile fails, is because it is tailored to fit another mold, i.e. trying to fit Agile into Waterfall, and this is where false beliefs about the effectiveness of agile come in to play. Your candidate should be able to respond with a “yes, but…” type of answer. From there they should be able to point out that tailoring is not ideal, and that it would take place perhaps after multiple iterations and sprints, where the agile team notices certain events or processes that aren’t working well for them. This would usually be coming from the Sprint Retrospectives and observed in each successive retrospective to see whether they’re continuously improving or not. This makes the tailoring process more safe and tuned to the team’s needs.

[Image courtesy of Ambro at FreeDigitalPhotos.net]


 

How to Define Your Kanban Workflow Management

Whether or not your workflow management tools include a kanban board with a workflow process via an actual (low-tech) office wall or having a (high-tech) virtual agile software board, you want to avoid having too much WIP (work in progress). If there is too much WIP, you may create too much waste or risk in the form of lagging partially completed work, or excessive waiting. Furthermore, excessive WIP will also cause blockages to be obscured and hidden.

Here’s an example of a comprehensive status workflow automation from beginning to end:

New –> Open –> In Progress –> Code Review –> Code Committed –> QA Ready –> QA In Progress –> QA Passed [or] QA Failed –> UAT Ready –> UAT In Progress –> UAT Passed [or] UAT Failed –> Closed/Done

A more simplified (and recommended) view of this workflow process would look like this:

To Do –> In Progress –> Done

how-to-define-your-kanban-workflow-management/In either workflow solution, it is in everyone’s best interest to place WIP limits. Before your sprint would start, you should be able to determine based on the story points and team size what the typical limits should be as per the agile team roles and team members. These can then be calculated and factored to represent the overall WIP limits for your board to prevent too much clutter. However as you can guess, the comprehensive example above or any type similar to it, would be the most difficult one to set limits to, since the stories would be scattered everywhere across multiple statuses.

Like any complex procedure, it is best to break it down into smaller parts. A simplified board should be used as your dashboard view to get a consistently general view of progress.  Once you’ve scaled down your board as much as possible the WIP limits will become easier to manage. A notable mention is the status “Blocked” which can be shown with a more specific indication of which workflow the block occurrence came from, i.e. Blocked in Dev, Blocked in QA, or Blocked in UAT. This will further allow for a quick response to the blockages.

The example given above assumes workflow management processes are happening simultaneously, but it would certainly be more appropriate to create some workflows in later sprints or specific milestone date if you knew, for example, that UAT was coming at a much later time. The key is to keep it simple.

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]