(luKa)

The Agile Coach facilitate the dev team and management to reach the full potential of the organization in software development. Given the time, energy, passion and effort we put in our job, why not to do it alright ?

Improvement requires change. Sooner or later an Agile Coach face obstacles and resistance to change, in his area of influence and outside that area.
When the Agile Coach is sponsored by the management then he could face resistance to change from the dev team. And when the Agile Coach is sponsored by the dev team it could be the other way around.

Ten years ago Agile was new and innovative, unknown to most. Nowadays Agile is mainstream. "Agile" has become an empty buzz-word. Many organizations and teams already went through their Agile adoption. There are also dogmatic agilists and people burned by or uncomfortable with agile.


An Agile Coach when needs to work around resistance and advocate a change nowadays face a new challenge, especialy with organizations/teams that already had their Agile adoption,  because this could not work :

• claiming that Agile is innovative, modern and new and deserve a try: it is more then 10 years old, and some team is already doing Agile so Agile brand cannot be used as a valid excuse/motivation/explanation to push further changes. And this apply also to other names as Kanban, Lean, etc.
  
  
• using rhetoric and success stories that are known in Agile literature: they have already been widely used and abused many times, team members and managers already heard of them, so they don't work as before
  
  
• using as motivation the Agile theory: it has already been used before to justify different things and cannot be used to justify changes in a team that is already went through their Agile adoption and is already "doing Agile"
  

Doesn't matter if the Agile coach is knowledgeable, experienced and can have the sense of all the forces at work and the vision of how the whole should come out and so can have the understanding and the intuition of what is not working and which interventions are required.  The more advanced the tools and models and paradigms used are and the more insightful the intuitions of the Agile Coach are, the more they are hard to understand and explain in a simple and effective and rational way.

Here a relevant quote from Joseph Pelrine:
No matter how insightful and effective the intuitions can be and how counter-intuitive can be Agile, since it's a person-to-person business: incremental improvements and simple understandable rational contextualized explanations are required.


Nowadays an Agile Coach to advocate changes, to work around resistance, to facilitate enduring concrete valuable and tangible improvements, to grow in the organization Agile skills and experience, to transform the cooperation and collaboration between dev team management and marketing, to remove impediments that time to time are confused as values of the organization culture, he needs a deep understanding of the internals of the Agile tools and models and paradigms - and also - knowledge and a more intimate acquaintance with the dev team the management the product and their history (successes failures experiences and lessons learned).

This because the Agile Coach nowadays:

• have to point real problems in the current context: he need to be patient and wait that the problem actually occurs for real, he need to be part of the team and have trust from the team in order to get to know about the problem and the related information that is relevant, he need to make the problem visible to anyone and to reach a common understanding of the dynamics and the consequences of the problem (for the involved people, in that specific team/department/company in that specific moment and for that specific context)
  
  
• must provide a simple model of the current context that explain the changes and the expected outcome: he need to have a good understanding of the context (involved people, team/department/company involved, product, requirements, technology, stakeholders, there in that place at that time in that specific situation) and a good understanding of how and why agile work in order to apply that to the current situation and been able to explain the situation in a comprehensible and rational way that make clear what changes are required and why and what would be the outcomes
  
  
• have to produce visible improvements: changes create discomfort, is normal to face disagreement when changing, change also needs to go through a series of trial and error before reaching the goal. All this can be justified  for an improvement that is effective, visible and perceivable. The coach needs to point to problems that the organization/department/team/people are aware of (good answers first need the right questions) and that are capable to see and understand and value the solution. And the problem must reside in the current system bottleneck (or at least not the behind the current bottleneck) for the effects of the solution to be immediately visible and inspectable. And the solution needs to be sustainable and persistent, say resilient, to contribute to build trust in a long-term relationship.
  

On the other side, dev team and management can benefit of a deeper knowledge of Agile (let's call them simply "modern")  models and tools and paradigms to better understand and direct the organization.


Here some relevant quote from XP Explained, K.Beck: