Cross functional teams sounds a lot like a buzzword, and maybe it is to a degree - but still worth talking about and I have a short story to support it. Several years ago when I took on management of a team of developers one of the first things I did was stop the practice of everyone going to their favorite developer to get a fix/feature done. It was painful for all concerned, but I built a pretty serious wall around the team so that we could control the interrruptions, the pace, and the overall focus of our efforts. External users didn't appreciate my adding a layer of so-called bureacracy, and the team didn't like the idea that they didn't get to be 'the man' by responding to various pleas for assistance.
Over time the strategy worked, and we tried to do the things that mattered most, as we could best determine. So far so good.
A little longer into the change though I started to see other negative effects, the biggest being that the team (and this is common in IT) was really disconnected from the business, approaching their work with enthusiasm but still the outlook of....mercenaries? Probably a better word to be used there, but the point was that they became overly isolated from the successes and failures of the business that paid their salaries.
The next step was to lower the wall some, let them have some controlled interaction with the business users beyond purely tactical conversations. Strangely it was just as hard to get them to do this as it had been to put the wall up in the first place. I think few of us like change of any type, and it was surely change. Project based (cross functional) teams were the first place where I really had success at integrating them back into the business and as an aside, another interesting point was that while within the team they were often cynical, sarcastic, or reserved, putting them in front of people they didn't know very well brought out their long hidden professional people skills - most people just act bettter in front of strangers and/or upper management.
The final step was to move into cross training, in two parts. One part was putting someone from my team in operations for a day - letting them follow along with a user and a manager to see how the tools they built were really used. Lot's of really interesting input came back from those (after the complaining about having to go) along the lines of 'we can help them do x....'. The other part was bringing managers and users into our team environment for a day, warts and all. IT is often seen as overhead, a black box, and worse, and there's nothing like showing them what we do in meeting and watching some code being written to show them that it's harder than it looks.
I think I'm wandering a little, so here's the final point. I've worked on a LOT of cross functional teams during my career, some worked, and some didn't. The idea is sound, perhaps even great, but it really depends on the person leading the team and their ability to manage all the egos and agendas that come along with having humans involved. The more I could participate in cross functional discussions the more I understood - really understood - the business, and how I could add value to it. Something to think about perhaps.
