In the conferences I participated in during spring, one word was at its peak: professionalization. Weary of seeing the marketing success of the word agile empty it of its meaning, weary of seeing an army of beginners ravage notions that took time to emerge, everyone was expressing their desire to protect, to delimit, to reaffirm their profession in agility, whether they were coaches, devs, or in any other position.

Some are considering a certification. Yet another one, when 100% of certifications have shown their uselessness, and worse their harmful aspect. But yes the market demands them (for the wrong reasons). Others suggest peer recognition groups. “If you belong to this group, it’s a guarantee of professionalization.” Perhaps. But many quality people still won’t be part of it. And good people can get lost along the way, we’re all cyclical. So on structuring the recognition of professionalization, I have no solution. I currently only believe in word-of-mouth, or in actions: I can see what this person has accomplished, what they have produced, the universe they have built around them. I don’t listen to what they say about themselves, I look at what they do. And I come back to word-of-mouth.

But on the question of professionalization itself, I could have my opinion. What is a good professional? I’m not going to paint a specific portrait, there can be many good professionals who behave very differently, who are of very different natures. They can be gentle, harsh, patient, impatient, etc. They will be good professionals in my eyes as long as…

Three pillars of agile professionalism?

a) They understand well the principles and philosophy of these agile approaches. This creates integrity and coherence in their responses. In fact, they can adapt their responses to the context while knowing how to respect the principles that found this movement of thought.

b) They seek to respond to the client’s needs. This seems obvious. And yet, how many times have I seen people simply testing their workshops, or their frameworks despite any need behind them. And I almost want to say: they respond to the need of the situation in accordance with agile principles, because it’s not always the client who knows, understands or expresses the real need, but that’s another subject.

c) They can say no when the client need, or the client’s posture do not allow things to move forward in the right direction. They therefore have autonomy (financial, decision-making power) to stop the support (and to explain why), or to condition its continuation. (This is not about being stubborn or despotic, and ignoring change management, you understand me).

When one of these pillars is weakened or absent, the others suffer.

If you don’t know, nor understand well, the principles and worldview of these agile approaches, you’ll respond off the mark to your client, or you’ll roll out a pseudo-recipe (the only artificial escape that makes you believe you know what you’re doing).

If you don’t respond to the client’s need, it’s impossible to judge any improvement, and if by chance it occurs, impossible to rely on it to move forward.

If you can’t say no to the client, or to your boss, your action will lose all coherence and interest. (The possibility of saying no, not the obligation).

Let’s dig a little deeper

However, I quickly imagine that these three pillars stated so simply will satisfy too many egos too easily. Let’s put tests on them.

Test of agile knowledge

• You know how to explain each of your proposals by making explicit the principles hidden underneath. What you’re looking for, why these principles are important, and how they are “agile”.
• You know how to make proposals without using any jargon, any keywords, any proper nouns.
• Each of your proposals belongs to a coherent system. None puts another in an awkward position.

Example of a dialogue: To have an approach that regularly develops finished things on which we can take a real look, have a real opinion, do real tests, we need to break down our need in a certain way, and we need teams built to carry out this “end-to-end” approach, so we need heterogeneous teams, not teams by expertise.

Test of responding to client needs

Normally you work on a derivative of:

• Bringing their projects to completion.
• Not wasting too much time, too much energy, too many resources trying to move forward.
• Having something that works well.
• Having something that is interesting or useful.¹
• Ensuring the organization’s survival if part of the organization disappears.

Why? Because you work for an organization that has a purpose. Everything should tend toward this purpose (apart from the question of survival). If you tell me you’re working on people’s well-being, I’ll answer that it’s a means, and that you need to know the purpose. If you don’t need to know the purpose, you may be a very good professional, but you’re not working in agility.

I’m doing a workshop so they get to know each other better. NO. I’m doing a workshop so they get to know each other better because I think it will help the group’s outputs function better. So I’m not going to be sensitive to the fact that they get to know each other better, but I will be sensitive to the question of how getting to know each other better will bring added value and thus make their outputs function better. This will change everything. And perhaps even completely my operating mode, my choice of support, etc.

Ability to say no

Here the answer is obvious if you’re honest enough with yourself. You know very well if you’re swallowing bitter pills or if there’s a real dialogue with your client or your hierarchical managers (if you have any). In this dialogue you can say no, and you can be told “yes but let’s try anyway”, it happens, it’s normal, and you try. But if your proposals are never listened to and your nos are never or too rarely heard, you know it very well. It’s up to you to make the right decision at that point. It’s not immediate. My principle is to tell myself that you have to give three/four months for this dialogue to establish itself. If over a period of three to four months you haven’t been heard, you need to leave.

But can you? Perhaps despite all your good will, you need this contract and the money that comes with it. That’s understandable. You’ll also understand that this removes some professionalism from you, because you know perfectly well that you’re no longer responding to the client’s need, but to your need, to earn money to live (which is legitimate).

Not being a good professional

No problem, it’s completely natural, it’s a journey. Everything is fine if you’re tending to become one. Nothing is fine if you’re complacent in the errors seen above: you recite recipes without understanding, you don’t respond to needs, you can never say no (it’s the possibility of saying no, not the obligation).

Besides, we’re always tending toward this good direction. The contexts, the moments in life, the support phases, one’s journey, it stirs things up, and we must tend toward this professionalism, this quality of agile presence.

I’m not saying anything difficult to understand, but you have to do it.