How to build a Cross Functional Team

Try arranging some team building sessions for the team.

Limiting Work in Progress, ideally to Single Piece Flow, is a good way to challenge skill silos. Team members are obliged to collaborate in order to maximize throughput.

There is not enough information from the question. Let me bring in some interrogation

- What is your role here? Are you the only one feeling that the team is not self-organized?
- Was the work for near term sufficiently decomposed to have fine grained work items? Can the team clearly sense the work involved in each of these items
- Did the team use the scrum elements to increase the transparency of their collaboration? Do they get together everyday in Daily Scrum and see the status of work items and collective progress? Does the team see that there is lack of transparency of information on this collective progress?
- Are the issues and impediments publicly radiated?
- From your articulation of "more experience experts", I wonder if the team has healthy mix of skills. Is the team mix biased towards one skills too many where there might be social tension in proving who calls the shots. Cross functional is about having sufficient mix of skills as required in definition of "done" not more not less. Also, the team members need to have high transparency of work information, not necessarily technical mentoring or sharing. Is the work items decomposed to have too many cross dependencies within the team? Check that angle too
- I assume that the team has been into Sprints now. Was there any retrospective? Did the team reflect on their way of working? What was the collective decision on improvement goal?

Once the team gets the skill mix, decomposition, transparency elements correct, Ian's recommendation about lean workflow can be followed as well to increase the team focus on the goal.

Rahul, it seems your first obstacle is in helping this assemblage of individuals identify themselves as a team. This can be both a tricky and lengthy process.

One tactic I have used in the past is to schedule a meeting where the topic is on what are the traits of a good team. Usually, everyone can explain these characteristics through sports analogies or other group experiences. Look for them to list traits like versatility, communication, commitment, etc. Then have them discuss characteristics of a bad team.

You can then use both lists (actually provided by the team) to make your observations known around your team's behavior. It is a good starting point to help your team understand what they need to do as a whole in order to perform better. Good luck!

http://blog.scrum.org/how-to-build-a-scrum-team-with-contractors/

this blogs seems to be answer to my question

Hi Rahul,

Could you be more specific about what the blog post managed to solve? I have experienced what I think may be a similar problem but we don't work with contractors. There is a real dilemma with team formation and management. Ideally you want people to self-manage, yet I have experienced all to often that people do not feel can- or need to influence the formation of their team.

Egos can be a real difficulty too, some people work for external reasons like being seen as an expert so the challenge is to try to make the results of teamwork rewarding.

I have found that many changes come down to getting the behaviour first and not the motivation. So just 'mechanically' doing a best practice by saying "let's try swarming a few features and see how we like that". If there is resistance, ask for a little experimentation time. When people have tried it try improving the process instead of abandoning it. But I have also had people who really don't want to work in a team and refuse to try new things.

Dennis, the problem is not yet solved but the blog gives good hint to solve this problem.
Lately the team started offshoring. So I have team with few developers from offshore and few contractors old (close to their retirement ) employees.

The old employees are having fear of loosing their job because they think that if they become very transparent then they might loose their value and Job. so they tend to be little reserved and not share the information so openly. Changing behavior of such employees is quite hard

Contractors are also doing the same. They use their expertise, work alone and they try to make sure that their part of work in done rather than the teams works. They tend to hide the information and create a dependency so that in case if management decides to downscale the team, they are not fired.

The blog talks about the solution(at least some aspects of it) and i will try to implement those. And obviously need to work with management to convince them.