I’m currently re-reading some parts of the Agile Coaching book by Rachel Davies, which I already read back in 2013 when I started my career as a technical manager. But now, I’m reading it again intending to improve my coaching skills and revisit some tools and mental models to apply in my role as Group Product Manager.
One of the tools I’ve stumbled upon was the PrOpER Coaching cycle as a mental model to decide where to start the coaching journey before just jumping in. In the figure below I’ve tried to illustrate each step of the process:
Up until this point, it might remind you the well-known PDCA or Deming cycle management method. What resonated with me and, IMHO, made the difference was reading a list of considerations when trying to come up with options to tackle the problem:
- Surface the problem: Make the problem visible to the team.
- Socialize the problem: Talk with the team about the problem.
- Wait and see: Leave this problem; if it gets worse, the team will probably notice.
- Go sideways: Sell the problem to someone else inside or outside the team.
- Root cause analysis: Look for the root cause of the problem.
- Educate the team: Provide the team with more information so they see a solution.
- Put them in charge: Hand over responsibility to the team or a team member.
Let’s see an example in a fictional situation any Product Owner might live in her/his daily basis:
Imagine we’re going to start the delivery phase of a new project. We already gathered the whole product development team and created a User Story Map with 3 epics (let’s call them epic A, B and C), each of them with the user stories estimated in story points. The team is ready to start the sprint planning and they decide to start developing all three epics in parallel, so each developer can focus on one epic without dependencies between them. However, the epic A is the one with more story points and a tight delivery deadline and it might be a risk not focusing all the development efforts on it.
Well, let’s apply some of the different options described above to face that potential problem.
Surfacing and/or socializing the problem
We can use a tool like the Burndown chart to make visible that, based on team’s sprint velocity and the sum of the story points of the epic A, we’re in trouble to reach the deadline. We can socialize it during the sprint planning meeting and agree to change the approach to focus the development efforts first on epic A and, after finishing it, then work in parallel in epics B and C.
Wait and see
Maybe the risk of not meeting the deadline for the epic A is not so high, and it is a better approach to let the team decide the development strategy and work in all three epics at the same time. If the problem gets worse, the team itself may notice it after a couple of sprints and discuss it during one of the sprint retrospectives, agreeing to dedicate all the efforts to epic A to complete it.
Go sideways
We can share our concerns about the development strategy with the Scrum Master or the Team Lead, with the aim that she agrees and take action on the problem.
Root cause analysis
Probably, there’s a reason behind team’s decision on working all three epics in parallel and we do not know it until we go deeper into it. Maybe the development needed to be done in the epic A needs some knowledge on a programming language that only one of the developers of the team has. So, is there any action that can be done to increase the workforce on it? Can we “invest” the time of one of the other developers during the next sprint so she ramps up the learning curve of the new programming language? Can we ask for some help from other teams within the company? There’s plenty of techniques to do root cause analysis such as the Five whys or the Fishbone diagram.
Educate the team
We can share with the team an article about the importance of focus in the Scrum framework or ask a teammate from another team that already has tackled this same problem before to share her experience.
Put them in charge
We can also simply communicate clearly to the team the timing constraint that epic A must be ready in the production environment before the date XX/YY/ZZZZ. So, they own the decision on how to approach the development and the responsibility of meeting the deadline.
Final thoughts
Which of the options is better? It depends. It depends on the maturity of the product development team, on the risk the project had, on the environment and culture we’re surrounded by, etc. As usual, the PrOpER cycle it’s not a silver bullet, but just another tool in our toolbox to face the challenges we have on our daily basis. It should help us reflect on how to tackle a given problem or help our reports to take action on it to succeed.
References and links
- Coach photo by Nguyen Thu Hoai on Unsplash
- Burndown image from Agile In a Nutshell+
- Fishbone diagram image from Wikipedia
