Agile Forest

I have been doing some hiring lately. The two roles I have been hiring for are a Scrum Master and a Business Analyst. I used the opportunity to test my recruitment questionaire – questions that I am expecting the organisation to ask in the future when I am no longer there in order to ensure that they are getting quality candidates into the roles.

The questions had some basic Agile bits, the sort to ensure that we were getting people who culturally understood T-shaping, the values and principles of Agile – not that they had to ring them off by rote, but they knew and understood what it felt like to experience them.

And then there were the role specific questions. For the Scrum Masters the test predominantly comprised a series of pictures with a question per picture. An example (without showing the picture) was “Take a moment to orient yourself to this wall – what issues do you see with the team/the work?”

If the Scrum Master applicant passed the basic Agile questions and the wall picture questions, stage three was getting them to demonstrate facilitating in a mock scenario.

Somewhat thankfully our search for a Scrum Master didn’t last too long – candidates that recruiters passed through to us all failed abismally. All of them didn’t even pass through the first stage to begin asking the picture based questions. Feeling despondent we did the whole ‘Who do we know who can do the job and are actively looking?’ thing. Interestingly they passed all three components of the test quickly.

So then the challenge was finding a Business Analyst, and that was indeed difficult. We had resumes without even a reference to the word ‘stories’, ‘Agile’ or ‘Scrum’ being put forward by recruiters despite being exceptionally clear that we were looking for Business Analysts who had strong experience in an Agile environment.

There were a couple that got through to stage two testing – but they were few and far between, many of our interviews got cut at 10 or 15 minutes.

It was very frustrating; we weren’t asking questions that were hard – we were asking questions that anyone who cares about being good at their job should be able to know the answers to.

So let me put this as simple as I can – if you aspire to be an Agile Business Analyst, or you think you are worthy of being an Agile Business Analyst and selling yourself as one, then these are the things I feel you should be able to answer (naturally these questions are more fluidic and are asked when a conversational element exposes their relevancy):

1. How do you decompose something down from a big idea to something that can be delivered by the team?
2. What qualities does a good user story have?
3. How do you know when a user story is small enough?
4. If you had a user story that was too big, what are the different strategies you would think of/use to try and break it down further?
5. What is the difference between Acceptance Criteria and Definition of Done?
6. On average how many Acceptance Criteria do you have per user story?

If the answers to the above questions are correct then the interview goes onto stage two – scenario testing. Similar to the Scrum Master test we provide a simple User Story and ask the person to define some Acceptance Criteria. Then we ask them to look at a number of poorly formed User Stories and tell us what is wrong with them.

Stage three, like the Scrum Master is practical, asks for a demonstration of analytical and breakdown skills through a scenario, ultimately to test facilitation skills and on the spot thinking.

Now I won’t reveal the answers to the questions above, but if you feel like giving a try and responding in the comments you are welcome to. Additionally I have left out some of the thinking processes that we have been looking for but I can reveal that answers like “I just do what I did back in waterfall – I talk to people and write the requirements. Business Analysis is no different in Agile than in a Waterfall environment,” is probably not going to get you the job.

But through all these interviews what I was most surprised with was how little people cared about the quality of their skills in their chosen profession. I am often frustrated and don’t know the answer as to why people know so little about their profession. Here are some possible root causes I have conceived of but I don’t know which is the right answer (I suspect it varies based on the person):

1. I am too busy doing my job to learn how to be more effective in it (too much work)
2. I work hard when at work, in my down time I don’t want to think about work or read about things related to my job, I just want to relax
3. I studied at school and for my degree, I was so glad when that was over I didn’t really want to study anymore
4. I am awesome and don’t need to know any more/get better
5. I am sick of people telling me what to do and how to do it, I am just going to do the smallest thing I have to in order to get my paycheck.
6. Understanding this change threatens my job in some way
7. I get by, no one else has commented on how I do my job

And so the ultimate question that it came down to in the interviews were “What is a Minimum Viable Agilist?” To me it is a person that cares about their craft, that understands the value of spending time to make themselves better and in doing so making the product better.