How to Build Cross-Functional Agile Teams

Intro

Everyone used to love the idea of a well-rounded individual. Society had ingrained into us a foolproof belief that true professional and personal success was exhibited when a person had their foot in a little bit of everything. Contrary to this long-standing thought, in an effort to assemble a well-oiled team that will build software and deliver quality products, organizations are now looking for a different type of individual: one that is a master of his or her trade. This individual is not an all-arounder, but rather a subject-matter expert. People no longer need to be knowledgeable in the arts as well as science, because companies need to be the best in their particular field and showcase their capabilities as superior to their competition.

As a result, there are predefined niches for which each new hire can fit. This desire to prefer masters over adapters compartmentalizes talent within a company. Therefore, encouraging college students not to strive for interdisciplinary learning but rather to concentrate on narrowed majors and not venture into other spheres. This practice is a manifestation of the furthering divide in the workplace. It impedes the translation of work from technical to non-technical project members, meaning that it is harder and harder to understand another team member’s job.

The Problem

Companies want teams of think tanks to gain patents or produce white papers. However, they may fail to realize that the main hindrance to a successful team is the lack of cross-functionality. How does a team that is not agile, nor cross-functional, behave once a new project has begun? Once employees are given their tasks, they are somewhat pigeonholed and expected to dive deeply into one subject to please a client. For example, a project manager may study a client, practice their presentation and speaking skills but may not focus on the technical details for the project. Why would they, when they know that is solely the engineer’s responsibility?

Similarly, an engineer may brush up on a new coding language and watch tutorials, but may never be given the opportunity to develop skills in communication. More technical employees may rarely get the chance to lead meetings or engage with a client, and over time, they become less likely to do so in the future—that skill set remains nascent and never develops further. This lack of client interaction is evidence of monofunctional teams that only focus on product-building, not people and business building.

Why Agile?

Explaining technical requirements or thoughts to non-technical project members has been overlooked due to a lack of awareness. It stems from the outdated idea that one degree, career, or capability is considered more valuable than the other, to the point that the need to transcend other teams is swept under the proverbial rug. Often, in the waterfall approach, work is divided into trenches that allow team members to go deep, wait for a blocker to get removed or approval to be granted, and then proceed. This methodology is becoming less relevant as the increasing complexity of products, coupled with a rapidly changing technological environment, demands more interaction across engineering teams and design teams than waterfall traditionally allows.

There is no allowance of breadth for an individual as this method of development not only pigeonholes but is also somewhat resistant to change. If a new design or change order arrives, an agile team would be prepared to handle it much better than their waterfall counterparts. In Agile, since goals are smaller, new input from other capabilities (e.g., designers, business analysts, and project managers) is far easier to implement. As a result, all team members can focus and understand goals holistically, becoming accustomed to both the technical and non-technical aspects of a project.

Why Cross-Functional?

Diversity adds value. It spurs innovation and creates not just stronger teams but also stronger deliverables. A team that is interdisciplinary allows individuals to absorb knowledge and skills from their peers. So the goal for managers who are staffing teams should be to have members who are not only specialists but are willing and able to learn other horizontals and participate effectively in an agile approach. That means being able to ask the right questions and understanding other aspects of the product that are not their direct responsibility.

Oftentimes, engineers are in the shadows during client presentations and are only called upon to answer specific questions. Likewise, project managers are in the shadows during Proof of Concepts, unable to contribute their skill sets. Imagine if that team was cross-functional, and an engineer was encouraged to improve their public speaking or a project manager had been present during technical meetings and therefore had enough knowledge to answer those questions. How much stronger is a team when everyone is encouraged to add value?

Coaching

With agile and cross-functional teams, there needs to be an emphasis on training. When it comes to learning, engineers are often provided more opportunities to increase their knowledge than other team members. In this case, software development is the helm of coaching as engineers are racing to get certified in various programs, classes, and skills in order to build agile software. Why invest in non-technical team members to fly out to client sites, or to take a class or gain a certification? Why is that needed if the money-making software and products are being created to grow the ever-changing business and its needs? The answer is that agility is not only a methodology but a mindset.

When building a product, communication between teams speeds up a process significantly. Moreover, better communication can be achieved if a product manager is offered the chance to become AWS certified or is trained on some basic technical items before project kick-off. Confidence becomes instilled in an individual that they are valuable to a project as they can adapt to the technical side and better help with potential risk. This illustrates the idea that agile teams are flexible, faster, and more responsive to any roadblocks. However, it is often forgotten that an agile cross-functional team is one that is itself agile but also one that has team members that are able to play various roles.

Cross-Functional Agile Team

Levvel, when staffing projects, aims to create cross-functional teams that predominantly work in an agile fashion, and the success has been tangible. However, the question arises on how to make the system work a little bit better? How do we explain technical needs to non-technical project members? Moreover, how do we do it without condescension and maintain the dignity of every individual?

Levvel held a workshop where employees, in the office and remote, were able to play virtual Taboo. Two teams were created, and each player, when it was their turn, was sent a Taboo card through Slack. The objective of Taboo is for the player to get his or her team to guess the word listed on their card, without using the word itself or any of the related words listed on the card. With only a few kinks, we were able to get everyone participating, and while some words were harder than others, everyone was able to understand what it is like to be in the shoes of someone trying to explain something technical to a less technical team member.

The idea for this exercise stemmed from a popular interview question that is often asked in the tech industry: “How would you explain the internet to your grandmother?”. While this may seem like an innocuous question, explaining the internet to an older relative is harder than you think. While we may all “know” what the internet is, can we describe it to someone who has rarely or never used it? To us, it seems absurd, of course, everyone must know what the internet is. It seems like a prehistoric notion that a person does not know the power of the internet. Nevertheless, it is that hubris we have when imagining someone who could not possibly know what we know. Being put into the shoes of someone who is not like us and doesn’t think like us is hard, but it is necessary. Do we all strive for this level of empathy when working on projects? We’d like to think so.

Similarly, are we then practicing how to explain databases, algorithms, and computer architecture to our stakeholders, analysts, and managers who have rarely or never been in contact with such topics? Activities like this can help teams learn to be more agile. Not only does this activity promote cross-functional teams, it showcases that no one niche is superior when it comes to building software or products. It also enables better communication channels to be opened as each role is humbled through this activity and forced to reflect on that uncomfortable feeling of not being certain.

Promote Multifaceted Individuals

If communication is, in fact, key, then a scrum master should be able to lead a team without worrying about understanding technical questions or problems. Instead, their priority is to coordinate with the team throughout the development cycle. If a project manager or scrum master has not been trained or given the opportunity to cross into the technical field to observe and learn, then they may be in a state of panic during meetings, attempting to catch up with his or her agile team members. Moreover, team members would not get siloed in their work; instead, they can venture into aligning disciplines.

Imagine if that scrum master had been given the chance to achieve some breadth and cross into the software or product side by being allowed to gain certifications in AWS, Azure, or basic coding. What if that learning was encouraged? That is the true definition of agility. Having that comprehension allows that team member to adapt and apply previous knowledge. This is why they say that one can have an agile mindset, as well. It can be created and molded just as a cross-functional team can be taught to become agile which leads to increased innovation in the process.

“It takes a focused team to implement strategies and bring your vision alive. Our project management team integrates with other Levvel capabilities, sometimes a mix of developers, analysts, and designers, to carry your project to success. Our approach is to deliver solutions as a team while building long-term strategies so you can see value quickly without sacrificing quality over the life of the project.”

The above statement from Levvel serves as guidance for companies to find ways for their team members to communicate in the technical and non-technical spheres. Levvel aspires for its employees to be T or V-shaped rather than I-shaped individuals. T and V-Shaped employees are those with breadth and depth. They are not pigeonholed or simply scattered shallowly into many areas. Instead, they are experts in their respective fields but are also given the opportunity to switch projects, are encouraged to try new things, and are constantly asked to voice their opinions.

By aspiring for truly cross-functional teams, this has enabled Levvel to climb the ever-growing ladder of success. Regardless of how other organizations are set up, teams that can speak different “languages” are a necessity. A truly cross-functional agile team has many masters and specialists who work towards the same goal, and that cohesion brings about some of the best agile software development.