A customer I was working with asked me to help out with the intake process for recruiting a new Scrum Master and a new Product Owner. I asked them what they had so far. They provided a clear job description describing what they wanted to see from the candidates. They also had a great business storyline describing their goals and ambitions and in what way these impact the people applying for the new roles. They planned two interview sessions and wondered what else could be done to increase chances of finding the right person for the job.
In the past they had created cases for developers. The candidates would prepare these cases at home and present their results, showing their ability to create code. My opinion on this practice is that it makes total sense if you want to test the presentation abilities of candidates, which is not what I want to test because giving presentations is not a main PO or SM skill. We want to know if the Scrum Master is good at doing Scrum Master things, and if the PO is good at doing real PO things. I therefore proposed to create cases like they did for developers, but then for a PO or a SM. We agreed it would be best to prepare real work and let them do that work with the team in a one hour session.
The Scrum Master was asked to facilitate a Retrospective with the team. The reason for choosing the Retrospective is because this is the session in which the Scrum Master plays a very important role. The team would then be able to assess the candidates on their ability to listen, facilitate, help the team to formulate action points, personality, etc. Although the Scrum Master is not up to date with all details and does not know the team, he should be able to show his skills by doing a general retrospective using a facilitation format of his choice delivering an improvement action point or deeper understanding of a problem. This will also give him an idea of the team dynamics and will help him to make an informed decision if he would like to work with this team.
The PO was asked to do a refinement session with the team. We chose a refinement because it is such a rich session that requires the PO to take decisions, show his understanding of the domain, work with estimates, deal with stakeholders and team dynamics, etc. To prepare, he was granted access to the acceptance environment to access the product and was given some real wish from the stakeholder, accompanied by a UI design. The stakeholder was present in the refinement session to give more context or answer questions. The work contained unclarities and the information provided was incomplete. As we said, it was real work. We expected the PO should be able to produce a set of sensible estimated user stories within an hour. We were curious to learn what the PO thought of as being most valuable.
The results were great! Experiencing the Scrum Master in action immediately tells you what this person’s soft skills are, how well he can facilitate, if he can manage the time box for delivering actionable items, etc. It is immediately clear for the team if there is a misfit on a personal level too. The Product Owners worked on the same requirements, which was a pretty large chunk of work that had to be split, estimated and ordered. We saw very different results produced by the various candidates. We evaluated the candidates and the results they produced straight after each session. The outcomes were easy to compare because the candidates all worked with the same input material. The candidates that participated all were enthusiastic about this approach.
Downside of this practice is doing the same sessions multiple times for the sake of evaluating a candidate can be a bit tedious. So apply this practice only with the last two or three candidates.
I highly recommend to put job candidates for PO and SM roles in action doing the real work as an addition to job regular interviews. It is a great way (maybe the only way) to learn if a candidate matches your expectations.