In my opinion, the worst thing agile coaches can do is to introduce practices they cannot motivate. And by “motivate” I do not mean that they can recite the relevant passage from the Scrum Guide or from some book. By “motivate” I mean that they actually reach and convince the people they are dealing with.
The burden of proof that a specific practice is useful is always on the agile coach.
Saying “It’s done like this, because we do Agile/Scrum/Kanban/Whatever” is only marginally better than saying “It’s done like this, because I say so.” If we accept these as valid arguments, then we also have to accept “It’s done like this, because we always did it this way” as a valid argument – and it is a common argument of people who oppose Agile, because they want to hold on to their old processes.
If someone asks “What is a retrospective good for”, we should have a meaningful answer and not just something pre-packaged from the Scrum Guide, such as “It’s an important inspect-and-adapt meeting”. That is like saying “It’s important, because we do Agile”, because after all, Agile is the reason why we run frequent inspect-and-adapt meetings. But why do we run frequent inspect-and-adapt meetings in Agile? We need to be willing and able to dig quite a bit deeper here. I would recommend using the 5 Whys method here before you even go into the discussion with your team.
Yes, that makes life more difficult for agile coaches, because there will often be some resistance, and often, we cannot even conclusively prove that something works until it has been tried. But the important word here is “try”. I do not see a problem with introducing a practice explicitly as an experiment, stating right from the start that it is a time-limited experiment while encouraging feedback and making sure that the experiment is properly documented and monitored. That is the agile way for handling this: If we emphasize the importance of empirical product development, then we also need to practice empirical process development by running our “great” ideas as experiments and not as decrees that are not open for discussion.
Everything we do should have a purpose. I.e. by using a particular practice, something in our work must get simpler or faster.
“XY is in the Scrum Guide” only means that there seem to be other teams/organisations where the practice has solved some problem.
What works for Team A, does not have to work for Team B.
Maybe a team doesn’t even have the underlying problem.
But of course it is easier to follow any best practices, patterns or blueprints
than to deal with one’s own context and suitable solutions.
This pattern is not only found with agile coaches, but also with developers (Microservices and SPAs everywhere)
and probably in all other disciplines.
LikeLiked by 1 person