What are the 3 things that generally trip you up as an Agile coach?
This is an interesting one. There are generally a lot of things that trip you up as an Agile coach so I can only speak to the things that I find hard.
Using language confidently but incorrectly.
I find it super interesting when people use language confidently, yet incorrectly.
I’ve spent a lot of time in the Agile world and you collect a number of different meanings for the same phrase.
MVP is a popular one. It used to have a single meaning but over the years, it has expanded to represent a whole range of things. It’s a phrase I hear a lot.
Now, interestingly, although I teach people not to do this in my coaching and teaching, I tend to assume that we all mean the same thing when we use a particular phrase. Especially amongst industry professionals and experts.
It stands to reason that given our expertise and experience, we would all KNOW what the phrase meant and as such, I sometimes tend to assume that.
Sometimes, we will agree on what a specific phrase means in a meeting, and I assume that this definition is going to carry on regardless of how long we are working on the product or service.
It seems safe to assume that we all know what a phrase means because we have already agreed on it’s definition, but this seldom happens. People will expand on that as the coaching engagement moves along and down the line, the phrase means something very different to what we all initially agreed that it means.
This trips me up.
It took me a while to understand that although my full-time job is the team environment and product development environment, the people who agreed to the definition of the phrase work somewhere else in the organization.
They spent an hour in a meeting, a few months ago, and don’t have the same daily engagement with the team and product environment as I do. They forgot or they didn’t fully understand, or things just happened to change over time.
As an agile coach, I need to keep reminding myself that stakeholders have a day job. They aren’t as engaged or integrated into the team environment as I am and often definitions will change for them based on the conversations they are having with other people, coaches, and teams.
Goals aren’t priorities.
This is an interesting one and leads from the first lesson.
Initial conversations with stakeholders, team members and other individuals across the organization don’t mean that what we decide to pursue is a priority for everyone.
When you are deeply immersed in the product development environment, you assume that the goals are incredibly important to everyone and sometimes forget that people have different roles and responsibilities within the organisation.
Because they aren’t deeply immersed in that product environment, they have competing priorities and report into senior leadership and executive teams across a range of metrics and responsibilities.
Whilst they will agree that our team’s goal is important, it isn’t necessarily a priority in their world.
I’ve had to learn that the client and product stakeholders have a life beyond what I am there to do and achieve. They have a myriad of responsibilities and competing priorities that don’t include my work or sphere of expertise at all.
I am there, as an Agile coach, to help them achieve a specific goal that forms a part of their role. It isn’t the beginning and end of their responsibilities; it forms a small part of it.
It is something that trips me up when I think we are all aligned with goals and priorities only to discover that I form a small part of someone’s bigger picture and responsibilities.
It goes deeper when you understand that Agile is not the answer to everything. It is a great answer to a specific problem, but entire organizations don’t run on Agile. There are control and command elements of execution, logistics and administration that don’t require Agile at all.
Our teams and the work they do are small cogs in a much greater machine.
Our organization, Agile Centre, aims to support individuals within the company in living the agile values and principles. We also aim to support them in living our own brand’s values and principles.
Because of that, I forget that many people in organizations don’t even know what agile values and principles are. They are forging ahead with traditional management and project management frameworks that don’t include values or principles at all.
It is as foreign to them as a different language and it helps when you remember that in your touchpoints and engagements with other people, outside of the team environment, within the organization.
Those are the two things that generally trip me up the most as an agile coach, I would be super interested to hear what trips you up as an agile coach or scrum master in your organisation.
If you are interested in becoming an agile coach and value mentored, coach-driven skills development in your journey to mastery, visit our Growing Agile Coaches page.
If you like the idea of becoming a scrum master and want to achieve internationally recognised and certified accreditation as a scrum master, visit our Certified Scrum Master (CSM) course page.
If you are already a scrum master and want to upskill to a more advanced level of knowledge and agile coaching capability, visit our Advanced Certified Scrum Master (A-CSM) course page.
If you have several years’ experience as a scrum master and want to validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master (CSP-SM) course page.
#agile #agilecoach #agilecoaching #agileprojectmanagement #agileproductdevelopment #agility #businessagility #scrum #scrummaster #scrumtraining #scrumcertification #scrumalliance #agilecentre #johnmcfadyen #coach #coaching #certifiedscrummaster