The story of our experiment with Cross-functional teams (with a few tips!)

Before we start

Cross…what?

A cross-functional team is a group of people with different functional expertise working toward a common goal. It may include people from finance, marketing, operations, and human resources departments; basically everyone needed to achieve the goal.

Why bother?

In Agile, cross-functional teams are advocated as the best way to reach a goal, usually a delivery of a new functionality for a product. There are several advantages to cross-functional teams as opposed to siloed teams. A few of them are:

  • better and easier communication;
  • more accountability;
  • increased throughput.

With regards to the latter, the reason why the throughput is improved is that cross-functional teams reduce the number of queues, that are a known performance killer.

Where we started from

In our case we had a mobile front-end team, working with the Scrum framework, and a separate back-end team, using Kanban.

The challenges we wanted to address

challenges

The challenges we wanted to address

The problems that we wanted to address were, for the back-end team:

  • Technical stories. Since the back-end team was responsible for the API it was hard for the Product Owner to prioritize the stories and for the team to showcase business and customer value;
  • A “pool of resources”. Since the team was a component team (see what the LeSS framework has to say on component teams vs feature teams), they ended up being allocated and moved around, according to a logic of maximizing individual occupancy. What’s the problem with this? Kanban teaches us that maximizing the work of an individual doesn’t necessarily improve the team performance, actually a bit of slack might indeed improve the team performance.

In many occasions, the front-end and back-end teams were working in a desynchronized fashion and with different goals. These were the consequences for the front-end team:

  • Difficult planning. Before the start of the sprint they had to check with the back-end team if the needed endpoints would have been ready or not; in the worst case the front-end team ended up being blocked during a sprint for an unforeseen dependency;
  • Reduced throughput. Sometimes the front-end team had no choice but to start the work without the API endpoints ready or finalized. This caused rework as they had to resort to mocks, a fuzzy definition of done and difficulty in planning testing.

What we’ve done

merging

Merging teams

We decided to merge the two teams. Since the two teams were working on different frameworks, the mobile with a Scaled Scrum (LeSS), the back-end with Kanban, we had a session together. In this meeting the back-end team got to know the concepts of LeSS, while the front-end learned how the back-end team was using their Kanban board. The outcome was:

  • The fron-end team adopted the back-end team Kanban board, with more columns to better visualize the flow of work;
  • The back-end guys agreed to be part of all the ceremonies of Scrum, together with the front-end guys;
  • To foster communication we changed the seat assignment so that we all could be close;
  • The back-end guys agreed to use Story Points for their estimations;
  • In a second stage we decided to have full vertical user stories, with tasks for the back-end work and the front-end work. We also agreed to try pairing on these stories.

Learnings and benefits

Working in a cross-functional team has increased the team ability to split and refine stories and to quickly identify and break possible dependencies.
The collaboration between front-end and back-end in the definition of the API contract, for the new services, ensured higher quality and no surprises later on during development.
Finally pairing and refining all the stories together was a great boost for knowledge sharing and learning chances for both parties.

The challenges during the experiment

challenges

The challenges during the experiment

A new way of working

Working on vertical stories proved to be more time consuming than we thought. People that had never worked together were now pairing. Also they were using different technologies (iOS front-end, C# back-end), so this was also not great for performance. This anyway got better with practise.

Timing and too many changes

The timing also was not the best, especially for the front-end team. They were a pretty recently formed team, still struggling with the difficulties of sorting out the dynamics of a new team. Also, they were working on a new product increment, with a tight timeline, a new architecture, on a code base presenting a good amount of technical debt and fairly unknown. This caused a lot of uncertainty and low predictability, as there was actually no one in the team that had a firm grasp of the functional requirements and the technical challenges.

Mindset and alignment

From the mindset point of view, the teams didn’t really gel, they kept being two sub-teams Reasons behind this might be:

  • the OKRs and the reporting lines were not unified consistently;
  • the back-end team was not focused only on mobile but was also carrying over some work for other teams.

Our tips for your journey towards cross functionality

try

Our tips

After this experience, we would share our learning. So here are our suggestions if you want to move to cross-functional teams merging two component teams or people from different part of the organization:

  • Keep the experiment small and controlled. Avoid changing too many things at the same time;
  • if you merge two or more teams: make sure these teams have already reached the performance stage;
  • Make sure the reporting lines and goals are unified and consistent; this will imply an involvement of business and product people and the goal of the change has to be visible, shared and understood;
  • Choose a product increment that is not tight in terms of deadlines; making the new cross-functional team succeed will require time and determination from everyone involved, so be in a position where people know that it’s not a problem if they’re being less performant for a while: they need time to learn and adjust;
  • Big teams are not efficient. If the cross-functional team you’re creating is too big (more than 8 people) you might want to scale it; how to do that? My suggestions would be to use the LeSS framework.

Wrapping up

Do you have an experience with cross-functional teams to share? Have a question to ask?
Please get in touch or comment the post, we’d like to hear from you!

Credits

I have written this article with the help and feedback from Nicole De La Feld, esteemed colleague and iOS Engineer in the front-end team.