I received this interesting email from a colleague (who allowed me to share it) a few days back.
“I currently lead a project on how to increase our resource fluidity so that we can effectively assign sufficient manpower to where it matters the most, e.g. working on the highest priority items on the backlog. We acknowledge the need for deeply specialized teams in certain areas and that drastic competence shifts are unrealistic, so the change project aims at finding out how many scrum teams do we need to make more fluid? What competences should these teams have, if they are to be deployed on a wider range of tasks? We also need to address change resistance such as designers or managers being protective of their work domain.
I wonder if you have any advice on how to increase resource fluidity and thereafter managing it.”
— Dr. Mikkel Mørup, Nokia Mobile Phones, Experience Portfolio Management
The email also reminded me of a visual on the same topic that I saw recently as well, which went something as follows:
Even if we have driven the excess WIP out of the system, even if we can match capacity to backlog, even if we have shorter queues, even if we can build working software in a short time box, we still have to rapidly adjust resources to match the current backlog; that’s a big part of what makes us agile after all. But of course, it never really matches. So we constantly struggle to make the best of the situation, and yet who wants to be the epic owner (or project manager) for Epics (epics 7&8 above) or a team member for Team 4 or 5? A number of awkward conversations and suboptimal economic solutions are likely to develop.
To address this problem generally, we need two things:
1) Feature teams, which have the ability to work across the domains of interest (See feature teams/component teams category)
2) Individuals with “T Skills”, i.e. people who are deep in one area and broad in many. (See Reinertsen: Principles of Product Development Flow, W12).
As agile as we hope to be however, this is a journey often measured in years, not weeks or months, and it is sometimes met with resistance from the enterprise, as Mikkel notes above. Resistance can come from:
– individuals who are highly specialized experts, and who may even see their knowledge of a domain and specialty as a form of job security
– managers who control resources associated with a domain and who can be reluctant to share their resources (and implied base of power)
– Individuals or managers who may have lost their technical thirst for “life long learning” and are comfortable in their existing skills and knowledge
– Logistics and infrastructure (CI and build environments, branching structures, etc) that make it difficult to share code bases across teams
I’m posting this as I would like to hear some other opinions on the topic. As a kickstart, however, my initial response to Mikkel went something as follows:
1) Make the objective clear. It is product development economics that drive us to this particular change vector, and in the end economics wins (or loses) the game for every enterprise. Make the business case based on economics of agility and flow.
2) Make the value system clear. We value feature teams and T skills the most highly (yes, we value component teams too; but even there T skills are an asset). Embed the value system in the performance review/appraisal system to eliminate ambiguity about our expectations for individual career growth and advancement.
3) Adopt XP like practices and values (simplicity, pair programming, collective ownership, single code line, etc.). Hire people with experience in these areas.
4) Attack the infrastructure unremittingly. The technical blocks must be eliminated or the rest of the change program will far less effective.
For you other enterprise agilists out there, do you have thoughts and experiences that you can share?