Why Agile and Traditional Managers Lose Sight of Resource Supply and Demand, and How to Fix It

Your sprint teams plan four weeks ahead. Your project schedules look at the entire horizon with detailed resource assignments out three quarters. Both draw on the same people, but many sprints are run using Excel or other separate tools and lose sight of one shared resource pool that can show the shortfall months before it hits.

Most organizations cannot standardize on a single methodology. Product teams work in sprints where infrastructure, regulatory and customer implementation work follows Traditional Project and Resource Management, with fixed dates and dependencies.

The friction this creates is usually blamed on culture: agile people and Traditional PM people not using the right tools.

Two horizons, one pool of people

• Agile teams plan capacity one sprint at a time. That is by design, and it works well inside the sprint. The team knows its velocity, sizes the work and commits. What it doesn't produce is a forward demand curve. Ask an agile team what capacity it will need in five months, and the honest answer is that the framework doesn't ask that question.
• Traditional PM schedules look across the whole horizon. A resourced schedule says which skills are needed, how many, and in which week, for the next two or three quarters.

Put both against one pool of people with the right tools and demand is clear for the next four weeks via the sprint and is covered at a summary level for the rest of the sprints for the project duration.

Why managers lose sight of supply and demand

When sprints live in a spreadsheet and projects live in a scheduling tool, each manager sees half the picture.

• No shared pool. The sprint spreadsheet lists the team. The project schedule lists its resources. Neither knows what the other has promised the same person.
• Double-counting. A developer sits on a sprint team and on a project schedule, and each manager assumes they have most of that person's time.
• No common unit. One side counts story points per sprint, the other person-hours per week. The two don't add up, so nobody can total demand.
• Late discovery. The clash surfaces when a sprint commitment and a project milestone land in the same two weeks, when it is too late to hire or move a date.

None of this is anyone behaving badly. It is what happens when demand is recorded in places that can't see each other.

What the right tools have to do

Getting a handle on supply and demand takes three things, whichever methodology a team uses.

1. One resource pool. Every person, and every role you plan to hire or contract, lives in one place. Each resource has a start and finish date, so joiners and leavers change supply in the right month.
2. Demand as allocations, in one unit. Sprint teams and projects both record demand as people allocated to work, measured in FTE per month (or hours per week for detail).
3. Supply, Demand and Variance (S-D), by role and month. Negative variance on senior backend in Q3 is a fact both managers can act on, and neither can argue with.

How Timebars Ltd. tools make this work

The three Timebars Ltd. products share one data model, so each team keeps the tool that suits its method while demand lands in the same pool.

Costbars holds the pool. Costbars is the master. One Costbars dataset holds every named person and every generic role, plus a master schedule with one bar per project. The pool is maintained there and nowhere else.

Traditional PM teams schedule in Timebars. In Timebars, the project manager allocates generic roles early ("two integration developers, one tester") and swaps in named people as the work firms up. Every allocation becomes demand in the pool.

Agile teams have two options. Both give the detail-now, summary-later picture from the opening.

• Option 1: run sprints in Agilebars, with a summary bar in Costbars. The team plans and runs each sprint in Agilebars, on its Kanban board with a burndown. Agilebars has no resource allocations, so in Costbars the squad also gets a summary project bar for the project's duration, with allocations by role (for example, six FTE of senior backend and two of QA each month). That bar can be broken down into sprints. Each month, the team lead updates it from velocity and the burndown.
• Option 2: run sprints in Timebars. Each sprint is a bar with the team allocated to it, using traditional resource management and no Kanban board. The current sprint carries named people in detail. Later sprints carry summary allocations by role. Demand flows into the pool with no extra step.

The Supply vs Demand grid shows the result. In Timebars and Costbars, the Supply vs Demand grid sets supply against demand by month or week, in FTE or hours, grouped by project, resource or role. Group by role, and named people and generic roles with the same role add up into one line.

The Enterprise Dashboard shows it across teams. Each team publishes its data to Timebars Cloud. In the Enterprise Dashboard, a Dashboard Source combines Costbars, Timebars and Agilebars data, and the Capacity vs Demand report shows supply and demand by week and role across all of it. Agilebars data adds sprint burndowns, while the squad's demand comes from its summary bar in Costbars.

A worked example

A platform squad runs two-week sprints in Agilebars. Its Costbars summary bar holds six FTE of senior backend developers every month to the end of the year. The organization has eight senior backend developers in the pool.

A regulatory project scheduled in Timebars needs three senior backend developers from March to May. The grid, grouped by role, shows:

Senior backend, FTE	Feb	Mar	Apr	May
Supply	8.0	8.0	8.0	8.0
Demand	6.0	9.0	9.0	9.0
Variance (S-D)	2.0	-1.0	-1.0	-1.0

In January, the shortfall is visible: one senior backend developer short for three months. The managers can contract one developer, move the project start to June, or agree to lend one person from the squad and reduce its sprint commitments. Without one pool, they would have found out in March.

What each manager gets

• Agile team leads: their standing capacity is visible, so project demand can't quietly erode it. A project that needs their developers has to show up in the variance row and ask.
• Traditional project managers: they can see which months have the people before committing to dates.
• Resource managers: "We are one senior backend developer short from March to May" supports a hiring decision. "The teams feel stretched" does not.

The honest limits

• It models capacity, not backlog. Agile teams don't have to estimate stories months out. Their capacity stays stable even when the backlog changes.
• Summary bars need monthly upkeep. With Option 1, someone updates the squad's Costbars bar each month. Teams that won't should use Option 2.
• Seeing a shortfall doesn't fix it. It moves the decision (hire, descope or move the date) to someone with the authority to make it, before the clash instead of after.

Next: turning the pool into dates

A shared pool tells you where you are short. The portfolio manager's next questions are when current work will finish and when the next project can start. When Can the Next Project Start? walks through that monthly routine.