First of all, let me explain how to distinguish a coach from a trainer. A coach helps to change or develop someone’s behavioral patterns to help them through obstacles that they cannot overcome because of their personality traits and manifestations. A trainer, on the other hand, transfers knowledge.
Wanting to charge more and calling yourself an Agile Coach rather than an Agile Trainer is an obnoxious and counterproductive tactic.
Knowledge transfer and development are just as valuable and monetizable services as the shaping of personality or behavior patterns, and both may be charged the same amount of money. So let’s stop this Agile Coach approach and call ourselves a trainer if we are actually trainers and not purposefully engaged in shaping someone’s behavior patterns.
To become an excellent Coach requires a lot of training. It is no coincidence that many coaches have a degree in psychology or, where appropriate, a specific psychiatric practice, alongside which they do coaching as well.
So the correct question is:
How to choose an Agile Trainer?
A person who contacts you as an Agile Coach if they are not aware of the difference between a trainer and a coach has already scored a pretty strong negative point.
Let’s assume that the person knows the difference and therefore has passed the first exam. To work with an organization as an Agile Coach, you need a certain amount of experience. This experience is built by going through the journey needed in order to be called an Agile Coach or Trainer by the market.
You don’t become an Agile Coach/Trainer by taking an Agile training course and suddenly becoming qualified for it. You can become one by gaining the right amount of experience, AND by taking a lot of trainings and processing a lot of literature along the way. It is a very challenging and exhausting journey. How many years does that mean? Certainly more than five.
This means that you have spent at least that much time in different Agile roles and/or Agile organizations, most likely as a Scrum Master, Product Owner or Change Agent. It is in these roles that you can typically pick up the experience and knowledge you need to be able to represent to others in a credible way what the right way is, where to start, where “North” is in the transition.
The fact that someone has been an Agile Trainer for several years is of no interest to me. It’s much more interesting if this person has actually implemented, tested, used, refined over the years the knowledge needed to excel as a Scrum Master or Product Owner.
It makes no difference if he/she was a software developer in an Agile team. Having said that, of course, with all due respect to the software development wizards! Without them, our knowledge is worthless.
He/she shall know the manifesto by heart!
Let’s suppose that your candidate knows the difference between a Coach and a Trainer, that he/she has gone through the journey, and that as a result, he/she woke up one morning as an Agile Trainer.
The next thing to check with the candidate is whether they remember the Agile Manifesto. Don’t be shy. Give him/her a piece of paper and a pen, and have him/her write down the four points of the manifesto by heart, in the correct order, in English, word by word.
This is critical, because a trainer who knows Agile tools, but does not know the manifesto by heart, does not and cannot really understand the essence of the Agile approach, cannot give awareness-raising advice, help and support. If he/she can only think in terms of tools… they are useful, but they are far from the same as being able to influence the way people think because you know the philosophy and the fundamentals of the whole methodology.
After the four points of the manifesto (www.agilemanifesto.org), ask him/her to also reproduce the 12 principles for us in writing, by heart, but this time not necessarily in order and word by word.
The 12 principles always and in all circumstances provide guidance for situations that may arise in an organization. Anyone who knows and understands the principles will always know the right way and the tools to use.
I realize that being able to learn the manifesto does not automatically mean that he/she also understands it.
However, if someone has worked for years as a Scrum Master or Product Owner, and has tried to achieve some results in an Agile environment, with Agile teams, using Agile methodologies, AND he/she knows and understands the manifesto, that is a pretty good sign that the candidate is in the know and did not just memorize the text.
I also want to be a Scrum Master!
Favorite point?
Once he/she has passed this test as well, the next question is: what is his/her favorite point? Ask him/her to tell which of the 12 methodological principles has had the greatest impact on him/her. Everyone who has been trying to achieve something with Agile transition for years will have a favorite. For my master, it is “The art of maximizing the amount of work not done”, and for me, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”. If he/she can tell you what his/her favorite thing is, the next question is: why? Their response should be made up of very specific work experiences and stories… Let’s say this was also fulfilled.
Failure is the greatest master
He/she should tell you at least five personal experiences when, as an Agile Coach/Trainer, Scrum Master or Product Owner, he/she has failed in some transition attempt or methodological experiment. What has he/she learned from these cases? How has he/she incorporated these experiences into his/her life, work, profession?
This is a critical issue because a very important principle of Agile organizational transition and operation is the tool and approach of “early failure”.
Make no mistake, this does not mean that you can mess up anything and say “agile” and then everything is fine. This means that you have to work in such a way that you can see soon enough if something does not work out. Lessons must be learnt from the case and put into practice straight away. On the next attempt, mistakes already made should not be repeated.
Anyone without such experience can be an excellent supporting actor in a transition project. And we need plenty of such people! They will gain the necessary experience with us, while, as a supporting actor, they will probably only bring benefits. Let’s say that our candidate has also passed this step.
How much is the fish?
What is left? The price. It is usually the price negotiation that everyone leaves to the end. This is a huge mistake! The price decides everything. Always start with the parameters that can be show stoppers.
It makes absolutely no difference what a person can do if no one is willing to pay for his/her work.
Always start the meeting with that: What’s the price?
The candidate tells you what his/her daily rate is, and you tell him/her how much you are willing to spend on him/her. If the two are close, hooray; if they can be approximated, that’s the first point worth addressing; if they’re not worth putting in even the effort required to approximate, then all other efforts are pointless and a waste of time.
And what else?
What else should we look out for in the meantime? Pay attention to any visual aids that the person might be using. Pen, paper, whiteboard. You need someone who will have to do a lot of drawing to support the connection of all the different actors.
An experienced trainer knows that it’s not enough to talk about the world-changing clever stuff, it has to be drawn as well. An Agile Coach/Trainer will have to draw a lot to ensure that the same image, the same message appears in people’s minds in the same way at all times.
If we rely only on words and the images that words evoke in others, we can be sure that the transition will take much longer, which means much more money, friction and damage to the organization. If he/she doesn’t draw or write on a blackboard, it will be very difficult for him/her to operate in a transactional environment and minimize communication damage.
I want to try my hand as a Scrum Master!
The right business model for the Agile Coach / Trainer
A good Agile-minded person does not want to create a “hotel trap” for the customer. The “hotel trap” is where the customer can, in theory, leave at any time, but, in reality, the conditions are such that it is only worth it in very extreme circumstances. So they are forced to stay. A truly Agile businessman/woman comes with a business model where:
- He/she can show me where and how the money we pay for him/her will be worth it. So he/she is prepared to outline the ways of generating business value added, and to give tips and hints on how to measure it.
- He/she sets conditions so that both he/she and the customer can easily and quickly close the cooperation with fair settlement and value delivery. This is in the interest of both parties in the short and long term.
This is the approach that lends credence to the saying that the Agile Coach/Trainer is there to provide support in the organization’s ability to create business value.
However, it must be mutual in both its approach and practice. - A truly Agile Coach/Trainer is interested in customer impact, and not in maximizing revenue.
