Yes, Cross-functional Teams, but Real Ones!

If you start with Agile, one of the first things you typically do is come up with a team. And yes of course, the team will be cross-functional. But what’s actually meant with cross-functionality? At first people (in software) understand this as different kind of developers (e.g. backend & front end experts) and also testers are working together on the same features / user stories. And, there is even some business knowledge in the team through the product owner. That is fine, but this is only a start. In fact, if you check with the Agile Fluency™ Model this is the first shift for your agile journey and is called the ‘Team Culture Shift’.

Yet, if a company decides an agile team isn’t enough, it will invest in a different shift. And some of those other shifts require implementing real cross-functional teams. Meaning, the whole team has the full business expertise, knows the market, can even disrupt the market and isn’t waiting for some person (e.g. the Product Owner) to decide on priorities. It also means the team fully understands the company’s business and has a holistic view of it, knowing its contribution to the company’s value stream. Thus, a cross-functional team overcomes the limitations of the classic stovepipes in organizations.

Like a lot of other companies, one of our clients, an insurance company, is currently facing the challenge of digitalization. They now understand that digitalization means software is their product and no longer insurance policies. In this company, the teams in software are using Scrum. Next to software there is the business experts and the mathematicians who have the domain knowledge about insurance. The next leap is bringing these different units together (not only through the interface of the Product Owner) to form teams that are actually as knowledgeable about business, contracts, mathematics, sales, marketing, and everything else that is relevant for the company’s value stream as they are in software. The leap means for the Scrum teams that they can’t “hide” behind their backlog or the Product Owner, but need to explore and learn about the market, their customers, and the company’s value stream themselves. Basically it means that now the agile teams’ focus is beyond software.

Agile Teams

Other examples: a large charity, a university, a construction company. What would cross-functional teams look like in one of those organizations? First, the organization might have classic stovepipes. Schools of a university would, for example, focus on music, or English, or economics, or agriculture, and so forth. They would publish in different professional journals and be invited to attend totally different professional conferences. Thus, a cross-functional team at a university might include professors from widely different schools as well as representatives from the administration. But, what would they focus on? Their customers of course! Their customers would include students, the various professions and industries they serve, and also the other members of the university. They would produce insights gained by combining their studies. (Note: this output would be something other than the classic survey course for freshmen that might look at a topic from the standpoint of various disciplines but rather a real synthesis of those disciplines.)

As can be learned from the Agile Fluency Model, it is fine to start with cross-functional teams that span the different software expertise and support these teams with some business know-how. Yet, if you are thinking of implementing company-wide agility, the expertise of real cross-functional teams spans beyond software and comprehends the whole value stream. In order to do so, ask, does the team really mirror our overall organization in its assignment and authorized scope of action? Are additional skills or more empowerment needed to make the team mirror the whole?