How to have a cross-functional team in a real-life setting?

Many organizations don't have truly cross-functional Development Teams teams. So if you can help create those, that's most of the battle won right there.

Everything else, as long as you implement the Scrum framework, would come about through empiricism and emergence. Don't overthink it. Self-organization is good for innovation. In my opinion, smaller Development Teams (3, maybe 4) get a lot done, quicker, if they are cross-functional. And avoid the temptation to scale. 

I'm working on a concept to split the Dev-Team and create two, truly "cross-functional" teams, but I can't seem to find real life examples how to actually do that,

In Scrum the concept is not one of deciding how to split teams, but rather of facilitating the ability of people to self-organize for themselves.

+1 to what Ian said.

What's your role? I am guessing Scrum Master, but knowing that may allow us to provide more specific advice.

You raise a lot of important issues. Some of them already seem to be not ideal, and it might not be reasonable to solve all of these issues immediately. That doesn't mean you and the teams shouldn't continue trying to solve/eliminate them.

Be aware that optimizing current processes isn't always the best solution. Sometimes you need to choose a completely different approach.



Actually many of these issues could become a topic by themselves, so it might be hard to get to the bottom of them in a single forum thread, but I can try to answer a few, and let's see where it goes.

What if you don't have a task that involves that person in a sprint?

What if you run out of tasks that involves that person in a sprint?

Try to avoid the concept of feeding tasks to an individual. Yes, there can be specialists, but the danger is that the focus switches to keeping people busy instead of delivering value.

If you buy a house, do you care whether the plumbers were busy for every hour they were on site, or do you care about the result, such as the taps and drainage working correctly?

If you can have a person only 20%-50% of their time in each cross-functional team, how to handel double Daily, double retro, double planning etc for that person?

Yes, it might be best if they attend both. This could involve trade-offs, such as having one team delay its Sprint Retrospective and Sprint Planning until after the other team were able to have theirs; or alternatively, they could be at the same time, and this person might need to choose which team's events to attend each sprint. Bearing in mind what I said earlier, maybe it's more effective to hire or train someone else to have these skills, even if they won't be very busy.

One different approach could be like what my company has done with QA engineers. We agreed as an engineering team that we want coders to also write their own automated tests. Some began with absolutely no experience of doing that. The QA engineers stepped out of the teams, and they became servant leaders. Now they coach engineers on how to write better tests and documentation, and they can do other things, like looking at broader quality trends in the product.

The result is that the teams became cross-functional, even without these specialists.

If we for example a customer request to configure something, which only a consultant does but he would be part of the cross-functional team, should that task still be up for refinement for the entire team?

…

Would it be better to leave that task in that division and only have them join partially if required?

I would start with establishing whether the team take collective responsibility for it being done. If so, then it is probably in their interest not to have only one person with these skills and knowledge, and so other developers might want to get involved in refinement. Maybe the team find an even better solution, such as instead of requiring a consultant to configure something, that it's automated, or made self-service so a customer can trigger it directly.



If the team do not accept responsibility, then it should be transparent that as well as working in the team, this consultant has other duties. This may or may not prove to be a problem later, but a continuously improving team will eventually review it, and consider solving the problem in a different way.

Would the PO now be responsible for their tasks, despite not really contributing?

A PO can delegate as many of their responsibilities as they like, but they remain accountable. If the Development Team can simplify a process by treating certain work as business-as-usual, and acting on it without waiting for the Product Owner, that's an entirely valid way of working. If this negatively impacts the value that the team is delivering, the Product Owner might need to step in.

Would Scrum of Scrums be better if the tasks are primarily independent?

Perhaps, but what actual problem would it solve? With just two teams, I would expect developers to be proactive enough to go and talk to each other if they need help, or there is a risk of dependencies.

Thank you for your answers so far.

What's your role? I am guessing Scrum Master, but knowing that may allow us to provide more specific advice.

I'm the PO of the Dev-Team.

Be aware that optimizing current processes isn't always the best solution. Sometimes you need to choose a completely different approach.

I'm also researching other solutions, like SAFe, Nexus Scrum or LeSS.

Try to avoid the concept of feeding tasks to an individual. Yes, there can be specialists, but the danger is that the focus switches to keeping people busy instead of delivering value.

If you buy a house, do you care whether the plumbers were busy for every hour they were on site, or do you care about the result, such as the taps and drainage working correctly?

Since we aren't cross-functional yet, we don't really have that issue of feeding tasks, but I see it arising, once we have multiple specialists dedicated fully or partially in a team. Of course the end results count, but it's especially about those mono-tasks, that are typical operational work, which has no connection to any other team member or function.

If you can have a person only 20%-50% of their time in each cross-functional team, how to handel double Daily, double retro, double planning etc for that person?

Yes, it might be best if they attend both. This could involve trade-offs, such as having one team delay its Sprint Retrospective and Sprint Planning until after the other team were able to have theirs; or alternatively, they could be at the same time, and this person might need to choose which team's events to attend each sprint. Bearing in mind what I said earlier, maybe it's more effective to hire or train someone else to have these skills, even if they won't be very busy.

Our QA was split 70/30% for two teams and he didn't get anything done, due to the constant amount of meetings he had to partake in. As per his request and mine we recently agreed that switches to one team full-time. The other Qa position in that other team is now vacant (again).

One different approach could be like what my company has done with QA engineers. We agreed as an engineering team that we want coders to also write their own automated tests. Some began with absolutely no experience of doing that. The QA engineers stepped out of the teams, and they became servant leaders. Now they coach engineers on how to write better tests and documentation, and they can do other things, like looking at broader quality trends in the product.

The result is that the teams became cross-functional, even without these specialists.

I'll add that appraoch to my research for alternative approaches to splitting the team(s).

I would start with establishing whether the team take collective responsibility for it being done. If so, then it is probably in their interest not to have only one person with these skills and knowledge, and so other developers might want to get involved in refinement. Maybe the team find an even better solution, such as instead of requiring a consultant to configure something, that it's automated, or made self-service so a customer can trigger it directly.

Well the new team goal would be "solution delivery". That means it doesn't matter if you need to configure something,

develop something, change a report or have server issues or need a combination of all. So yes, the team would responsible for that, depsite only a few person who can do that on each team. We'd not only have one consultant per team, probably around 2-3.

The issue would be if they are fully integrated in that team, that their operational tasks would still need to be done (customer support, directly configure something etc). So that part of their work is not truly integratable in scrum in my opinion, due to the timing factor and that it dosn't contribute to a new release.

If the team do not accept responsibility, then it should be transparent that as well as working in the team, this consultant has other duties. This may or may not prove to be a problem later, but a continuously improving team will eventually review it, and consider solving the problem in a different way.

That's why I'm wondering, if it would be better to have them partially join the team, so their operational work can still be done without a needlessy hassle and overhead and just have these cross-functional features be done by the new team.

Perhaps, but what actual problem would it solve? With just two teams, I would expect developers to be proactive enough to go and talk to each other if they need help, or there is a risk of dependencies.

We currently have 2 consultant teams (1 for a big customer, the other for all other), 1 Dev-Team, an admin-division who doesn't work as an agile team and Reporting who is just a single person. Any of these is usually invovled for tasks concerning my product. We recently implemented a biweekly SoS-Daily, with a representitive of each division (sans the reporting person who has enough to do) but it's too early to say what impact it has.

You have already gotten some great advice on how to proceed on your plan.  So I'm going to play devil's advocate. 

Why are you doing this?  Is there a problem that you are trying to solve?  Is the organization having difficulty delivering value to the customers based on your current organization structure?  

While agile is a hot topic and Scrum is desired by many I remind you of the old adage "If it ain't broke, don't fix it".  If you are delivering upon the needs of the users in timely fashion, I would just leave things as they are and continue.  Have you ever upgraded your phone to a newer model and then realized that you are using the new phone exactly like you used the previous phone, that there was no benefit to getting the new phone but you are subject to the expense of acquiring the new phone? 

Having said that, if there are indeed problems with your ability to deliver value to the users in a timely fashion, then you have something to address.  But address those specific issues as simply as you can and don't try to make wholesale changes across your organization just so that you can say you have cross functional teams using Scrum. Do you really need consultants on a team with developers if they will just work on separate areas?  Will the presence of a consultant on a team of developers really add any value or benefit to that team's ability to produce a potentially releasable increment of value at the end of a Sprint? 

Don't try to organize in a way that allows you to claim you are following Scrum unless there is a real need.  And your entire organization does not have to be using Scrum.  From the Scrum Guide's section that defines Scrum:

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Is this really what the consultants are doing if they are just configuring an existing product?