GROW Practice Instructions
Select one person to be the coach, one person to be the client, and (if there are three of you) one person to be the observer. The observer remains silent during the exercise, taking notes so that they can give the coach feedback at the end of the exercise.
At the end of a scenario, you will rotate roles, so that each person gets to play each role by the end of the exercise.
The client selects a scenario from the list at the bottom of this document, or one from their personal experience.
When everyone is ready, the coach starts things off.
Coach: What would you like to talk about?
Client: Briefly describe the problem.
The coach uses questions to guide the client through the GROW process. Use the following question list for reference:
Coaching Questions For GROW
You will not use all of the questions on the list. Pick ones that feel natural and appropriate to help your client make progress. You may also use open-ended questions that aren’t on the list.
The time box for each phase of GROW is two minutes. Coach, be mindful of the time, and use questions from the list to transition from one phase to the next:
- (G) Goal Setting
- (R) Understanding Current Reality
- (O) Options
- (O) Obstacles
- (W) Way Forward / Will
This process can be iterative, especially options and obstacles. Don’t worry too much if you briefly find yourselves revisiting a previous phase.
Once you have made it to the end, and the client has identified their goal, end the role play and debrief the exercise. In the debrief, the client and observer (if present) each share:
- Two ways the coaching intervention could have been even better
- Two things the coach did well
During this sharing, the coach remains silent, absorbing the feedback. At the end of the feedback, the coach thanks the client and observer for their feedback.
Scenarios
Over-Committing Team
You (the client) are a development team member on a team that always over-commits. Each sprint, they plan to deliver about ten stories. At the end of the sprint, they typically deliver five or six stories. The product owners and stakeholders are clearly upset with the team. Each sprint, the PO and stakeholders put more pressure on the team to commit to even more, so that they can catch up.
Product Owner And The Divided Team
You are a product owner. The development team is asking the PO to split feature stories into coding stories and testing stories, so that the team can get more stories done each sprint. Currently, the programmers say that the testers aren’t getting the testing done fast enough and it’s making the team look bad. They want this to be more visible. The testers say the programmers don’t give them anything to test until very late in the sprint. They want their own testing stories so that they work a full sprint testing the ‘coding stories’ from the previous sprint. You don’t like this idea, as it would take two sprints to get a feature story fully done. Additionally, you are worried that it will further divide an already fractured team.
Manager In The Middle
You are an engineering manager. The organization has adopted Scrum, and the developers that report to you are now split across several Scrum teams. Your boss is still holding you accountable for the deliverables in your annual plan, which was created before the move to Scrum. When you tell your engineers that they have to work on the items you are accountable for, they push back saying that managers can’t tell developers what to do in Scrum. You’ve looked online and found very little about what managers are supposed to do. You are feeling powerless, vulnerable, and stuck.
Frustrated Senior Developer
You are a senior software developer. You are passionate about the craft of software development. Your teammates don’t seem nearly as interested. You constantly are finding anti-patterns in their code: global variables, copy-and-paste code reuse, dead code sections, and so on. You would like to institute coding standards, test-driven development, and pair (or even mob) programming. You don’t think the other developers will be interested. You think the product owner will push back because they’ll see this technical focus as something that will slow the team down, and distract the team from getting features out the door.