One (Team) size and structure does not fit all

How does leadership determine how big a team they need (may be organized in multiple scrum / kanban teams) to support a given demand in a portfolio or a program?

This is a very involved answer, and, like most answers related to adopting Agile practices, it depends.

If someone is asking for a simple formula, that will not work and is also not in line with the principles of Agility.

Very broadly, two anti-patterns that are most common are the top-down planning and bottom-up estimation.

Top Down planning:

This involves drawing up a detailed plan – for the portfolio with constituent products or components and timelines, by the senior leaders representing the demand and supply sides. [sales and marketing along with engineering and product management]

Add to that the current commitments as well as any desirable cleanups [including addressing tech debts] and one would have the plate overflowing.

This may result in a high level ‘architecture’ or a block diagram of various things to be done and a ‘magic hat’ may be used usually constrained by the overall budgets.

This will then more easily translate into a number for the team size based on an average ‘employee cost’.

The HR team can then chip in with what are acceptable ratios of managers to members, and, voila! We have the team size.

Bottom up planning:

Here, teams are usually asked to come up with estimates of efforts, dates as well as resource needs. With just a vague articulation of the expectations, teams also may be eager to please management and come up with aggressive [unrealistic?] team sizes and timelines.

One of the related anti patterns that I have seen is that teams that are considered successful, ased on past deliveries, get tagged with more expectations, and, as I saw in one team, was working on 3 versions of the core platform and half a dozen customer specific branches at the same time!

The team was getting stressed to just prioritize the work streams and the testing team was even more under pressure to be able to switch between multiple test environments even within a sprint, just to catch up with the developers.

As you would have got the drift, neither of these approaches is sustainable in the long run – and sometimes could also be impractical.

One rough process that I would suggest is to look at multiple aspects holistically.

These would include not only the aspirations – of what the next version would be or the next new product we want to build, but also the current commitments and challenges in the ways of working.

Focus on the flow and how that can be smoothened and be made more predictable in terms of the lead times.

Start throttling demand to match the capacity or impedance of the current engineering teams.

Set the overall goals and aspirational timelines [as you may have noticed, I have used the term aspirational multiple times in this discussion – and that is intentional – when making big plans, please treat them as aspirational and not deterministic.. more on this, some other time]

Let the teams figure out or propose [experiments related to] how they would like to manage the flow of work.

Use the basic good design principle of high cohesion and loose coupling – teams that are formed – even if not by self selection – by the way, this is something that some companies are experimenting with – can identify common goals that they can all contribute to and have protocols to work with other teams,

In other words, let the work flow to teams and not the other way. I have seen some instances where team members are moved dynamically or periodically from one ‘team’ to another, to handle projected workloads, without realizing that every time such a change in team membership happens, there is an impact on all the team members and not only the persons who are moving, to readjust their ways of working. This is true even when the larger team is stable and most team members know each other personally and professionally.

Another significant dimension to consider is the backlog or workload from past commitments and plans.

Unless the context is for a fresh development, from the scratch, one cannot forget the past – but one needs to, at least selectively – as Prof. Govindarajan recommends in his three box solution.

One pattern I have seen is to visualize this as a hierarchy or priorities.

The highest priority is at the bottom and if something needs to be knocked off, start at the top.

With this visualization, you can see that in dropping or deprioritizing something, you would not affect the stability of your operations.

Of course you would consider other factors such as risk and [business] impact to classify a need under these four buckets.

To summarize the approach:

– Start with your constraints [of time and budget]

– Look at your risk appetite, to experiment with alternative solutions or approaches to implement the solutions

– Set the overall goals, as aspirational expectations

– See if you can throttle the demand [prioritization]

– Let the teams expand this more to come up with how they can best realize this

– Look at the overall architecture patterns

– Look at smoothening the workflows and dependencies across teams

– Consider the first couple of milestones [internal, interim or early adopter releases] as experiments to calibrate your aspirations by revisiting your assumptions

Bonus points:

– The above may appear as idealistic. Factors relating to specific skillsets, workload that would require such specialist skills as well as organizational constraints to onboard or inject new skills in the teams would also come into play

– The practical approach would be to start with a budget [however rough it may be], set interim goals and success criteria and use them to adjust the workload as well as team sizes

– In doing this, do not forget the related investments in terms of tools training and management oversight needs

Sivaguru