How do you know when you need to scale up resource vs seeking to challenge value and prioritisation
We have significant demand across our 4 product teams.
Our POs currently manage the PBIs and we ensure we take items onto sprint backlogs based on current velocity from our learning in previous sprints.
We are however not completing work at a rate to keep up with or match the rate our demand is growing.
I think there are two considerations here, one our processes/ways of working are they efficient (e.g. currently we have little automated testing)? Probably not an this is something we are looking to address, but this takes capacity which is hard sell given the external demand, even though it would likely have long term benefit. The other is could we expand our teams to increase capacity (knowing that initially this may impact teams efficiency) for a medium to long term gain.
We are constrained currently by a recruitment freeze, but I am looking to find out what the community would recommend as potential tools to help justify an increase in resource for the team, something tangible rather than anecdotal. Any input would be much appreciated.
Our POs currently manage the PBIs
There's your problem. It isn't enough for Product Owners to manage PBIs. They have to manage the Product Backlog itself.
This includes, for example, taking velocity into account when ordering the Product Backlog so value delivery is optimized. The intelligent and considered throttling of demand might well include discussions with the team about reducing velocity, temporarily, so automation can be enabled and longer term value achieved.
You have specifically asked for
tools to help justify an increase in resource for the team
Can you provide more information around what has led you to increasing resources as a solution?
Depending on your current team sizes, configurations etc. suggestions may actually run counter to your request and include reduction of team size, or use of smaller focused teams or even a scaling framework such as Nexus to help manage dependencies and integrations.
Brooke’s Law: “Adding people to a late software project makes it later”
The team I am currently serving ran into this. Team members were being injected into the team, without the team's input, which actually resulted in us slowing down and delivering less value. Focus was impacted, work fell through the cracks as people thought others had it covered, communications were cumbersome and Events and meetings ran too long. It took some work, but we gained support to streamline the team which has resulted in better focus and more delivery of value. Unfortunately we have many instances in our org of teams adding more people to the problem, only to find things getting worse, and adding more people, and getter worse.
For your 4 Product teams: Is each team focused on its own distinct product? Each with its own Product, Product Owner, Scrum Master and Developers? What are the current team sizes? Is there any sharing of people across Product teams in this scenario? If yes, what are the allocations like and has the cost of context switching and impacts to their focus been considered?
Also what Ian said.
Thanks Ian and Ryan for your comments.
Currently we have increased capacity from external contractors but this resource is finite. They are likely to leave us at the end of the year and not be replaced.
Our Teams are between 4-7 people (4-5 without the externals).
Ryan, your point on focused teams is an interesting one, we work on a platform with many facets, which have been grouped into our Products, some that lend themselves more to a focused product and some that a perhaps a less logical grouping. In an ideal world we would have split the platform into more than 4 products, enabling more focus from the dedicated product team, but looping back to my original point, we are limited by resource. 4xPOs 17xDevs and 1xSM.
The challenge I have, is how do I deomstrate that getting two more SMs for example would be beneficial or if we split "Product X" into Product "X & Y" and bring in another PO, then we will see tangible outcomes in these areas.
My next step was going to be to run an experiment by doing the above split one product in two and see what the outcome is, but fear this may stretch the team and put more pressure on them.
An approach you could consider is illustrating or visualizing the challenges of your current situation.
One SM across 4 teams is a lot of context switching. The impacts of context switching shouldn't be ignored. Some studies show the impact of around 25 minutes per context switch. Even if you reduced this down to 15 mins per, and only considered all of the Scrum Events a SM may support with 4 teams, ~50% of their time could be spent on just Scrum Events (this can vary depending on team maturity), with that alone, 21% of their time could be wasted on context switching alone. This doesn't leave much time for coaching, organizational support, impediment removal support etc. Any additional activity only adds to the context switching waste. A simple spreadsheet can be created to help with calculating cost of context switching and used to illustrate scenarios. This is what I have used in my own organization to help illustrate inefficiencies of shared team members.
I am wondering about splitting your products. There are other ways to narrow focus. You can have one Product, with one Product Owner and more than one Scrum Team working on it. Imagine you are working towards a Product Goal. Each team would focus on a different concrete step towards that goal each Sprint. Each with their own Sprint Goal focus, but still working on the same Product and making progress towards the same Product Goal. If this goes beyond 3 teams you may want to consider leveraging Nexus.
Thoughts?