BT

Resource Management in Agile Projects

| by Vikas Hazrati Follow 0 Followers on Jun 23, 2009. Estimated reading time: 2 minutes |

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.

 

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

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

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.

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.

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 :).

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

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.

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...

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

7 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT