You are an Agile coach, a new recruit in the organization – a Global In-house Center (“captive” software arm) of a major financial services organization. Prior to this job, you have been a Scrum Master and a coach for over five years in a fin-tech product organization and before that a Project Manager in the same organization for many years. In the current job, you are taking over from another coach (Payal Raman) who is leaving the organization. Payal is responsible for your on-boarding.
You have gone through stage 1 of on-boarding – observing the current coach, Payal in action. You appreciate her work and value to the team but, in some situations, you feel that your approach and coaching style would be very different from hers.
Now in stage 2 of the on-boarding, you are the primary coach and Payal is taking a back seat, observing and providing you feedback. One recent feedback from her is that you are too much of a problem solver for the team since you have such a deep knowledge of fin-tech. Payal says that you should stop doing that and have the team think for themselves and resolve problems. You recognize the validity of Payal’s feedback and want to act on it. How would you go about it?
Suggested solution:
Although, you seem to have accepted the validity of Payal’s feedback, perhaps the first step is to introspect on it. Maybe your long stint in the earlier fin-tech organization has conditioned your coaching style to be mostly a “problem-solver”. Have you really stopped being “Project Manager”?
Next, you need to be convinced about the reasons for Payal’s feedback – that your problem-solving assistance is not good for the team’s growth and self-organization.
After reflecting as above, you can also do the following:
- Your self-awareness of your problem-solving tendency may need some initial prodding from time to time; for that, you can take Payal’s help; for example, every time Payal sees you problem-solving in a team meeting, she can smooth her hair sending a signal to you to desist!
- Pick out the situations where you were offering solutions to problems; try and stay away from such situations like team meetings on user experience, feature design, competing products etc.
- If individual team members come to you and ask for help with product functionality, check yourself before saying anything; create / use that space between stimulus and response! Direct the team member back to the team and the Product Owner; ask powerful questions to make the team member think; persistent feature-related problems should be a topic for retrospectives
- Another proven coaching approach to problems is to examine which underlying Scrum value or event needs to be strengthened- once that is done (the underlying cause), the surface-level problem should get addressed. For example, if stakeholder involvement in sprint reviews is the problem, then it may well be that the underlying cause is the team missing out on the real intent of the review (“show and tell”); they may be, say, presenting too much detail of the “How” of features resulting in stakeholders switching off during sprint reviews. So, just reinforcing the team’s handling of the review should fix it and improve stakeholder engagement
- Remember, there is a balance you need to strike; you want to help the team but not make them unduly dependent on you; you are the team’s Agile coach, not their fin-tech consultant!
