Welcome to the Hüb – a place where our experts frankly share their opinions, ideas and expertise, their knowledge of the industry, its future and important trends.
Discover the skills of a good Agile Coach, the role in a team and whether you need one at all.
Pour some coffee, put on some relaxing music and join us for the eleventh episode of The Hüb, where Bogdan Doroslovac shares his valuable views on the role of an Agile Coach in a company.
In brief, an Agile Coach is someone who helps a team to better adopt an agile way of working.
Some would say this role is quite similar to the role of a Scrum Master, and there are also some colleagues of mine who would describe an Agile Coach as an overpaid Scrum Master.
In reality, all these things depend a lot on the company, its needs, and its understanding of the framework.
From my experience, this role can be seen in two ways:
But at the end of the day – everything always boils down to people and working with people.
The idea is to humanize people’s jobs and gain a real picture of what things are like, rather than a caricatured one. There is an excellent phrase - “watermelon project” – which describes the state of a project resulting from a lack of transparency, where everything looks green on the outside while inside it is actually all red. Openness, transparency and clearer, more human processes are the way to get a real picture. For example, if there is a problem on the project, you will be aware of it the moment you find yourself in trouble, and not when everything comes tumbling down.
The goal is to reach a point where the team has learned to deal with itself. This includes a simple mindset thing, which is the fact that it is not important what you think or what I think – all these statements are just hypotheses. We need to test them and see what the data from the real world tell us. Maybe this week you are right, and next week I might be right. And, most probably, neither of us is right, or perhaps we are both right. In a complex world, there are no simple answers.
We live in a world of what Peter Drucker, a famous author and consultant, called ʿknowledge workers’. Today’s workers know more than their bosses and you can no longer dictate to them how they should do their work. You need to change your way of thinking – by empowering the workers and placing responsibility where it belongs – down in the trenches.
The majority of modern management and MBA studies are based on a Taylorian model which includes the idea that workers should do only one task in only one way. Today, however, you have highly competent men and women who need to be allowed to do their work in a way they believe to be best, and you should not micro-manage them.
New generations also bring new structures of work. Most people today do not work just to get the work done. They find more importance in their working conditions and, above all, an idea to which they can commit. They want to work less but they want more sense in what they do, so the following question arises – how do we make a job that suits them?
If we take a look at the phrase ’Agile Coach’ – the keyword is none other but ’coaching’.
According to the Shu-Ha-Ri concept, work with people can be divided into three levels:
There has been more and more talk about this coaching mentality, about bosses as leaders. When it comes to leading positions, a great emphasis is laid on this set of soft skills, whereas it is less important to have someone who actually knows how to do the things that are done by the people they are in charge of. Most hard skills can more or less be mastered, and so the most important thing for an Agile Coach is their attitude, their mindset. It is not only important for a person to have a good technical skillset; they also have to know how to work with other people.
I believe that a coach should teach the organization to solve its own problems. All successful organizations have developed some model of scaling the agile way of work (SAFe, LeSS, Nexus, Spotify) precisely because they were looking for a solution to their problems. It is OK for you to begin with a framework, but where you will end up should be the answer to those contextual questions – What do we want? What is the criterion we should optimize against? Why?
Everything needs to be understood as a hypothesis, as an experiment. There is no such thing as ’true or false’. All the things we do may be right but may not be, and we will not know whether our first solution suits us or not until we test it. Sometimes it is better to try anything at the right time than to look indefinitely for the best possible solution. As a personal example: I tried diving and gave it up, now I am roller-skating and I like it. And I could have spent a whole month doing a cost-benefit analysis.