InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Cost of Cross Functional Teams

Posted by Vikas Hazrati on Jul 27, 2010

Sections
Process & Practices
Topics
Teamwork ,
Agile ,
Team Collaboration
Tags
Diversity in Teams

Cross functional teams are the teams in which all members work on delivery of the same business value. It could potentially be the same feature or the same product. Though, Agile recommends cross functional teams due to a lot of inherent advantages, there are some caveats that organizations need to be aware of

Jurgen Appelo suggested that though the cost of cross functional teams is lower than the teams built around functional silos, but there is a cost nevertheless. According to Jurgen,

However... when you build teams across the functional silos, and not inside the silos, the interaction penalty is lower, but not zero!

He mentioned three main problems with cross functional teams.

  1. Sub-optimization at the project level
  2. Inefficiencies due to lack of coordination across projects
  3. Reduced expertise because of limited knowledge sharing across specialists

Jurgen also mentioned that, cross functional teams are usually too engrossed in the project that they are working on. This might lead to the scenario of doing major optimization on their own project which may or may not be in the best interest of the organization.

Cross-functional teams tend to optimize for their own projects, which can also hurt the overall performance of the business. For example, there may be problems when different project teams all decide to choose their own architectures and 3rd-party components. This increased variation of technologies makes it very difficult for the organization to support all those projects. And I’m sure that, when I allowed all our project teams to purchase their own computers and install their favorite operating systems and development environments, our friendly team of system administrators would skin me alive. With a screwdriver and a soldering iron.

Rick Maurer, suggested that the cost of cross functional teams is high especially in those organizations where either such teams are built without proper diligence or they have a half hearted endorsement of the management.

Likewise, Tom Mochal mentioned the need for effective management of Cross-functional teams. According to Tom,

Managing cross-functional resources is a result of working in a matrixed organization, where project teams are staffed, in full or in part, with resources that reside in other functional areas. The project manager needs to be very proactive when managing cross-functional resources.

Though cross-functional teams may look like the best solution in the Agile scenario, however there are important considerations like effective diligence, knowledge sharing amongst specialists and increased communication cost across projects which should not be overlooked.

Joan Lloyd and BNet shared some tips on building effective cross-functional teams.

  • This article is part of a featured topic series on Agile
Superficial and Incorrect understanding by Steven Mak Posted
Re: Superficial and Incorrect understanding by Vikas Hazrati Posted
Re: Superficial and Incorrect understanding by Steven Mak Posted
Re: Superficial and Incorrect understanding by Vikas Hazrati Posted
Re: Superficial and Incorrect understanding by Steven Mak Posted
Disconnection by Alan Dayley Posted
Re: Disconnection by Benjamin Booth Posted
Re: Disconnection by Colm O'hEocha Posted
  1. Back to top

    Superficial and Incorrect understanding

    by Steven Mak

    The worst one of all: "Managing cross-functional resources is a result of working in a matrixed organization". Agile teams are self-organised, and not organised by a "Project Manager".

    The lack of co-ordination is a problem with the teams and organisation, but not the problem caused by cross-functional teams.

  2. Back to top

    Re: Superficial and Incorrect understanding

    by Vikas Hazrati

    Steven, though I agree that on many occasions the organizational environment could facilitate a better Xfunctional team. However, when you mention "Superficial and Incorrect" do you mean that there is no cost associated with the Xfunctional teams?

  3. Back to top

    Re: Superficial and Incorrect understanding

    by Steven Mak

    "Superficial and Incorrect" means that the opinions mentioned in the article, IMHO, are superficial and incorrect.

    Like the one mentioned above, "Managaing cross-functional resources is a result of working in a matrixed organisation" is not a problem of having cross-functional teams. The root of the problem is having matrix organisation structure.

    When the teams are self-organised and not under matrix organisation, it is no longer the problem.

    I would appreciate if the article emphasize better about ways of supporting cross-functional teams (like CoP, co-ordination techniques), and knowing the organisational impediments behind these costs.

  4. Back to top

    Re: Superficial and Incorrect understanding

    by Vikas Hazrati

    Understood. May be that is a separate discussion though. The idea behind this post is to dispel the myth that if you have cross functional teams then you have a silver bullet solution. As Jurgen mentioned, though you are better off than having functional silos but still you must be aware of the costs associated and take care of them.

  5. Back to top

    Re: Superficial and Incorrect understanding

    by Steven Mak

    Right, I agree most of it except for the subtle differences with "the cost" here, which is also unfortunately part of the title of this article, or perhaps the core idea about what is the "cost" of having cross-functional teams.

    Ideas like CoP, co-ordination techniques, self-organising teams, feature teams, long-lived teams and so on ... are good ideas going hand-in-hand with cross-functional teams. I am not convinced that these are the "cost" of cross-functional teams, as the idea of cross-functional teams is just about putting people with different functional skills to work collaboratively towards a shared goal. It says nothing about inter-team co-ordination, for example, doesn't mean that is a cost of cross-functional teams. But instead, the lack of inter-team co-ordination, is a cost of the more general organisation dysfunction. There are lots of reasons behind and not driven specifically by having cross-functional teams in place. Good inter-team co-ordination is simply what good organisations should have.

    Alternatively, do you consider that it is a "cost" of Scrum because of the need for good engineering practices?

  6. Back to top

    Disconnection

    by Alan Dayley

    Perhaps this article does not go deep enough. I simply don't see the direct correlation between cross-functional teams and the "main problems" listed.

    Here are the main problems in the article:


    1. Sub-optimization at the project level
    2. Inefficiencies due to lack of coordination across projects
    3. Reduced expertise because of limited knowledge sharing across specialists


    These are potential issues with any company, using any types of teams or no teams at all. I would even say that number three is a problem that can be solved, in part, by cross-functional teams.

    Nothing is a silver bullet, I get that. Nothing is no cost, I know that too. But I don't see how the problems outlined are exacerbated by cross-functional teams.

  7. Back to top

    Re: Disconnection

    by Benjamin Booth


    1. Sub-optimization at the project level
    2. Inefficiencies due to lack of coordination across projects
    3. Reduced expertise because of limited knowledge sharing across specialists

    These are symptoms of poor management - no matter what the methodology. To show how Scrum should address this, I'll take these one at a time.

    1. Sub-optimization at the project level.
    Project level optimization is a matter of two things:
  8. * Putting the right people in the right places. Project level optimizers need to ensure the right balance of skills in each cross-functional team. As work proceeds it will become clear that there are certain skill deficiencies based on business needs. This will drive tweaking teams until the right combination is achieved.

  9. * Regularly creating and communicating a coherent strategy. This can be done a number of ways. The outcome is an optimally prioritized backlog (if using Scrum).

  10. 2. Inefficiencies due to lack of coordination across projects.
    So Coordinate. This is what the Scrum of Scrums is for. If you've scaled up agile and don't have a SoS meeting yet, this isn't the fault of being cross-functional.

  11. 3. Reduced expertise because of limited knowledge sharing across specialists.
    I've seen this first hand and agree that it's a concern.

    The resolution, however, isn't to throw out the baby with the bathwater. My suggestion for addressing this in our org was to create 'tech focus groups' that would meet infrequently to establish rapport, share ideas, solve difficult issues, etc. Additionally, I always supported the ability of team members to respond to external requests for help and information. We would keep track of these interruptions and account for them in future planning.

    All-in-all, the 'costs' this author mentions are well worth the benefits attained from cross-functional development: increased collaboration and cross-domain knowledge sharing, more flexible team members, higher focus on business problems (better IT/Biz alignment), faster delivery to market due to frequent, deep communication, etc, etc. I could go on.

    Food For Thought
    Successful small companies generally regard their small size as a competitive advantage against behemoths - they get things done faster. In short order, small companies outflank big ones and deliver value to customers before the big guy even had a clue. How do they do it? None I know of start with functional teams. And when they hire folks, they desperate seek highly intelligent, flexible workers who can work well in a diverse environment - aka a cross-functional team.

    So, then, if this is the common thread in effective start-ups why do bigger companies always degenerate towards the complete opposite?

  • Back to top

    Re: Disconnection

    by Colm O'hEocha

    Benjamin, you make a good point in your 'Food for thought' bit - I had similar ideas a little while back on how SMEs rely on agility to stand up against the big boys and better beware they don't get beaten at their own game...

  • Educational Content

    New-age Transactional Systems - Not Your Grandpa's OLTP

    John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

    Cool Code

    Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

    Collaboration: At the Extremities of Extreme

    Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

    Yesod Web Framework

    Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

    Transactions without Transactions

    Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

    Attila Szegedi on JVM and GC Performance Tuning at Twitter

    Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

    10 tips on how to prevent business value risk

    One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

    Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

    InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.