What Do We Mean by Cross Functional Teams?

One of the characteristics of a Development Team in Scrum is that they are cross functional.  But what does that really mean? The Scrum Guide simply states that “Cross functional teams have all the competencies needed to accomplish the work without depending on others not part of the team.”  

Cross-functionality has been at the forefront of my mind in recent months because I observed how a lack of cross-functionality impeded the performance and continuous improvement of one  Development Team. This team is comprised of a group of talented, dedicated individuals and some folks might argue that they ARE cross functional by the Scrum Guide’s definition. Their skillsets consist of Java development, C++ development, Quality Assurance, and UI development, in other words, all of the competencies needed to accomplish their work without dependencies on other individuals or teams.  

However, delving deeper into the Scrum Guide, it also states the following: 

  • Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person
  • Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis 
  • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole

I observed that the team identified strongly with their specialized skills and areas of focus, particularly with regard to Java and C++. As a result, the team consisted of sub-teams focused on these two skills and individuals remained in the comfort zone dictated by their specific titles or roles. Java developers wouldn’t touch C++ code and vice versa, partially due to a lack of skills and partially due to an unwillingness to learn new skills or learn older technologies. Consequently, the team didn’t embrace full team accountability and I observed significant waste on the team as a result. 

What Do We Mean By Waste?

In their book Lean Software Development: An Agile Toolkit, Mary and Tom Poppendieck expertly correlate the 7 Wastes of Lean Manufacturing to the 7 Wastes of Software Development. In my experience, the less cross functional the team, the greater the likelihood that one or more of the seven wastes will surface. Let’s examine each waste in detail and how a lack of cross-functionality contributes to it.

Waste #1:  Partially Done Work 

Partially done work results when a team fails to fully meet its Sprint goal. I often observe teams working in “mini-waterfall” Sprints. This happens when development work consumes the majority of the Sprint creating a logjam of testing work at the end of the Sprint. Quite often testing can’t be completed in the time remaining. I have observed developers pick up additional development work in the Sprint to stay “busy” while their teammates are frantically trying to test and deliver the committed work. This “busy” work creates an even greater load on the team and exacerbates the partially done work. The pattern of partially done work is commonly observed in teams that do not embrace cross-functionality. Team members focus on their skills specializations and labels. “She is a UI developer,” “He is a QA analyst,” “I am a Java developer.” In contrast, cross functional teams do not focus on individual goals and contributions, rather they focus on the collective goals and commitment of the team. Cross functional teams work together, even outside of their core competencies to meet their Sprint goals. 

Waste #2: Extra Features

Extra features are waste that results when a team builds more than is requested or needed at the time. For example, a team is working on a backlog item to support the entry of a domestic mailing address. A team member decides to add support for international addresses. They reason that a customer may need the capability someday and doing it now will save time  instead of cracking open the code again later. While it may seem harmless or even proactive and forward-looking to add additional “bells and whistles” and keep “busy” while the rest of the team is working on their respective tasks, these extra features are a form of waste. Additional functionality takes more time to build and test, may warrant changes to the database schema, adds code complexity and potential failure points in the system and has a high likelihood of never being used. Similar to partially done work, this waste often occurs with non-cross functional teams because team members are focused on their individual tasks rather than optimizing the flow of work across the entire team. High-performing, cross functional teams don’t seek or create unplanned worK. They are focused on the highest priority items and meeting their team goals.

Waste #3: Extra Processes

Extra processes can take the form of meetings, documentation, and reviews and are commonly encountered when the team has to reach out to other individuals or teams for assistance. Extra processes add cycle time to getting work done and consume the team’s valuable time. I recall one particular organization that had a dedicated Database team acting as a shared service to all of the Scrum teams. There were four database engineers serving 20 Development Teams. Development Teams did not even have the authority to add a simple column to an existing database table. All proposed changes had to be reviewed by the Database team, then added to the Database team’s backlog to be prioritized. The coordination and communication sequences between the Database team and Development Teams added a lot of unnecessary overhead. Furthermore, the Database team wasn’t able to keep up with the demands of all of the teams which often resulted in partially done work. Having a separate Database team masked the real issue – the company’s database schema was entirely too complex and the company hadn’t invested in simplifying it or training developers to effectively modify it. The waste was finally recognized and the company invested in training its developers, relaxing permissions for which types of updates developers could make, and began an effort to overhaul and simplify its schema. Cross-functional teams possess the skills they need within the team to complete tasks without added cross-team coordination and scrutiny.

Waste #4: Delays

In that same organization discussed above, the Development Teams were also constantly finding themselves impeded from completing tasks because they were waiting on the Database team to complete a task. When a team experiences delays, there is often a high probability that partially done work, discussed in Waste #1 above, will result. Additionally, the next items in the Product Backlog are delayed. Delays are also manifested in other ways with non-cross functional teams, even inside the team, in the form of single points of failure. For example, the team has only one UI developer creating a skills deficit when the developer goes on vacation for one week of a two-week sprint, or if a team requires all code reviews to be completed by one senior developer on the team. Cross-functional teams don’t delay progress due to skills specialization or a reliance on certain people within or outside the team.

Waste #5: Handoffs

Waste in the form of handoffs can often be observed within a team by evaluating their communication practices. How much is the team relying on written requirements instead of talking and collaborating about what they need to build? How do Developers engage QA team members when they believe their code is ready to test? Do they just throw it over the wall or do they sit down with their team member and give them a quick walkthrough? How does QA document and communicate defects that arise? How many emails are sent with questions to other team members that could have been asked in a chat or better yet, in person by calling them or walking over to their desk? Handoffs result in information loss and every time team members choose to communicate in a less effective way, they contribute to that loss. Cross-functional teams communicate with members early and often and don’t exclude members from key meetings and decisions.

Waste #6: Task Switching

The waste of task switching manifests itself in many ways when cross-functionality is absent. Team members that rotate on/off teams continuously because they possess certain skills erode the team’s stability and velocity. When teams are not cross functional, work in progress (WIP) tends to be higher and backlog items are often worked out of priority order, thereby compromising delivery of highest value items, because team members cherry pick what they are able or willing to work on next. Cross-functional teams stay together. They focus on highest priority initiatives and limit WIP.

Waste #7: Defects

Defects are an obvious form of waste, however, the impact of a defect increases the longer it goes undetected. A critical defect that is detected in three minutes is not a big source of waste whereas a minor defect that is not discovered for weeks could result in a much bigger waste. The potential for defects is greater with non-cross functional teams because the testing often occurs late in the Sprint cycle and is performed by a small subset of the team. Cross-functional team members jointly contribute to testing efforts and collaborate early and often during the sprint cycle.

Not only is it important to structure teams such that they are cross functional, it is also important to build internal knowledge and cross-train team members to eliminate single points of failure and too much skills specialization. Non-cross functional teams are more likely to miss their Sprint goals and release targets, take longer to deliver value, overproduce features, deliver with lower quality, experience communication barriers, and experience inefficiencies due to team member over/under utilization. Cross-functional teams on the other hand, are more predictable, produce higher quality results, and deliver value more frequently. They experience greater empathy amongst team members because they partake in shared goals and tasks, essentially taking a walk in each other’s shoes as needed to meet their Sprint goals. They also benefit from skills development, knowledge acquisition and stronger team stability and trust.  

Thomas Edison once said, “Waste is worse than loss. The time is coming when every person who lays claim to ability will keep the question of waste before him constantly. The scope of thrift is limitless.” Mature, high-performing, cross functional teams minimize waste and as a result, their achievements together likewise are limitless. 

Watch the Scrum Alliance Webinar

In October 2020, I also had the chance to present this essay on Cross Functional Teams as a webinar for Scrum Alliance.