Situation

Cross functional teams are teams that have the capabilities of building the software they have committed to with no outside dependencies. This is fairly rare in development/IT organizations that have more than 30 people. The larger the technology group gets the more difficult this becomes. Having cross-functional teams makes teams both more creative as well as more efficient because of fewer hand-offs and common knowledge.

Unfortunately, creating cross-functional teams is often difficult, incredibly expensive or downright impossible.  This may be due to a shortage of a particular skill set or simply knowledge of what happened in the past. This latter one will always be a problem until someone invents a time machine where folks can go back and see what happened. Unfortunately, if we actually end up sending anyone back, they will bring a copy of today’s Wall Street Journal with them and won’t want to work for us when they come back. OK, I’m joking, but you get the point.

A side note

Scrum and XP proponents often suggest “co-located” cross-functional teams.  In many ways this is a good thing as face to face communication has many advantages. However, many people have found that everyone in the same time zone iwth a tool like Slack can be as good or better.  The real issue is that it is a real team, focused on one outcome – realizing business value via creating the sprint’s increment.

Objectives of the practice

The purpose of cross-functional teams is to have all of the people we need to get the work done be available when they are needed. This reduces handoffs and waiting for others. The principles this is following is to avoid delay in the workflow and to get quick feedback. In Lean this is called the workcell.  The law underneath this is that delays in workflow and feedback cause extra work to be done (consider how the delay between coding and testing makes developers spend a lot of time finding things that have gone wrong. See Cross-Functional Teams: Improving Communication Between People who Work Together.

How to do the practice better

Sometimes not being able to achieve cross-functionality is because a team-member is needed in more than one place at a time and the person does not have the time to cross-train someone. In cases like this, it is often advisable to have someone shadow this person. It may take a little more time to get the up to speed, but it won’t be a burden on the person with the specialized skills. In fact, the “shadow” person may be able to help at times.

Alternatives to the practice

Cross-functional teams should definitely be created if it is financially viable to do so.  However, it often isn’t. In that case, there are several alternatives available to get as much of the objectives of cross-functional teams as possible. However, different practices work in different situations:

If a team is almost cross-functional and needs a significant time from another team.

If you mostly have a cross-functional team and need people from another group for 2+ weeks, loaning people from the other group to the team may be a good choice. An example was a client of ours who had a team that needed help from a component team (a team that worked on components of an application that several teams used).  The main team used about 20% of the capacity of the component team which was comprised of ten people.  They realized that instead of having 20% of their capacity used by the main team, they could just loan 2 of their people to the main team. This, of course, required these two folks be in two daily standups (their temporary team and their real team so they could keep them up to date on the changes they were making).  They didn’t like this, but it was the price to pay.  This was a great improvement because the main team now worked as a true cross-functional team.

If a team is almost cross-functional and needs a person who supports 2 or more teams.

The edge case on whan a person can be committed to ther teams varies. Sometimes with 2, rarely with 3 or more a person can be split across teams.  More likely, however, the limited capability should set up their own Kanban board so teams can see what sort of delays they will have on dependencies. The Kanban board should not be a FIFO (first-in first-out) board but rather sequenced with the intention of reducing cost-of-delay based on the relative importance of the work being done.

Not close to cross-functional.

Adopt a pure flow model like kanban to lower the delays in hand-offs between different people. This is where a Kanban approach is more likely to be better.

How to test if an alternative is better

When considering a change, look to see what you expect to happen to the cycle time of work by looking at the value stream impedance scorecard. If the scorecard improves, you likely have an improvement. Try it as an experiment for a couple of iterations and see what happens.

Case Study

Cross-Functional Teams: Improving Communication Between People who Work Together. This is a chapter from our upcoming book that discusses team organization. The heart of Scrum is the self-organizing, cross-functional team. Sometimes people forget the cross-functional part of it. There are two parts to crossfunctionality. The first is that different skills need to work together. The second is that teams need to have all of the skills required to produce value.