For some time now, since a conference I ran in July on Agile and New Forms of Organization, I have been trying to get clear in my mind what the difference is between an “agile team” and a “cross-functional team”. Also, I recently participated in a cross-functional team looking at ways to improve the performance of corporate functions.
Cross-functional teams have been a feature of organisation since the 1960s, when Boeing first developed a new aeroplane using a multi-functional approach. This successful experience was documented by Jay Galbraith, who called it a “matrix structure”. It was the first documented use of matrix organisation ideas: in Boeing’s case a function/project matrix. At various points in time since then, cross-functional teams have been much written about and much used.
So what is new/different about Agile compared to cross-functional teams? Here is my list
- Agile team members are allocated to the agile team full time. Many cross-functional project teams are part time. Of course, many, like the Boeing example, are also full time. Just to confuse us all, some people call teams with part-time members “agile” teams.
- Agile requires a long-term mission for the team and some clarity about the “customer” being served. It also gives freedom for the team to “self-manage” in delivering the mission. Project teams will typically have time-limited objectives, and less commitment is given to ensuring the team has freedom to work in whatever way they like.
- Agile typically requires co-location of the team. Cross-functional team members often remain located in their function, but come together for joint activities. Co-location is believed to be an important part of agile because it produces better communication (essential to self-management), more commitment and more speed.
- Agile typically involves using many of the methods of ‘scrum’, like backlogs, sprints, stand up meetings, visible progress displays, etc. Project teams, at least historically, involved few standard ways of working, and project management typically uses a “waterfall” approach.
- An agile team needs a “product owner”, the person in the team who prioritizes the backlog and does some other “team-leader-like” roles. A cross-functional project team has a team leader, whose role is typically broader and less well defined.
- An agile team is expected to produce intermediate outputs and trial these outputs with the beneficiary/customer it is serving. The concept of “minimum viable proposition”, from Lean Start Up thinking is important here. Agile teams are expected to generate trial outputs quickly and expose them for comment and reaction. Project teams, more typically work in a “waterfall” approach, only exposing their output towards the end of their work.
- An agile team is a permanent part of the organization. Whereas a cross functional project team is typically expected to have a limited life, often months not years. However, many people use “agile” to refer to temporary teams, and because organizations change fairly frequently few agile teams stay the same for more than a year or two.
In summary, some cross-functional project teams (those with long time horizons, well defined missions, clear team member roles, scrum working practices, sensitivity to their customers, etc.) are very similar to agile teams. But the typical cross-functional project team has important differences from the strictly applied agile team.
This raises the question of what is the same between agile teams and cross-functional project teams.
- Both types of team have members drawn from different functional disciplines, and the functional disciplines are still responsible for the capabilities of their people. This is the matrix element.
- Both types of team have defined objectives and are expected to deliver valued outputs.
- Both are ways of breaking down the functional silos that can stultify an organization.
The current enthusiasm for “Agile” may be little more than a wave of popularity for cross-functional working. It could also be an enthusiasm for “scrum” working practices. But, it feels as though it is more than either of these. It creates additional matrices in the structure of the organization, and it seems to be a faster way to learn how to improve outcomes.
