Resource Management in Agile Projects

Agile projects are known to address the problems of rapid change. These may be changes in market forces, system requirements or implementation technology. One of the change, that does not gel well with Agile projects, is the frequent change of people working on the project. In organizations adopting Agile, this is a common challenge when they want to allocate people among projects. Roland Ceullar discussed a few ways of doing effective resource management.

According to Roland,

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?"

Roland mentioned that there are 2 fundamental problems in the question above.

1. An assumption that we need to move people around to staff projects.
2. Number of simultaneous projects.

He added that people cannot be considered as individual pieces who can be moved around at will. When people are working in teams, they go through the maturity cycle of forming, storming, norming and performing. This takes time. Once the team is performing well, it is usually bad to disturb a high performing team. The idea should be to keep the high performing team intact as long as possible. So, instead of assigning people to projects, it would be better to assign projects to high performing teams based on their capacity and skills. This however, would be different for specialists who would still have to move across projects given their special skills.

A related problem highlighted by Joe Ocampo is the matrix allocation of people. This boils down to percentage allocation of a person across projects. Hence, as an example

Developer UberBob – Is assigned to

• Project A @ 25% of his time
• Project B @ 65% of his time
• Project C @ 10% of his time

According to Joe, he has seen this matrix model work for large RUP based projects but this does not work well in Agile projects. In Agile projects it disrupts the team dynamics, communication and hence the velocity.

By fixing the resources on a given project and dedicating them throughout, you gain momentum and predictability of effort. Matrix models disrupt communication continuity as well as iteration velocity. As you mix and match resource from project to project every week, you might as well throw whatever velocity you have been tracking out the window as the team dynamics have been disrupted. If you simply perform a one for one swap of personnel you cannot expect output not to be disrupted.

For managing large number of projects in an organization, Roland suggested a slow down approach. According to him, an organization should queue up the projects for the team instead of having the team work on multiple projects simultaneously. Given the market and business dynamics this might be difficult to achieve but it helps in the projects getting better prioritized and the desired focus. This way teams would be able to achieve throughput and delivery on selected projects instead of working on multiple projects and focusing on none.

Thus the implicit message is to focus on people. Agile projects would benefit if people are utilized in the best way. Hence, it is in best interest to work projects around teams rather than people across projects.