What is a Minimal Viable Agilist?

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.

The product with the highest return on investment versus risk

Popularised by Eric Ries it subtly changes to

The smallest thing you can build that lets you quickly make it around the build/measure/learn loop

I must profess I have a few issues the MVP concept.

My first is the term. The term MVP is all well and good for you version 1.0 of your product, but what exactly is your next cycle through the loop called – is it called a Minimal Viable Product as well? Why do we not refer to the refinement or further iterations of the build, measure, learn (BML) loop as Minimal Viable Increments? Or better yet, BML increments? We know from using Lean Startup that we rarely get the product right first go, so we should have some simple term that talks about getting it closer to right shouldn’t we?

My second issue with MVP as a concept is that people forget that there is a life cycle to products if you do manage to be successful post the Startup phase. Let’s go through the scenario – you build your first MVP, you increment on it through build, measure learn, you begin to realise customer value, customer growth and manage to retain customers, you increase business revenue; in essence, your startup starts to succeed. Then your customers continue to grow. Suddenly your little tiny product is not handling the growth. You need to desperately take what was a tactical solution and industrialise it, strengthen it so that it can handle the next stage of growth. Your minimal tactical product just isn’t cutting it, it simply isn’t viable anymore. At this point in time the increments from a BML perspective need to focus on operational sustainability – how can you build a platform to sustain an acceptable performance? I call these minimal strengthening increments.

My third issue with MVP is that if you are doing it in a non startup environment – ie an intrapreneur in an already existing and flourishing business, is how to deal with reputational risk. In these large corporate organisations you need to worry about compliance to major standards, either in the country or internationally, you may also need to worry about how your existing shareholders feel about a non polished product out in the marketplace. It is for this reason that you could venture down the path of white-labeling the product, ie taking your brand off it and registering it under a smaller shell of the company, but often it means that the MVP becomes not so very minimal as the company is unwilling to incur reputational risk.

My fourth and final issue with MVP is the very difficult balance between MVP and minimal viable experience (MVE). Sure you could put a product out there to begin learning from, but if the content or the experience of the product is not compelling enough then you are going to risk turning away customers and that comes back to reputational risk for large corporations. Some call this a minimal lovable product.

Don’t get me wrong, I love Lean Startup, but in conclusion, if you are applying it into a corporate environment it is not going to be enough to ensure success and many different considerations need to me made. In a large and established organisation consider the minimal viable increment, the minimal viable experience, the minimal riskable product, and the minimal strengthening increments.