Resource Management in Agile Projects

Posted by Vikas Hazrati on Jun 23, 2009

Sections

Process & Practices

Topics

Adopting Agile ,

Agile ,

Agile in the Enterprise

Tags

Best Practices

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.

 

1. Back to top

   It's People!! People!!!

   by Dave Rooney

   Every "resource" with which I've worked in 21+ years in IT has been a person... at least in the context of "resource" in this article and how managers use the term.
   
   
   
   When I coach teams, I quite literally ban the use of the word resource when referring to a person. It's dehumanizing and leads to the Taylorist view that we're all just cogs in a wheel that can be moved about or replaced without any adverse effects. That thinking has been proven wrong for knowledge workers on multiple occasions - Google for "costs of multitasking" to see for yourself.
   
   
   
   As for the last two paragraphs, this is exactly correct. In my experience, organizations always have an optimistic view of their capacity to do work, neglecting potential bottlenecks such as manual testing and mounting technical debt.
   
   
   
   Dave Rooney
   
   Mayford Technologies

   Reply

2. Back to top

   Re: It's People!! People!!!

   by Vikas Hazrati

   Completely agree with you, it is people. That is the reason that the commentary that you would find in the post except "quotes" is always PEOPLE and not resources.

   Reply

3. Back to top

   Keep teams together?

   by Amr Elssamadisy

   
   The idea should be to keep the high performing team intact as long as possible.
   

   
   
   This is an interesting idea. In the 10 years (man I'm getting old) I've been doing this, I've worked with such a team only once and met another. The first team - the one I worked with was very cliquish and (arguably) did not work well with other (teams).
   
   Furthermore, I've heard conflicting advice stating that the essence of a high performing team is not a set of people who know each other and get along, but a set of people who are focused on a task bigger than all of them such that they are completely dependent on each other.

   Reply

4. Back to top

   Re: It's People!! People!!!

   by Simon Pink

   @Dave Rooney - I couldn't agree more. We are no longer even referred to as individuals (Resources) we are simply 'Resource'. Come on, developers are people too :).

   Reply

5. Back to top

   Re: It's People!! People!!!

   by Barrett Nuzum

   Simon,
   
   
   
   If we're @Resource, does that mean we can be dependency injected?
   
   I don't think I want that to happen to me. :)
   
   
   
   Barrett

   Reply

6. Back to top

   Re: It's People!! People!!!

   by Kurt Christensen

   Cheers to you, sir. It depresses me to no end that large organizations often intentionally use language and processes designed to dehumanize humans and abstract away the actual products being built. Effective groups of people building worthwhile products are... well... people. Building products. Sadly, in most cases the language used is symptomatic of the underlying culture, and not the other way around.

   Reply

7. Back to top

   Unstable Requirement vs. Unstable Team

   by Udayan Banerjee

   I think unstable team will doom any agile project to failure - setandbma.wordpress.com/2009/02/25/unstable-req...

   Reply

• Older >