'Cross-functional' teams misaligned with their portfolio of work?
Very keen to get any input into what I suspect will be fairly common issue across large organisations, where scrum teams typically execute against a large and varied (not to mention ever changing) portfolio of work.
For context, you have a team of five with a blend of overlapping skills, although each team member (not usually) comes from a quite specific discipline - x 2 FED, x 1 BED, x 1 SDET/Tester, x 1 Designer.
The portfolio of work in which they execute against can vary in terms of the product/workstream being worked. Therefore, the skills blend can vary from a design/front end heavy piece of work centered mainly around brochureware, to a back end piece of work with a large number of services to build and call.
Due to the variation in this portfolio, it makes is very difficult to ensure adequate utilization across the team on a consistent basis. Slack time is included, as is pairing and peer review, however there is simply not enough work to be done in line with the individual skillsets.
My question is - how can this best be tackled?
I am witnessing some unrest in the team right now due to this imbalance, and this is not something that is likely to be resolved with people-switching or changing the portfolio. I also need to mention that 3 of the 5 are based off-shore, meaning we also compete with timezone difference, cultural consideration and preferences etc.
Any input is welcome.
It is very difficult for a distributed team (in multiple locations) to execute Scrum well. Technology to aid and improve communication and collaboration can help, but you are simply experiencing some of the pain (and unrest) present in distributed teams practicing Scrum.
One item that stood out in your post however was the emphasis on resource utilization. This is actually a wasteful practice in Lean terms. The focus needs to be on the work and the value the team is delivering to the business, regardless of who is contributing or is busy. A 5-person team firing on all cylinders may be a good thing, but there is no guarantee that their optimization is translating into business value.
In the end, the customer doesn't care that a 5-member team was fully utilized. The customer cares about the functionality requested and represented in the work portfolio.
> Due to the variation in this portfolio, it makes is very difficult to ensure
> adequate utilization across the team on a consistent basis. Slack time
> is included, as is pairing and peer review, however there is simply not
> enough work to be done in line with the individual skillsets.
In Scrum no work whatsoever is done in line with individual skillsets. The role is Development Team, not Developer. Moreover, there are no de-facto subroles, even if they are paraded as "skillsets". Hence utilization is seen the other way around...people go to where the work is, whatever it is. The team genuinely performs as a role.
In Scrum, collaboration does not mean the efficient hand-over of work between de-facto subroles, however lean that hand-over may be. It means no subroles at all, and irrespective of whether they are co-located or distributed. If the Development Team is unable to collaborate in the said manner, then that is the problem to be solved, and it may well require deep change at an organizational level.