How to estimate and plan with a distributed, part-time team?

Question

The situation: We are a small, fully-distributed software solutions provider. We serve multiple clients, and given our size that means every team member is on multiple, part-time billable teams. Usually 2 such teams per person, to minimize context switching. Everyone works a total of 30-40hrs a week, varying from week to week per available work and normal challenges. All teams estimate work using story points or hours, but definitions of these vary by client, as does the methodology (Kanban or Scrum, with varying iterations) and tooling (Jira, PT, and V1).

The problem: Taken together, team composition and execution is never consistent enough to support typical velocity or efficiency metrics, in turn making it a challenge to create trustworthy targets for clients (e.g., where we'll land in a backlog by given dates, prospective work estimates). We do our best to maintain team composition for a few months at a time for continuity's sake, but the aspects mentioned above obviously induce hard-to-predict outcomes and probably obscure other concerns.

So, how can we get better, preferably without drastically changing how we do business?

Approaches that have occurred to us so far have important gotchas:

1. We lock down our inputs (e.g., definition of story points), methodology, and tooling and iterate until we get as good as we can with them. The gotcha, as we see it: Client relationship risk, since most already have teams, methodologies, and tooling we coexist with.

2. We come up with per-person, aggregate-able velocity metrics, cross-referenced by the kind of work, team size, etc. as we gain understanding over time. Gotcha: Based on our research this seems speculative and could take forever to lock down.

3. We stabilize our teams to enable more traditional velocity metrics, estimation, and planning techniques. Gotcha: Business development and sustainment risk, since this will reduce our ability to mix and match teams in response to budget changes and new work.

Which of these sound most effective? Or a mix? Any other ideas?

Answer 1

Organizational buy-in

I agree with what @barnaby has suggested. Option 3 is the preferable solution here, however it will only work if there is buy-in at an organisational level. There are a couple ways to avoid the "gotcha's" you mention

Gotcha: Business development and sustainment risk, since this will reduce our ability to mix and match teams in response to budget changes and new work.

Introduce Scrum to your teams. Explain what this entails to external stakeholders and ensure that they respect Scrum and it's principles. Once your team is onboard and understands what Scrum means it is your job to protect the Scrum team.

During Sprints it is your job to ensure there is no disruption to the agreed Sprint Goal. This doesn't mean you can't be Agile however. For example a lot of organisations run 1 or 2 week Sprints. So if something arises outside of your Scrum team that needs to be worked on asap, Scrum can accommodate that. It just needs to be done so in a controlled manner (through Sprint Planning).

Without more specific detail, it is hard to offer advice regarding 'changing budgets'. How often are project budgets changing, and why?

Scrum can only work if the Scrum team is protected and not interrupted. This can be difficult in many organisations that can from more traditional project management styles. Perhaps analogous examples can help win internal skeptics over such as Jeff Bezos approach that "a team should never have more people than what two large pizza's can sustain". However that is more closely related to organisational change than project management.

Answer 2

Option 3 is the one to go for and I will explain how to avoid the 'gotcha'.

We stabilize our teams to enable more traditional velocity metrics, estimation, and planning techniques. Gotcha: Business development and sustainment risk, since this will reduce our ability to mix and match teams in response to budget changes and new work.

Having stable teams does not reduce your flexibility to respond to budget changes and new work. It enhances it because the efficiency of the teams is improved (e.g. they can have a refined process for onboarding priority changes).

Bring the work to the teams rather than forming new teams for specific projects.

If a budget changes, change the priority of the backlog for the teams to reflect it. If new work comes in, determine the priority against other work the team already has on its backlog.

This may mean that a team is working on more than one project at a time. This is not ideal as context switching will reduce their effectiveness. However, you can mitigate this to some extent by:

• Trying to work on projects in work item 'batches', so that the team gets to focus on one thing at a time.
• If using Scrum, allocate sprints to projects

The biggest challenges will be around things like the billing mechanism and the customer perception (e.g. they may want a 'dedicated team'). If you have a good relationship with your clients you can explain to them the benefits of having stable teams and hopefully they will then be willing to compromise in other areas.