Robert C. Martin - himself one of the godfathers of the Agile methodology - has coined the term of “code smells”: Code that has certain characteristics that tell you you’re about to get into deep trouble. I propose the following agile smells:

  1. Your Agile Coaches start to micromanage their Jira project or the instance at whole. They get overly involved in Custom Fields, and Description Templates, and which fields need to be mandatory, in the naming of individual fields, they start elaborate discussions about the status category their statuses are in. This is a sign that they set the wrong focus and/or have free capacity - and likely that their teams are underserved.

  2. Teams complain that the coaches are more often in meetings with other agile coaches than they are in the team. The number one job of a Scrum practicioner is to support the team. If you notice that this doesn’t happen - or worse, if your Agile Coach is mostly absent (or absent-minded), things need to be set right.

  3. Your corporation is setting up a training capability to train new Agile Coaches. This sounds like a good idea at first, but what will happen 9 out of 10 times is that junior people will get a very narrow view on what the job of a Scrum practicioner is, and that view will be coloured by the percieved needs of the management layer - not the development teams. The newly-minted “Agile Coaches” will be essentially worthless to them, and to the industry as a whole, while they will always fall short of the ever-changing desires of management.

  4. Your organization decides to change naming for political reasons (e.g.: They decide to rename “Scrum Masters” to “Agile Coaches”) This makes communication inside and outside of the organization overly complicated and leads to general weirdness (and even mishirings). Usually, such an initiative comes out of a committee after one individual member, often a proponent of a different methodology, raises their concerns and is being taken too seriously.

  5. Agile Coaches talk about new tools a lot. There’s always that one plugin they need - or that extra methodology. If they need to validate their approach, they might want to have some formalized agile health questionaire filled out by the team every other month. If you have a bunch of them, they may start long and convoluted evaluation processes. This is an obvious violation of the ‘Individuals and interactions over processes and tools’ rule.

  6. … or about KPIs and reports. This is a sign of an Agile Coach who is abused by management to be a controller, and/or a control freak. When your Agile Coach tries to project timelines for future sprints based on vacation calendars, sickness quotas and team velocity in elaborate Excel files, or if he spends more time creating powerpoint slidedecks than he spends supporting the team, step in.

  7. Your Jira Administrator has to teach them about the contents of the Agile Manifesto. In the best case, they are incompetent or did not care. In the worst case, they have arranged themselves to deliver subpar work based on pressure they received from outside sources, e.g. management.