From Good to Great: Cross-Functional Teams

Next blog in the “From Good to Great” series (Don’t Copy Find Your Own Way, Radical Transparency, Agile Mindset, and Collaboration) is focusing on cross-functional teams. It seems like basics, but I realized that organizations still don’t fully understand why the cross-functional teams are critical to Agile and Scrum success. I guess it is grounded in the fundamental mindset shift, where the organizational focus is moving from functionality driven to the value driven. In traditional organizations, the delivery of functionality was the key. That’s what we focused on and that’s what we measure. It’s the world of allocation and reworks caused by misalignment which all over creates so many dependencies, that delivering end to end feature is a nightmare and takes forever.

Component teams

Business value

In agile organizations, the focus is changing to deliver business value. And here is the problem. Business value is hard to measure before you get feedback from the customers and users. There is no formula. All you have to do is to get feedback fast and inspect and adapt based on that. And here we are: the cross-functional team is an enabler of fast feedback as there is no way users will give you quality feedback on the backend or one system change while they have a hard time to imagine what does it mean for them. They give feedback on the end to end functionality, that actually often goes across all the technologies and systems in your organization. As such, teams need to be able to deliver value end to end. Otherwise, you are mentally at the manufacturing line where teams work in sequential mode and trying to parallelize this work creates so many dependencies that are making your life hell and preventing teams to focus on the value. They micro-focus on the part of functionality without seeing the whole and the feedback will suffer.

Cross-functional teams

The typical misunderstanding is that cross-functional team means that everyone needs to be expert on everything. But that’s not needed. All we need to have is a team willing to learn and take over responsibility for the end to end value delivery. A team, which can take any item from the backlog (which is end-to-end functionality which brings the value by the definition) and finish it together. They don’t need to take it as individuals, they collaborate as a team. In most of the cases, it’s not that hard in reality once you overcome the initial resistance of team members and the overspecialization mindset of the organization. Try it, and see that I was right :).

Impact

In addition to what has been said, we don’t do functionality because we can, we don’t do it because we believe there is a value, we implement it as we expect something to happen. It is impact driven, strategic approach. And that’s a game changer. In order to be able to measure impact, we need to be able to deliver working product frequently so you can really see how different functionalities changing people behavior. And to do that, cross-functional teams are the essential enabler.

During their agile journey, companies often ask what shall we do if we can’t have cross-functional teams. And the truth is I don’t know, except make it happen. It only needs courage and focus, which are two of the Scrum values after all so nothing new. All over, Agile without cross-functional teams is only empty process, kind of a fake agile where we are using the terminology but not changing the mindset at all.

From Good to Great: Don’t Copy, Find Your Own Way

Agile become part of our lives and you can see some sort of “Agile” in every other company, but still, many companies are failing to be Agile and understand the mindset. Ron Jeffries talks about “Dark Scrum” for years and I see more and more frustrated people around than ever. So why are the companies failing?

The most appealing way how to fail is to copy someone. When it worked somewhere else, why shall we take a hard time trying to invent it ourselves when we can just apply it. It usually starts with a big push from the top and has often wrong expectation from such a change. Being Agile is going to be hard, you might not see the results right away, and renaming a few roles and departments would not be enough.

Instead, you need to start from the bottom, get the experience from the teams, learn on the way through your own failures, do experiments, have the courage to do things differently. At some time, when you got used to this way of working at the team level and can imagine what needs to change in the business, systems architecture, culture, and organizational design, you might need to get ready to the next step – scaling.

Which to tell you the truth shall be called ‘descaling’ instead as in order to work, you need to turn the organization around and build it around the cross-functional teams who can actually deliver value end to end. Be business value driven, customer-centric. Hold on, yes, you need to understand what the business value actually is and think about the organizational purpose which is matching that value at the same time. Why are you here as an organization, and what would happen if you disappear from the market tomorrow? Would someone miss you? Are your employees living that purpose?

Having the evolutionary purpose is an enabler for Agile culture to finally settle down and stick. Only then, when you have a higher purpose, you can talk about truly being Agile and forming the Agile organization. How many ideal organizations I’ve seen? None. How many companies I’ve seen, being on this Agile journey? Hopefully enough to demonstrate that we can make it. Give us the light at the end of the tunnel that we can actually turn the organization around and make it a better place to be. Make work fun again. It’s not about being ideal, Agile is about inspecting and adapting, learning from experiments, learning from failures. So instead of looking for some ideal organizations to copy, how about if we start with ourselves, get the courage to do things differently. Be brave. Be Agile.