Stable Teams, Multiple Stakeholders
Some organisations struggle with team stability due to having to deal with multiple stakeholders. This is a fairly common situation. Typically, these stakeholders represent completely different departments or “silos” in an organisation, and they often have their own budgets. (This exposes one of the issues with departmental budgets in that they often make a claim on the same scarce Product Development resource. On more than one occasion I’ve seen budgets allocated that add up to more than the total that could possibly be spent – which makes a mockery of the obsession with the efficient allocation of capital.)
The slightly more extreme version of this is when the “stakeholders” come from different organisations (or clients). An extra complication (common for Development shops) is where the team has different client processes to align with or even different code bases and different deployment pipelines to handle.
So, how can we manage this complexity whilst still aiming for stable teams? The objective is to bring the work to the team rather than constantly reforming teams around work, (with all the waste that that entails). We can’t ignore the reality that demand does fluctuate so we need to figure out how best we can handle this.
Here’s how I usually recommend handling a couple of the most obvious complications:
How to handle multiple clients in one team
Most organisations who have this problem are already tracking the individual’s time against specific clients and tickets, so from a billing and tracking costs perspective this is typically already solved. What they haven’t solved is how to handle the one to many relationship between the team and clients.
Firstly, I would recommend configuring the teams so that people who you believe are better at switching quickly between clients are assigned to teams that are more likely to experience this.
As far as allocating and tracking work items within a team, there are a couple of ways to approach this:
A: Ring-fence some proportion of capacity
One way is to allocate some proportion of the team’s capacity (X tickets per week) to be focused on a specific client, while the rest of the team is focused on other clients or internal work. When it comes to allocating and tracking work we can either do this by having two backlogs that the team pull from in priority order, or a single backlog with a mix of client work in priority order. (Using labels or tags, you can often effectively do both of these side by side.)
This model is more suited to products that have already achieved some level of Product Market Fit, with paying customers, for which you are making more incremental improvements (rather than searching for a business model that works).
B: Time-boxed, focus on one thing
In other cases we may prefer for the whole team to focus on one stakeholder/client at a time, for a pre-determined length of time. This would be appropriate where we have the ability to pull demand forward or delay starting some work. This is a more common approach where the team is working on internal products. It is easier to switch focus from one product to another in order to meet a specific deadline.
This can also be a useful model to try and encourage the team to make sure what they are delivering is always a shippable product and/or a meaningful MVP that delivers value. As such, it is better suited to products where the problem domain or the Job to be Done is still unclear. It enables you to pivot the team more easily, amplify what works and quickly cut the tail if a specific focus area turns out to be less valuable than originally thought.
It is possible to also have the team service some mix of the above two options. In choosing one or the other, we should consider the team’s ability and preference for one or the other, as well as our ability to manage the demand from clients or internal stakeholders and how mature the product is.
Three different perspectives
I also find it helpful to consider the problem from three different perspectives:
From a Portfolio/PMO perspective, we should try to minimise this by bringing demand forward in some cases, and holding it back in other cases. Switching from client to client and codebase to codebase is expensive, so you should try to align clients to a team as much as possible.
Having said that, you don’t want to encourage or entrench key-person dependencies. If possible, you want to get to the point where clients and using (and teams are working on) a shared codebase. This means that delivering enhancements benefit all clients. Paid feature requests are then just part of the continuous flow of improvements that you are making. (You may even reflect the adjusted economics in the way you schedule these features.)
From an Account Management perspective, you should avoid “selling” specific individuals or developer time. Software development requires collaboration – it is a “team sport”. Instead, try “selling” some proportion of one (or more) of a team’s capacity. Since you should know the capacity of your teams, you should be able to better understand the output that clients are buying. For cost/estimating purposes it’s relatively easy to translate output to the typical input required (% of team capacity in developer-days, say) with a given degree of confidence.
From a Forecasting perspective, you should be in a better position to forecast when a specific work item on a backlog will make it into production since we will have a more stable predictable flow of work end-to-end. If you need to adjust priorities in order to meet specific deadlines for a client, this becomes a priority decision rather than a scramble for additional resources. (For more detail on why the latter is risky, see Fred Brooks’ Mythical Man Month.)
What have I missed? Any other complications we need to handle? Alternative models? Share in the comments below…
This post goes nicely with this one: Six things you should expect of a modern PMO
And this one: 5 Key Elements of a Digital Transformation
This one too: Fund the Teams, not the Project (Alternative Funding Models)
Hope this helps!