Hi there,

The topic for my next blog post has been right under my nose this whole time. For the past five months of working as a Scrum Master at Ericsson Supply Site Tallinn, I’ve been practicing agile, observing and modifying the way my teams are working. As a result of my observations, I’ve come up with an organisational change project to introduce my department to the new setup of the teams that can eventually benefit our WoW by removing communication barriers, focusing on the project goals, creating a team vision and spirit. The new setup will ultimately turn the current functional teams into cross-functional dedicated teams. Bear with me, take a cup of tea or coffee, and enjoy the reading.

Difference between functional and cross-functional teams

Let us start with the basic definitions. So, what is the difference between functional and cross-functional teams?

If people in your teams are grouped by function, for instance, engineers with engineers, project managers with project managers, developers with developers, then you have functional teams.

On the other hand, the teams can also be grouped by the same project/product, feature, client etc. In such a group, there can be different roles all together working towards the same goal. These teams are often called cross-functional.

Depending on what you want to improve, teams can be grouped either way. If it is efficiency and competence development you are looking for, then functional teams can be the best choice. However, nowadays, companies are becoming more agile and project-oriented, which creates a higher demand for cross-functionality in teams.

Why it is a good idea to become cross-functional

As I have mentioned in the beginning, the main areas which are affected by the team structure are communication channels, project/product goals, team spirit and vision.

Let’s first focus on the communication aspect. We all know that an organisation must have a good communication flow between the teams/departments/customer to ensure that business value is delivered. I’ve been analysing daily communication in my teams for the past five months, and it was clear that it is mostly project-oriented. People with different functions working on the same projects need to communicate more frequently than people with the same functions who work on different projects.

The second aspect is the fact that project goals are diluted when people are working on the individual tasks being in the same team with colleagues who have tasks of other projects. This separation also affects a team spirit and vision negatively because they are together but apart with no image to unite them. Having a dedicated cross-functional team may create a sense of ownership of the group, a sense of being a part of something important, delivering value to the customer.

It has been reported that in organisations where people are grouped by function (sometimes referred to as functional silos), there are too many dependencies between the functional teams. Delivering even the smallest piece of business value (like one feature of a product) requires communication and coordination across multiple teams. Functional silos, therefore, have a high interaction penalty. (Appelo, 2010)

Indeed, there are issues with cross-functional teams as well. Limited competence development within one functional discipline and poor coordination between these teams are the most crucial ones.

However, these issues don’t look like a hefty price to pay when converting to cross-functionality. Especially when there are solutions to overcome these issues. In terms of competence development, it would be a good idea to come up with a ‘shuffle rule’. Once in 3 months, some team members in need of skills development can change their teams. That way, we can avoid the issue of a team member leaving the project, and lack of skilled staff.

Coordination problem can be solved an excellent agile way which is ‘Scrum of Scrums’. ‘Scrum of Scrums’ is a framework to keep different teams connected, to share and align technical knowledge and any process changes. A representative from each team will be chosen to participate in the daily standup, which will synchronise the teams’ work within the department/organisation.

A separate tech leads team can be created where they can make sure that the actions of one team don’t affect the other groups technically. The team will consist of the most experienced people from each function, and they can meet weekly or bi-weekly discussing technical traits of projects, dependencies, issues, ideas etc.

How did I start implementing the change in my department?

The hardest part of every task is to start. However, once you made the 1st step, it gets easier — that what gave the motivation to begin with this organisational change towards agility and cross-functional teams.

I knew that to make a strong statement I had to have something on hand, some initial sketch and draft presentation of my business case that will generate the interest and feedback. So, I’ve prepared materials and arranged the meeting first with my line manager.

In the sketch, each cross-functional team consists of team members from two departments (test development and hardware design), Product Owner, Team Lead and a Scrum Master/Agile Lead. However, some teams may have several product owners due to the nature of the products and the number of team members. Unfortunately, can’t share the actual sketch with you, but here is the approximate structure on the image below.

Fortunately, my manager is an open-minded person who took my initiative very positively and encouraged me to continue enhancing the teams’ setup sketch and have some more meetings with other stakeholders that are going to be affected by this change.

And so, I’ve had consecutive separate meetings with managers, with key players within the department, with products owners and also with senior engineers. I have gathered data on who works on what in another department which helped me with the allocation of team members into relevant project teams. Each time I got useful feedback, challenging questions and better ideas on how to improve the sketch.

There were different challenges with this new setup, such as different departments (in my case hardware design and test development) have different working timelines. Sprints are longer for hardware team than for test development — multiple people working on numerous projects which makes it harder to create dedicated teams.

Another issue is that some teams can become too big as the organisation is putting more effort on a particular project at the moment whilst other groups are small, manageable and stable.

Despite all these issues, we still decided to try it out. First, start with two more or less clearly defined pilot cross-functional teams and in 1-2 months measure the results (NPS survey, error reports, yield reports, etc.).

It is not over

This blog post is not a success story (yet!). It is a comprehensive analysis of my findings, challenges and solutions for anyone who is thinking to implement the same change in their organisation. The story is not over yet; I will update you guys when I reach the next significant milestone which would be the results of the implementation of the 1st two pilot cross-functional teams and what my next steps are going to be.

I hope you enjoyed the reading, made some notes for yourself and have exciting feedback for me! I’ll gladly read them and reply; you’re welcome to some good thought-sharing.

Cheers and thanks for your time,

Ayten

References

Appelo, J., 2010. Management 3.0: Leading Agile Developers, Developing Agile Leaders. s.l.:Addison-Wesley Professional..