1. Resource Pool Model
It is a typical model where all resources in the organization are part of a common resource pool. In this model, product teams do not have fixed resources. Each new release of the product initiates a new resource request. Based on resource availability in the pool, resources are assigned to the project. This may result in changed team for each release . This model creates a consulting syndrome where people only focus on immediate work with no real motivation to think about product vision and long team performance. Also, resource allocation is loosely coupled with skill match for project needs. Pools are normally segregated by expertise e.g. QA, User experience etc. This results in less cross-functional team members. Unsurprisingly, this is the most commonly used model.
2. Split Resource Pool Model
This model is a variation of resource pool model. In this model, team members may not even have one-to-one project allocation. Resources can be assigned to multiple projects at the same time. This introduces another side-effect as people tend to loose efficiency when they multi-task on multiple projects with varying priorities.
3. Agile Resourcing Model
This model is generally driven from the product vision. A dedicated investment is made to develop a cross-functional team with right expertise for the product development. Investment is incremental as product meets revenue or other goals. Key focus is on building core product team with deep product and technology knowledge. This model works well with incremental agile approach.
You can find many other variation of these resourcing models. Main intent of this article is to help you understand efficiency and scalability caused by the resource changes.
TEAM EFFICIENCY METRICS
1. Team Efficiency Quotient (TEQ)
Building a team is a complex process. Enough is written about it already. I just want to stress that there is a cost associated with building a new team. We can't avoid it but we can minimize the impact by selecting team members with appropriate skills and attitude. Each time we make a change - addition or replacement - it brings efficiency of the existing team down for some time. This happens because team helps new people to ramp up knowledge and to get them used to the new environment.
Realistically, how much can a person contribute if he joins project in the last month? In my experience, this person can hardly contribute to the project deliverable, instead he brings down velocity of other team members temporarily. We can simply quantify team efficiency as:
TEQ = Average time spent by team on the project
e.g. You utilized 10 resources for 4 months project.
- 4 resources joined in the beginning
- 4 resources joined after 2 months (50% project left)
- 2 resources joined in the last month of the project (25% project left)
TEQ = ( 4*1 + 4*0.5 + 2*0.25)/ 10 = 0.65 = 65%
In Split Resource Pool Model, this efficiency goes down even further because people loose efficiency because of multi-tasking.
2. Team Scalability Quotient (TSQ)
Once you build a good team, it is easier to scale it as product needs grow. If you constantly rotate team members than scalability of the team reduces as continuity is constantly broken between releases. The following TSQ metrics is mainly targeted to gauge impact of team changes between releases. There are many other factors contribute to team scalability but those are out-of-scope for this article.
TSQ = % of the team retained from the previous release
In TEQ example, we built a team of 10 people. Team had low efficiency because of ramp-up but we can assume that team is ready to take on next version of the product. Team gained good product and technology knowledge. They finally got synergy as a team. Let's say if you replace half of the team members with newer members to work on the new product release then it reduces team scalability by 50%.
In a nutshell, portfolio and resource managers should carefully consider how resource allocation impacts team efficiency and scalability. Please think, if you are building teams or consultants. If you are really keen in making agile successful then invest more in developing cross-functional teams. An agile team gains velocity as team dynamics improves. If you keep disrupting teams, then don't expect your agile teams to gain velocity. Choice is yours!