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 by cross-functionality? People in software understand this to mean different kinds of developers (e.g. back-end and front-end experts) and testers working together on the same features/user stories. And there is even some business knowledge in the team via the Product Owner. This is fine, but it 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”.

If a company decides one Agile team isn’t enough, it will invest in different shifts. And some of those other shifts require implementing real cross-functional teams. This means that the whole team has 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 is overcoming 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 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. For the Scrum teams, the leap means that they can’t “hide” behind their backlog or the Product Owner and 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.

Another example: a large charity, a university, a construction company. What would a cross-functional team look like in one of those organizations? First, the organization might have classic stovepipes. Schools of a university would 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 whether the team really mirror the overall organization in its assignment and authorized scope of action. Are additional skills or more empowerment needed to make the team mirror the whole?

Authors

This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.