Giving PMs a view of developer resource

Question

I run a dev team of 8. We have a few PMs here and they often ask about getting a good view of what free developer resource we have.

Other parts of the business have a shared outlook calendar but for developers I feel this comes down to micro-managing. There's always work to do, but its a question of priorities. I don't want PMs questioning the fact that someone is refactoring the build or holding a code review; suggesting that this work should be superseded by some project work.

We use trello for assigning people to support tickets etc, but this doesn't give a feel of how well we can resource multi-week/month projects.

Anyone know of anything that works well?

Answer 1

Your Capacity Planning and Prioritization Processes Need Re-Engineering

You appear to be attempting to solve the wrong problem by treating this as an individual-availability issue. This is most likely because you have a weirdly-matrixed organization that isn't based around project teams or team capacity planning, but apparently based on the notoriously unsuccessful "Is Joe busy right now?" methodology.

Your team of eight should have a variable but generally predictable capacity. In Scrum, this is your velocity range over some trailing historical period. Whether or not you follow Scrum, this sort of historical estimate of future capacity is often your most accurate guide to determining whether a team may have capacity for additional work.

In addition, each project team should not be expected to context-switch without a visible and costly penalty to productivity. Your organization is clearly missing both a Product Owner for each project and a scaled framework that can prioritize work across multiple projects. As a result, everyone treats their personal priorities as the priorities, and when everything is a "top priority" then nothing gets done.

Your organizational process clearly needs work. Consider Scrum, Kanban, and the available scaled frameworks like SAFe or a Scrum-of-Scrums. There's no silver bullet, but almost any formal framework will be better than what the organization is doing now.

Answer 2

I have been in sort of a similar situation before we went full Scrum with actual planning with the teams and Product Owners to define the sprint backlog. What we were doing to mitigate the constant flow of requests to the development team (20 devs, 7 QA) was the following:

• had a good idea of what the dev team capacity is, depending on historical data, vacation days, etc (it was an Excel sheet, not proud to say but did the job).
• PMs, Engineering and Customer Support all prepared a list of highest priority tickets for them
• the dev team estimated all the tickets in that list
• depending on capacity, priority and an allocated time of 60% for features, 20% for tech tasks, incl refactoring, 10% bugs from CS and 10% was for admin stuff.
• Sprints were being planned based on the priority and ratio above.

This is a very crude way (and a bit slow) again not including dev negotiations with PMs on slimming down features when possible, and all that beautiful Scrum stuff, but it might help in-between. All that we tried to do beforehand with the PMs and the team leads only.

If possible, I'd really advise going full Scrum, if you have a good PO candidate and just starting from scratch. It takes a while to get the hand of the scrum events and proper planning, but it does really pay off.