Coaching advice for Scrum Masters (Part 2): The many Hats to wear as a Coach!

A Coaching Scrum Master wears many hats – takes on many roles – to help the Scrum Team find their way towards incremental progress upwards.

The focus should stay on the Scrum Team and how to help them better understand their own problems, establish realistic and effective action items to resolve them and stay on the path until they are dealt with.

A Coaching Scrum Master triggers creativity and intellect of the Scrum Team member through:

  1. Establish a “Safe” environment for your Scrum Team (Where they can create ideas and feel safe and confident in sharing them, free from an frowns, smirks or even retaliation).
  2. Maintain your Neutral stance as a Coach at all times (even if they are contradicting the obvious or falling head forward into a pit; You are to get them to see and understand what is misaligned, and then get them to think further into how to fix that, so it is okay to be wrong when they start the conversation … just fine!)
  3. Awaken their creative side by asking them the right questions.
  4. Actively Listen to what they respond (be present, show it!).
  5. Watch carefully for the mix of verbal response and their body language (See if they are aligned or conflicting).
  6. Be generous in giving them your helpful feedback in further supporting their creative instance towards their problems (be clear, to the point and as crisp as you can to avoid confusing them.)
  7. Break through their Assumptions and Pre-determinations (They need to keep their mind flexible and untied so it can create new ideas.)
  8. Guide their line of thought toward brainstorming for options they can action into resolutions.
  9. Get those Actions registered and tracked so they won’t get lost in time.

A Coaching Scrum Master should have mastered Agile concepts and values at the core level, and have developed them into a second-nature level of competency into their own mindset.

Every once in a while, even the most experienced Coaches would go through doubtful scenarios where it is not quite clear what they should guide the conversation towards to maintain the needed alignment to the Agile philosophy while responding to the problem identified. In such rough patches, Scrum Master personal strengths in understanding and applying Agile core concepts, will help him / her to push through.

A Coaching Scrum Master may have started with the Scrum Team as early as when the organization is testing the Agile idea from the beginning and the Scrum Team that is put together is essentially a carve-out from people working in other teams under a Waterfall model.

As Change is never easy, the Coaching Scrum Master must have developed people skills that would allow for reaching out to the Scrum Team members to inspire and motivate them to stay open to new ideas and be willing to learn new ways of doing their would and put that into practice.

A Coaching Scrum Master’s primary focus is to help the Scrum Team to raise their performance level and meet (and even eventually exceed) their organizational performance goals. Scrum Team acts as one body, pulling the work they can do in each Sprint, based on their own discretion and accountability and self-organize themselves, and are responsible for their quality of delivery.

This may picture the Performance improvement as a Team goal, which is true to some sense – especially when it comes to what is visible to the outside world – but it is essentially consisted of the aggregate performance of all individuals within the Scrum Team and their quality of self-organization and team work.

To help the Scrum Team to develop their intra-team abilities and invest in raising the quality of their collaboration, the Coaching Scrum Master should also be a strong facilitator to encourage the constructive conversation, and he experienced in leading the collaboration in brainstorming sessions.

A Coaching Scrum Master is a Servant-Leader at the core, and that would need him / her to act and be a role model of adoption and practice of core Agile concepts.

As a Coaching Scrum Master you are needed to also be a Master of one or more of the following competencies:

  1. Technology (That your Scrum Team is using).
  2. Business Context (within which the Product Increments produced by your Scrum Team are serving).
  3. Agile Transformation (to lead the charge in Agile Adoption, Implementation and raising Maturity within your Scrum Team, across multiple Scrum Teams, or even serve as a member of your organizational Agile Center of Excellence as they are transforming the organization).

A Coaching Scrum Master must also be a good facilitator.

Coaching and Facilitating have their similarities and their differences. They both relate to the Process to entice Scrum Team members creativity, brainstorming and goal setting for improvement.

A Coach is facilitating the conversation needed to ignite the curiosity and ideation in the team members. Facilitation would be per each session this activity is happening.

When Facilitating, Scrum Master is focused on the process of the event that is happening with the purpose of having a decision or action items created at the end of it. This is while Coaching is a continuous engagement with the Scrum Team with the purpose of challenging them to think, analyze, find solution and box it into an action. Here the outcome is interlace with the Scrum Team’s Performance.

Can we just Coach the entire time and never share our own insights?

The answer is: Yes and No!

No, as if you are supposed to be JUST A COACH, then you should avoid sharing your insights and knowledge on the matter and just help the Scrum Team to come up with theirs.

But the reality is that 99% of businesses who would hire you as a COACH are actually following a definition of a MENTOR.

So, the answer is also: Yes!

Here is the difference:

As a Coach your focus is on the Process, and doing more of what we want to achieve. It is also more generalized (i.e. it can related to any field of expertise), and it can one-to-one or one-to-many and follows a rather formal relationship between the two sides.

As a Mentor your focus is on the Context of the work and development of skills and capabilities within that context (e.g. making your developers better in their field.) and as a result it is highly specialized and relate to a very specific field (or tight area) of expertise. The relationship is mostly one-to-one and informal in structure.

Now you need to be careful not to confuse your position – even further – with a Teacher!

As a Mentor you are to create Perspective in your apprentice while as a Teacher would focus on knowledge transfer to your pupil (hence Teaching!).

As a Mentor you are raising the abilities of your apprentice while as a Teacher you are building up your pupil’s knowledge level.

Now to make this maze even more complicated (!!!), let’s finish this article with the comparison of Coaching versus Teaching.

As we mentioned before, a Coach is focused on the Process, while a Teacher is focused on the Context (similar to a Mentor).

When Coaching, you are letting the client – Scrum Team in this case – to decide on the topic of the sessions.

As Teacher you decide on the topic you want to teach (usually based on a pre-defined syllabus).

As a Coach you are not necessarily an expert of the Domain in which your client needs your coaching in (and even if you do, you should avoid sharing that with them to ensure your neutrality on the matter).

As a Teacher, your key to success is to be the expert in what you are teaching.

As a Coach you are using a tailored approach, knitted to the needs of your client (Scrum Team) based on would work best for them, while as Teacher you follow a pre-defined course to teach with barely any customization.

And last, but not the least, as a Coach, your interaction with the client would create a unique journey for them as it will incrementally move from one random ideation and solutioning to another until the final resolution is turned into action items. As a Teacher you will provide a flat, blanket journey for all of your pupils, based on a set of rather static checkpoints that would demand static (and predictable) outcome.

We will continue this discussion in our next article.

Cheers!

Arman Kamran (The Agilitizer)