Agile Coach Interview And Selection Questions

Years ago I was hiring agile coaches, and working closely with a hiring partner who was really really (!) good at finding talent. I had no time, he had some time and was keen to help me in any way we could figure out how. I knew agile, he knew recruitment. I knew coaching, he knew people.

The first round questions that I designed then still hold true today. I was inspired by Joel Spolsky's 12 questions candidates should ask their potential employer before deciding to join back in 2000. It may be a little old in some circles by today's standards, but it is still insightful imho:

The Joel Test:

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

The neat thing about The Joel Test is that it’s easy to get a quick yes or no to each question. And that's what I needed from my first round interview questions that anyone, even a non-agile-skilled or non-agile-knowledgeable person could use. So I came up with 24 quick questions, and we got some truly great candidates making it through the face-to-face screenings.
One of the most (perhaps THE MOST) important things about an agile coach is their experience. Money can't buy experience. Reading about other people's experiences, or attending courses based on other people's experiences is not the same as having the direct hands-on "did the best I could with the information and knowledge I had at the time, and nothing worked...until...after much persistence and many failures something worked!"

All experience is relevant. I am wincing at how arrogant I was when I was younger thinking that attitude mattered more than experience. They are equally important - it all depends on the problem space and time! The thing about people without experience in a particular space, is that they don't know what they don't know. My 24 questions highlighted things that were relevant for the different openings we had going at various times. A quick 10 minute Yes/No followed by a few initial typical HR availability, package suitability, location, role etc matching minutes and wallah - 1x effective initial screening for very cheap!

The very few who made it to face-to-face interviews which were experiential and enjoyable for both the coaches and the candidates highlighted the right candidates each time! Happy daze! (especially compared to traditional candidate screening processes and pains)

Rob's Agile Team Member or Agile Coach 24 Question Assessment:

1. Do/did you use source control?
2. Do/did you not use source control?
3. Can/could you make a build in one step?
4. Can/could you not make a build in one step?
5. Do/did you make daily builds?
6. Do/did you not make daily builds?
7. Do/did you have a bug database?
8. Do/did you not have a bug database?
9. Do/did you fix bugs before writing new code?
10. Do/did you not fix bugs before writing new code?
11. Do/did you have an up-to-date schedule?
12. Do/did you not have an up-to-date schedule?
13. Do/did you have a spec?
14. Do/did you not have a spec?
15. Do/did programmers have quiet working conditions?
16. Do/did programmes not have quiet working conditions?
17. Do/did you use the best tools money can/could buy?
18. Do/did you not have the best tools money can/could
19. Do/did you have testers?
20. Do/did you not have testers?
21. Do/did new candidates write code during their interview?
22. Do/did new candidates not write code during their interview?
23. Do/did you do hallway usability testing?
24. Do/did you not do hallway usability testing?

After you have all the "yes" and "no" responses to these, you will know the level of "modern" and "old" styles of developing and delivering software. Now you get to decide how to direct the rest of the experiential based interview if you decide to let the candidate through to face-to-face more investment round(s).

I advise experiential interviewing during the face-to-face as it is a case of "under stress, we regress", and a lot of coaching can be quite stressful as very little is under the control of the coach who is at best influencing the situation! And any coach who has not mastered conflict management and resolution skills, personal attacks, helping people overcome their own anxieties etc can be quite damaging to your organisation.

f you're more focused on a coach who's technical background is less interesting, you could take a look at the coaching levels and the types of coaching and design similar Yes/No questions to try and understand the tangible hands-on experiences a personal, executive, soft skills, etc coach has.

I suggest at the beginning of the face-to-faces to do some spot-checks to check that whatever Yes/No questions you screened with were correctly interpreted, and that the candidate's response was accurate before proceeding into the simulation(s). Some people, you know, will say anything to get a role! :O

After the simulation assessment(s), ensure you and your assessment team form and document your own, subjective, fact-based, Delphi-style, assessments of each candidate.

My final question for the candidates: Ask each candidate face-to-face what their opinion is of the other candidates. You'll be or not surprised how many candidates know, or know of, the other candidates, and their face-to-face opinions can be quite informative! Also insightful is how they react to those coaches they don't know or know of.

So hopefully by now you have collected all the minimal data points to make a more informed decision about finding the right candidate - a round peg for a round hole / a square peg for a square hole - for your people's (!!) needs. Remember, past performance is no guarantee about future performance. But also remember this is a critical role to match the right person to - as any change agent will by the nature of the role be disrupting people's comfort zone(s). Including your own often.

Good luck with your search and selection process!

Lastly, please let me know how it all works out for you and your organisation. Remember the most important (top) line of the Agile Manifesto reframed is a bit like "we're doing it, and by doing it we discover new and better ways of doing it, and we share with others what we have learned so that we all benefit". That's "agile"!

Thankyou for supporting!

Agile Principles 102

I was looking around for how to make my teaching of the agile principles much better than my and the class's experience of them as per "industry standard" captured in my earlier post: agile principles 101.

Somewhere along my many readings over the years, I came across an article describing changes to the teaching method for fire fighter training used somewhere in the US (to the best of my recollection). I've hunted for the reference but have not found it again (yet) unfortunately.

The fire fighter training story went along the lines of teaching trainees by having them watch videos of fire fighter crews operating in various scenarios and then facilitated debriefing of the elements that made each crew successful. Apparently this change to the previous training method was marginally better as there was a minor percent improvement in successful rescues / blazes extinguished / fire fighter injuries and deaths.

Then someone discovered that a small change to the content produced much better results. Instead of showing the trainees scenarios that were successful and then debriefing, they showed unsuccessful scenarios and then debriefed the errors. 

Scenarios where fire fighters in their rush to save took personal risks, overlooked snagged hosepipes, did not operate the hosepipes and ladders effectively as 1 team, etc. And the result of these individual, and at first glance, minor errors, rescues failed, blazes were not extinguished and fire fighters were injured or died. Debriefings of these failure scenarios caused the trainees to learn (a lot) more, and (a lot more) quickly, which was quickly demonstrated by these new crews having much higher percentage success rates, and most importantly, fire fighter injury and death rates!

Similarly in the UK, I've heard that people who've had driving points deducted from their licences are shown videos of accidents that were caused by speeding drivers, intoxicated drivers, drivers in non-roadworthy vehicles, etc. Learning from the bad impacts us more, and teaches us good.

So...I thought I would apply this principle to teaching the agile principles.

For many many classes, I spent a few more minutes on the same slide I used previously (how lucky to not have to "waste" any more precious slides on this foundation to the whole huge "agile umbrella of knowledge"!

This time I did not reveal the "masterpiece single slide" in a single click. Instead I made use of PowerPoint's fly-in, appear, and other "On Click" events to have the bullets appear as required (some lines are longer or more complex than others, so give the trainees a few extra seconds to read and understand, occasionally - I am such a nice trainer!)

So now I had the class read 1 principle at at time, and after everyone finished reading the current principle I asked the class - "What effects would happen if you/we did this?". Followed by "And what effects would happen if you/we didn't do this?".

Typically the 24 DO / DON'T outcomes (which I hoped were deep realisations embedded forever in the learners' consciousnesses) were similar to below:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

DO:        Happier users getting valuable features earlier

DON'T: We don't satisfy our users, sooner or later we lose our jobs

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

DO:        The development team adapt whatever we/they do to accommodate users' changing minds
DON'T: We build the wrong thing, we don't satisfy our users, sooner or later we lose our jobs

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

DO:        Happier users getting features preferably every few weeks or few months
DON'T: We give our users unusable software quarterly, half-yearly or annually only, we (in)frequently upset our users, we lose our jobs.

Business people and developers must work together daily throughout the project.

DO:        The business and developers work together and become 1 balanced team
DON'T: Business and development don't understand each other, don't know each other, don't work as a team, so the environment is low trust, low knowledge, low productivity, work and value does not flow, and people are stressed and unhappy. No one is satisfied with anyone, including ourselves, blame game is played often, so eventually we lose our jobs or we leave our (bad) jobs.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

DO:        Hire good people, support them, they are super motivated and do the best job they can

DON'T: Don't support our people, give them bad environment(s) in which to do complex work, don't support them, and continuously interfere with how they do what we ask for. People get frustrated, and either they leave their jobs, or eventually lose their jobs because they're just blocked from doing (enough) good.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

DO:       Less documentation, fewer/no hand-offs, more quality conversation which is better for conveying difficult abstract details and concepts to each other. More productivity time.

DON'T: Convey information to each other in the least efficient and least effective ways, resulting in miscommunications, misunderstandings, and a lot of wasted time, effort and money. All this waste results in unhappy business people, we lose our jobs.

Working software is the primary measure of progress.

DO:       Everyone believes the development team's progress "report" as it is clearly running in front of eyes and fingers, or not, and hence everyone can plan more confidently based on realtime, real, information.

DON'T: Measure progress by some other means - maybe Red-Amber-Green "traditional" governance reports, Earned Value Burnups, (C)RAID Logs, and we plan based on those abstractions of progress, and quite often those abstractions are not reality and may be quite stale at moment of understanding. And when progress reports are not reality, a lot of wasted time, effort and money goes into that "cottage industry" for negative Return-On-Investment (ROI) and the organisation's plans are wrong. This results in unhappy business people, and ... job losses.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

DO:        Everyone goes together and works together. Few surprises. No late night and weekend work for anyone. Morale stays high and energy levels are protected and nourished.

DON'T: People work late nights, weekends, get tired, get grumpy, produce bad quality plan/artefacts/tests/requirements/analysis/code/architecture/designs/workshops/sessions/meetings/etc. Boom-and-bust cycles. People miss their personal lives, they leave their jobs. Quality suffers, the users and company suffers, and ... job losses.

Continuous attention to technical excellence and good design enhances agility.

DO:        Our codebase remains cheap to maintain, nice for people to work in and learn from, and we can realistically and constantly "welcome changing requirements, even late in development" from Principle 2 above. :-)

DON'T: Our legacy codebase becomes expensive to modify, it is no longer "soft"ware, it has become "hard"ware, and people hate working in it because little changes require great effort and introduce great uncertain risks that developers are unable to easily (if even possible) mitigate and hence the developers appear to go slower (but actually they're doing a lot more difficult cognitive work!). It creates cognitive dissonance in developer's minds and this is tiring and annoying, so they get sick of it physically due to stress and sickness rates are higher than "normal", developers/analysts leave temporarily on long-term illness, or leave the role, or something blows up in production, and after a short period of job creation (Operations needs more people to deal with poor Change/Development/Tech/etc outputs) ... eventually job losses.

Simplicity--the art of maximizing the amountof work not done--is essential.

DO:        We keep things simple, we save effort, time and money, so more productivity and happier users!

DON'T: We overcomplicate things, waste a lot of effort, time and money, sometimes even make quality worse. We maximise workload, decrease creativity and innovation, and people leave their jobs, or we lose in the market place and eventually lose our jobs because our competition is quicker with new features and products.

The best architectures, requirements, and designs emerge from self-organizing teams.

DO:        The team knows their design, requirements and architecture inside-out, back-to-front and can confidently do things at speed, knowing "where the skeletons are buried", and where they risk nothing, a little, some, more, a lot, or "bet the whole farm" - when they have to.

DON'T: The worst architecture and worst requirements are pushed onto the team who don't understand or know them evenly or equally well, and hence unintentionally build the wrong things in the wrong ways and nothing integrates or works properly, or worst developers paint the whole codebase into a corner. The users and business people get upset as the investment is lost, developers ... lose their jobs.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

DO:      We continuously learn and improve and become stronger as a team - we become a high performance team that can do anything.
DON'T: We keep doing the (every) thing(s), the same way(s), we never get better, we never modernise our skills, we get bored, we are boring, we are overtaken by other teams, we look bad in comparison, we ... lose our jobs.

In a nutshell, the benefits of this teaching/learning agile principles approach are:

1. The trainer can "tick the box" on the "we covered the basics" section / poorly defined learning outcomes
2. Only 1 slide!
3. Only 1 page to print for the pack for the attendees! Save the trees! Save the planet!
4. It's much better than just a single slide of reading and a short FAQ (aka  agile principles 101) before moving on as some of the learners do engage with the thinking process and take some of the messages into consciousness!
5. There is some interaction with the trainees!

The consequences of this teaching/learning agile principles approach are:

1. Not enough positive effect or impact on the learners
2. Some negative impact on many learners as they begin to feel that agile is being forced on them, that it's "go agile or lose my job". "People don't resist change, they resist being changed." - Peter Senge
3. Some learners feel left out and/or confused by this session - seriously only 1-3 louder folks engage passionately with this approach
4. Learners realise the trainer might not be a good one or the training content might not be good

Post mortem: 

Did you notice who gets more benefit from teaching the agile principles like this? Who is not getting benefit? What about all the negativity taste in the mouth at the end? 

"go agile, or lose your job!" is not a positive message nor a reasonable call to action! Look how well "Stop smoking, or die!" or "Lose weight, or die!" is working in the health industry. It's not that these things are not true to some degree, it's that they're also false to some degree. And the framing does not allow for that "shade of gray" - so people can spot just one counter example and choose (with logic) to disbelieve all of what the principles are trying to encourage understanding of.

This approach does not work well enough. A negative call to act only works when the person called this way really believes that they will actually die otherwise (a gun to the head, and someone's finger on the trigger, and no doubt they will pull it unless you do as they say), and even then, a substantial number of people (and in team work, you only need 1 to be out of alignment) will freeze or flee in different direction. Some will evenly actively fight against it - sabotaging, cynical outbursts, campaigning, using Schopenhauser's methods to win any argument. 

A handful of learners will become more aware of the big picture and hence will support because they believe. But that's not good enough unfortunately!

Also, the summary interpretations are a HUGE gap from what the principles are actually saying!

Users and customers are not always the same thing! The market place - the fact that every software team member is facing off to the market place no matter if they are the networking engineer, database guru, feature team member, scrum master, product owner or any other role required to get the software Done, is overlooked - even in this approach. And this is fundamental - that's why the highest priority is called out so explicitly at Number 1 position!

Every line of code or configuration or content that in some way supports the objectives of the business' service to its customers is either "for" or "against" success in the market place. The principles are trying to make "IT" folks aware of this, as most are blissfully friends with their computer and that's most of the extent of the engagement with the firm they work for. They can't see the tight chain of inter-dependence that truly exists between how quickly and cleanly and consistently they work, with how well the end customer perceives the company.

This approach is more effective than the industry standard agile principles 101, but it causes a lot of hostility quite quickly and hence is simply not effective.

Don't teach or try to learn the agile principles this way. Rather use this as a thought experiment (or 12) once you have taught or learned them in a more positive way. I'm documenting my experiences via my earlier post What Is Agile For so if you are interested, read the other methods linked there!

Thankyou for reading! Let me know what you think!