When we move to interchangeable feature teams working from a single Product Backlog, multi‑functional development stops being a “nice to have” and becomes a condition for survival. The load on different specializations constantly shifts: today there is more analysis, tomorrow development, the day after tomorrow testing, and a team of narrow specialists inevitably runs into overload for some and idle time for others.
Short Sprints and small Product Backlog items reduce WIP and decrease Time‑to‑Market / Lead Time, but at the same time increase the pressure on people: gaps in knowledge become visible, and stepping outside one’s primary specialty turns into a daily norm. If the organizational system does not support multi‑functional development, any demand to “learn and help each other” triggers exactly the resistance Peter Senge wrote about: the harder you push on the system, the harder it pushes back.
So the key question is: which elements of the organizational system trigger this resistance and block multi‑functional development and Scrum / LeSS adoption? Below are the main obstacles and their antidotes, mapped onto Galbraith’s Star Model.
Why “Learn and Help Each Other” Doesn’t Work
Structure
Obstacle: functional line management
When people in the same team have different functional managers — for testing, backend, design, and so on — multi‑functional development stalls. This setup strengthens silos and narrow identities (“we are testers”, “we are programmers”), while functional managers reinforce specialization and throw in work that bypasses the team’s Sprint priorities.
Antidote: shared cross‑functional line manager
Cross‑functional teams have a shared line manager who is responsible for developing teams’ capabilities, not running a “department”. They focus on multi‑functional learning, team cross‑functionality, adaptability and speed of the product group, while people learn from each other, from other teams, via communities of practice and other informal coordination techniques.
Processes
Obstacle: pressure and high utilization
With high WIP and constant overload, people live in “hamster wheel” mode and perceive any learning as mockery. In such an environment they have neither the time nor the mental capacity to develop new skills and help colleagues, and burnout and cynicism become the norm.
Antidote: slack time for growth and adaptation
Slack Time is deliberately built into the system: hackathons, learning days, discovery Sprints, internal meetups and office hours with seniors. A portion of the team’s Sprint capacity is reserved for development, so learning and mutual help become a legitimate part of the job rather than “extra load in the evenings”.
Rewards and measurement
Obstacle: “efficiency” metrics
Metrics like individual Velocity, number of tasks per person, 90–100% utilization and personal on‑time delivery KPIs push people towards local optimization. In such a system it is more profitable to “fill up” your personal plan than to help the team, take unpopular work or step outside your familiar specialization.
Antidote: adaptability metrics
The focus shifts to the adaptability of the product group: product‑level WIP, Lead Time from idea to shippable increment, and the share of backlog items that most teams can pick up. These metrics reward skill broadening, dependency reduction and mutual help, because that is what speeds up product pivots rather than the “speed” of individual people.
Obstacle: job‑based pay
When salary is tightly tied to job title and position, it is more beneficial for people to cling to a narrow role than to broaden their skills. In such a system, multi‑functional development looks risky: you do more, but formally stay in the same “box” and pay band.
Antidote: skill‑based pay
Compensation is tied to the breadth and depth of skills, not to the job title. Every new capability — a new type of task, domain or technology — increases contribution and brings a clear pay growth, making multi‑functional learning both useful for the team and attractive for the individual.
Obstacle: narrow grading
A large number of narrow grades pushes people into micro‑boxes by level and role, making any move towards broader responsibility harder. People quickly hit the ceiling of their grade, and multi‑functional development starts to conflict with the formal model.
Antidote: broad grading
Instead of 15–20 narrow levels, introduce 3–4 broadly defined grades with wide pay bands. A grade describes a range of contribution and maturity within which a person can safely expand their skills and types of work while staying “valid” for the compensation system.
Obstacle: individual rewards
Individual bonuses and incentives encourage competition inside the team and a “everyone for themselves” game. Helping others and taking on hard but product‑critical work becomes unprofitable, because it does not translate into a personal bonus and can even hurt it.
Antidote: rewards for product group outcomes
Bonuses are tied to the outcomes of the whole product group, not to individual heroics. This shifts attention from personal metrics to shared results and makes knowledge sharing, mutual help and multi‑functional development the natural way to grow the overall “pie”.
People and development
Obstacle: traditional performance evaluation
Infrequent annual or semi‑annual performance reviews lock people into familiar roles and evaluate them based on past tasks. Experiments with new types of work and skills are seen as a risk of “getting a lower rating”, so people rationally choose a safe narrow specialization.
Antidote: frequent informal feedback
Regular informal feedback (one‑on‑ones, peer feedback, lightweight 360s) supports small steps towards multi‑functionality. The team can quickly try new tasks, get support and adjust course without waiting for the “judgement day” of the annual review.
Obstacle: top‑down development plans
When development plans are created by HR or managers and handed down as a list of courses, multi‑functional learning turns into obligatory box‑ticking. People “attend trainings” without connecting them to real cross‑functional gaps and product goals.
Antidote: teams own their development plans
The team itself creates and regularly revisits a shared development plan — a “star map” of its skills and capabilities. They decide which skills the product needs, who learns what, and how this will reduce dependence on narrow roles and increase the adaptability of the whole product group.
Summary
Multi‑functional development does not grow out of motivational posters and calls to “learn and help each other”. It is either built into structure, processes, metrics, rewards and people practices — or the system will consistently suppress any attempt to step outside a narrow role.
If you want feature teams in Scrum / LeSS to truly be able to pick up each other’s work, change product direction quickly and stay resilient to change, look not at the people but at the organizational design around them. By replacing the obstacles above with their antidotes, you create an environment where multi‑functionality stops being a heroic effort by a few enthusiasts and becomes a normal, supported way of working.