Back to the Basics: Cross-Functional Teams

This is a topic that really shouldn’t even need to be discussed. Yet, there are hundreds (maybe even thousands) of companies that do not understand one of the core pillars of modern software development: cross-functional teams.

Or, at least, they don’t practice the true concept of cross-functional teams that can lead to true agile, lean, and high-impact outcomes for your customers. So, today I would like to set the record straight. I will discuss how we got into this mess, what cross-functional teams are, what they are not, and how companies can best maximize their efficiency.

Why Modern Software Teams Are Broken

Why do we find ourselves even needing to have this conversation? To understand that, we need to understand something of the history of both software design and software development.

The first thing we must understand is that when personal computers were first popularized in the 1980s, there was no such thing as an app store or digital downloads. Software had to be manufactured. The cost & time required to manufacture and distribute each release was staggering.

Because of this, there was immense pressure to pack as many features into a release as possible. It wasn’t only the time between releases that was the problem it was the sheer cost to consumers. Some software packages costed hundreds (and even thousands) of dollars. An individual consumer simply wasn’t going to upgrade every year. This led to a focus on technology and shoving as many marketable features into a given release as possible.

The other (and maybe more important) thing this did was to put the focus on a stage-gate, get-everything-figured-out-first mentality. This is understandable given the above constraints. Product Requirements had to be 100% defined before design touched it. Design had to complete their work quickly and deliver detailed design documents to development (comprising hundreds of pages at times). Then development had to finish for testing. Testing for manufacturing, and manufacturing for distribution. All ahead of an annual release date. There was no time for tweaking or reacting based on user feedback. Due to the get-it-figured-out-first mentality that was necessary all the teams worked in their silos with their hard deadlines before throwing it over the wall to the next group.

Then in 2001, a group of engineers got together at the Snowbird ski resort in Utah to discuss how this process might be improved. The internet had been popularized a decade earlier, iTunes with their digital downloads had just been released, Napster’s popularity was on the rise and they knew the age of manufactured software was nearing its end. A change was needed.

They placed the focus on the user rather than the technology and on continuous delivery and working together with the business side to iteratively deliver value to consumers. They wanted to shift their industry towards “responding to change over following a plan”, “customer collaboration over contract negotiation”, “working software over comprehensive documentation”, and “individuals and interactions over processes and tools”. As the name “Agile” denotes, the main goal was to move faster and be more reactive to new learning.

Over the last nearly 20 years companies across the globe have attempted to become “Agile”. Yet many still struggle. Why? The main reason I have found is that Agile failed to address one key aspect: Cross-functional Teams. It was focused on improvement of the development process. There was no discussion that weekend in 2001 about design, product, user validation, research, marketing, or any other discipline related to the creation, sales, & distribution of software projects. As a result, the product lifecycle at most companies today resembles a quickened version of the waterfall process of 30 years ago. Product still comes up with requirements largely by themselves (or in conjunction with UX if you’re lucky). They deliver their requirements from on high to the UX team. UX iterates through the design and delivers “what will be built” to the developers. Often the first time a developer sees the design is at Sprint Kickoff or Planning. At each stage there are objections, arguments, and heated discussions all which create an immense amount of wasted time and result from the fact that each discipline was involved very little in the others’ work.

Even if a dev lead is consulted mid-way through the design process that still doesn’t work because his focus is on helping his developers finish their sprint and only maybe 10% of his attention is on your problem. Is this what the Agile Manifesto authors intended when they wrote: “Business people and developers must work together daily throughout the project”? I think not.

“Cross-Functional”

So how do we fix this? To understand that I think we need to talk about the term “cross-functional”. Cross-functional means multi-disciplinary. It means that everyone needed to design, build, and release software are all on the same small team. It means Product, UX, Dev, QA, Marketing, and anyone else work together to deliver value to their customers. Yet walk into virtually any standup or look at any scrum board today and what do you see? A board chalk full of dev tasks. Are there UX stories? Nope. Product work to do in the next 2 weeks represented there? Nope. All “team commitments” are based on dev work. If there is a UX board at all, it essentially is it’s own mini little scrum team.

Most companies assign cross-functional employees to work on the same product, but they operate as separate teams one feeding work to the other. Sound familiar? It should. The flavor has changed, but at its core it’s still the stage-gate waterfall process of 30 years ago.

"Teams"

A team is a group of people who work together to achieve a common goal or solve a common problem. Can you imagine if an NBA player decided to let someone pass him uncontested and score in the last seconds of a close game because it wasn’t his assignment to guard him? Imagine a police officer who witnessed a sex crime let it go on because he wasn’t part of the special victims unit? Yet software teams operate like this all the time, and it’s not the team’s fault. We as leaders need to break away from the notion that every minute not coding is a minute wasted. We need to ditch the output-focused mentality of the 1980s and join the Experience Economy. We need to focus cross-functional teams on delivering outcomes.

The only way to truly do this is pull together your cross-functional employees assigned to a given product and give them a SINGLE problem to solve TOGETHER. What is their championship? Then you need to structure how you estimate work, evaluate performance, and judge success around those outcomes they achieve together. As you might guess, this is closely related to the principle of Shared Understanding I have written about before.

If your product mangers are working on one problem, your designers are designing a solution to solve another, and your developers are implementing a solution for a third, you don’t have a cross-functional team. You have siloed teams. It doesn’t matter if they occasionally talk to each other. It doesn’t matter if they sit together. You do NOT have a cross-functional team.

So let’s all do a process inventory. On your Sprint board are there stories representing all cross-functional work? Do you commit to stories across disciplines? Are the designers, PMs, developers, and anyone else on your team focused on solving the same outcome? Does the entire team participate in brainstorming and user research sessions? If not, your team is not achieving the results you could be. Are you evaluating employees on delivering value to customers together or on completing N story points this sprint?

If not, ask yourself this question: do you really want to deliver value to your customers quickly and reliably? Then create a truly Cross-Functional Team. Focus them on a single problem. Encourage them to brainstorm, commit, and learn together. The Shared Understanding the team will develop, the speed they will be able to move at, and the outcomes they will deliver to your customers will astound you. It’s what the Agile Manifesto has been trying to tell you for 17 years.

Like what you read? You might enjoy my article on Jobs To Be Done or Shared Understanding on Medium.

Have something to add? Connect with me to join the conversation or check out my portfolio to learn more about my work.