How Not to Do Resource Management

Every now and then, we will get the interesting question of how to do "resource management" in an enterprise that is adopting Agile. "How can I allocate people 100% to a single team for so long when we have so many projects going on?"   I like to reply that this is actually the wrong question.  Instead of answering the question of how to do resource management, we like to say that the right question is "How can I not do resource management?"  How can I avoid it altogether or at least greatly reduce it?

There are 2 problems in the question above.   The first is the assumption that we need to move people around to staff projects.  The second is related to the number of simultaneous projects.

Moving People Around

There is a tendency to think of projects as the primary unit of organization.   In this view, the project is static and we move people and resources to the project in order to staff it.  When the project is finished, we return the people and resources to the central pool and make them available for the next project.   There are several issues here mostly related to the pe

ople side of things.   Treating people as individual pieces that can be moved around like pieces on a chessboard does not go a long way towards creating high performance teams.  You will recall that teams go through a life cycle of maturity:  forming, storming, norming, performing, and all of that, and this maturation process takes time.  By the time the team is really performing, usually after quite a few months, the project begins to wind down and we break the team up and send staff off to other projects where they have to start the process all over again.  As soon as we get a high performing team we break it up!

In the Agile world, it is common to think of the team as the central unit of organization and we move projects to the team.   In this model, teams go through the maturation process but once they achieve a high performing state, we keep them working together for as long as possible. The team members know each other well, they know their strengths and weaknes

ses, they have learned how to communicate and collaborate with one another and they have hopefully worked out their major differences.  Why would you want to break that up?  Instead, look at the projects that are in the queue and assign the project to the team that is in the best position to deliver from a capacity and skills perspective.

Specialists

Some projects demand the use of specialists who are in limited supply.  In those cases, you may need to share specialists across many teams and the teams will need to adjust their Agile schedules around the availability of the specialists.   Moving only the specialists around is a lot easier than shuffling everyone.  And oh, by the way, if you don't have enough specialists to serve all of the projects, then you have an obvious bottleneck that needs to be addressed.

Too Many Projects

Finally, the biggest problem in most organizations is too many projects and too little focus. Just like having too many cars on the highway, having too many projects in flight is a guarantee for SLOW DELIVERY.  There is plenty of inventory management and queueing theory to support this and we all know it intuitively.   Most IT organizations have a lot of projects going on, hence a lot of spending going on, but not a lot of delivery happening.  Each project (or car) is inching slowly along, fighting for attention and limited resources.  The solution of course is take some cars off of the highway so that the remaining cars can fly!  But that requires the political strength to say "I'm sorry but we are fully allocated and we cannot support your project right now.  We will queue it up for the next available team."  Easy to say, harder to do. This takes strong, decisive management to truly manage demand against capacity in order to keep from overloading the system.  Agile can help however.   Since Agile does require that teams spend a significant amount of time together, it is difficult for them to support many simultaneous projects.  Agile teams are better able to focus and get the project done quickly.   By moving towards Agile on a large scale in your organization, projects will have to be better prioritized and some will have to go into the queue while others get the focus they deserve.  And this is a great step towards achieving throughput and delivery instead of high-spend and never-ending projects.