How to hire an Agile consultant

Advice to clients.

Agile is not a prescription. There is no manual. It is not about process, it is about people—it is about respecting people, and guiding them to more effective, more engaged ways of working. Likewise, hiring an Agile consultant (aka coach) should also be person-focused. These days too many clients are being led by big brand names and low cost to drive their choices. Bad idea. As Agile consultancy scales, it dilutes. It’s inevitable. The big agencies—the wannabe Accentures of the Agile world—may well be able to populate your organization with bodies, perhaps quicker than the small agency, or the independent consultant. And they may even be cheaper. But what are you buying? Do you even know?

So the first piece of advice is know who you are hiring. And I mean personally. Engaging a big-name consulting agency is likely to land you with a random consultant, or group of consultants you have never heard of and/or are unknown in the Agile community. Perhaps people with limited experience, primed to follow the company standards—and who knows what they are, or who sets them. With this method of engagement you stand a good chance of getting a lemon consultant.

Here are a few guidelines to finding the right person for your organization. First a couple of things to avoid, followed by a set of things to seek.

1. Don’t hire a nameless person.
  • Don’t let a consulting agency promise you “the right person”. Chances are the consultant who shows up will have no idea what you need—only what you are asking for, and the two things are rarely the same. 
2. Don’t let cost and geographical locality be the main criteria for choice.
  • Start by selecting people who sound as if they know what they are talking about, and have a track record to show it. It doesn’t matter if they live further away, or cost more. You will likely get what you pay for, and the value a good consultant can offer is often exponentially better than a low-priced alternative.
3. Go by recommendation.
  • Ask friends and colleagues in different organizations to make recommendations. If people you know can recommend consultants they have worked with, this can be (but is not guaranteed to be) a good sign. It is at least a better starting point than responding to a Google ad, or a spam email.
4. Plan ahead.
  • Engage in the Agile community through reading blogs, joining discussion groups and attending local Agile meetups or gatherings. This way you will get to know who you connect with, who is making sense, who has the experience you think you may need.
5. Research the consultant.
  • Does the consultant keep a blog? Is he* on twitter? Read the blog posts. Follow the tweets. Why do these things matter? Consultants who themselves engage with the Agile community are the risk-takers, the ones not afraid of bad press—just read some of the feedback comments on their blog posts—we call each other out, challenge each other to new ways of thinking. Look at how the consultant responds to criticism. Is he defensive, or embracing?
  • If the consultant has written a book, read the book—or at least read the reviews on amazon.com, or other booksellers/industry magazines. If there are no reviews, be wary.
  • Forget resumes. Resumes are dry, empty documents written to sell the consultant. Don’t be sold. Use the principle of attraction over promotion: seek engagement with consultants whose public voices touch or inspire you in some way. Seek them out.
  • Forget LinkedIn. Every consultant is on LinkedIn, and each has carefully vetted feedback comments. LinkedIn is for people who want to do business. Blogs and Twitter are for people who want to engage in community.
6. Seek a consultant who is willing to say “I don’t know”.
  • Many consultants will come in with solutions—without knowing what the problem is. This is especially true of Agile consultants. Agile, in its many guises, e.g. Scrum, Kanban, is often seen as a cure-all. Process is often imposed—and with the larger, tool-vending companies, a tool is imposed right alongside. Beware of this. Agile tools usually force a process that may be (in fact quite likely is) entirely wrong for your context.
  • A good consultant will come in to your organization with a beginner’s mind. With no solutions. He will come in with ignorance rather than expertise. Take this as a good sign. If you have done your homework on the consultant, you have nothing to fear. Solutions emerge from understanding. A good consultant will seek to understand.
7. Meet with the consultant face-to-face before engaging him.
  • Look him in the eyes. Hear how he speaks. Listen for assumptions he may make about your organization. Assess the conversation, is it a pitch, or is it more like a two-way dialog, to explore and learn. Again, don’t be sold. Listen to your gut.
8. Request an initial assessment—avoid big, up-front commitments.
  • You are hiring an Agile consultant. Be Agile about it. Create frequent inspect/adapt moments in the engagement plan to assess value. Ensure a clear exit strategy is implemented at these points, for either party.

I may add a couple more items to this list—or perhaps commenters of this blog will add their own. For now, I see this as a good starting point. 

In essence, the onus is on you, the customer, to take the time to find the right person. This is not about “staffing” or “resourcing”, this is about meaningful engagement with real people, towards the end of effective product creation. Take the time to do this well. In the end the ROI will be far, far better.

* I use the terms he/him as the best approximation our language has for gender-neutrality. Our minds are conditioned to balk at the use of she/her, in a way that distracts from the content of an article. Sad, but true. Mixing ‘he’ and ‘she’ in the same post for the sake of political correctness, or using the hideous, and grammatically incorrect ‘their’ are simply not options for this writer.