Shifting from Specific Profiles to Cross-functional Roles

Shifting from Specific Profiles to Cross-functional Roles

It’s all too common to hear that a project is using agile methodology, but when you take a closer look, you realize it is missing many key pieces. In my experience, one of the most ignored and important pillars of agile methodology has to do with cross-functional roles.

One of the biggest challenges is changing the mindsets of those involved, and shifting from specific, individualized roles to multi-dimensional teamwork is a lot to take in.

I’ve already written apost about how agile methodology should be incorporated throughout companies – not just in the technological sector, but also in the operational, administrative, and sales teams. But here, I’ll focus on how to start this transformation within the existing technical team. 

In traditional technical teams, people have tended to have specific, clearly defined roles. Analysts do analytics, designers design, developers build things. So when these teams venture forth into the domain of agile teamwork, they bring with them this idea of their specific role.

Often, they feel like they’re responsible for just one part of the project and even ignore what their colleagues are doing. In some corporate cultures, it’s even considered taboo to get involved with what’s outside your specific domain. 

But to be a truly agile team, you have to first rescue the concept of teamwork. Individual successes and failures are not more important than the entire result. After that comes accepting what it means to be a cross-functional team, which implies a cross-functional group of people collaborating as one.

But how do we fit those specialized roles into a job concept where there is no such classification?

Either we start this transformation process, sensitizing team members to the importance and benefits that everyone obtains with this new cross-functional practice, or we end up doing mini waterfall cycles of two to four weeks, with the same failure, bottlenecks and rework rates as before.

So, how do we initiate transformation from a specific role to a Cross-functional role?

The most important thing, as always, is honest and clear communication. The team is usually reluctant to make this change due to fear and uncertainty of the effort and time they'd have to spend learning new activities, which they may be unaware of and do not master.

Let's start by rebuffing some common taboos that are nothing more than bad practices. Although some of these are very convenient for the comfort and stability of some people on the team, they don't contribute anything positive to this transformation. 

  1. There is me and them

First things first, on the agile development team, there are no roles as such. There are no dedicated analysts, focused testers, or exclusive developers. To be truly cross-functional, we don't need individualistic roles, but cross-functional roles.

This doesn't mean that everyone will be experts in everything, but team members should be able and willing to switch hats every now and then between one type of activity and another. Here, the common purpose is delivering something valuable, functional, and finished end-to-end, not just pieces of the project that generate no value by themselves.

  1. 'Ctrl+Alt+Del’ habit and learn new things.

Having dedicated much of our working life to specializing in certain skills, it is difficult to accept this versatility. Why would I ever abandon my expertise to jump headfirst into something I haven’t got a clue about?

For starters, it’s not that dramatic. Although it may be that we suddenly have to deal with a learning curve, the good news is that the team has capable people who can help you and, over time, you will get to know the tools and will have sufficient knowledge to cover the basics and even more of the different activities required within a cross-functional team. 

The advantages are endless, and there is no reason to fear a possible replacement. Every team member will still be an expert in his or her particular areas and serve as a guide for others and as support, speeding up the constant progress and entirety of the stories. Another benefit is that any change in the team won’t be so difficult to adjust to because everyone is capable of handling the various tasks, perhaps not at the rate that the expert would, but enough to keep the project moving forward. 

  1. Experts vs Juniors.

Another huge taboo or bad practice that usually happens is this classification of activities according to experience, something like: “experts think and solve, while others only execute.” That is just another waterfall leftover, and couldn’t be further from the truth. Although in early stages this strategy could be a safe bet, it solidifies into a practice of mistrust and inequality and limits growth and communications.

In addition to becoming a high-risk issue due to the possible bottlenecks arising in the "thinking department,” we are limiting the potential of the entire team. This practice will almost certainly lead to a tense work environment, considering the significant stagnation in the professional growth of people with less experience and the blow to their self-esteem. 

The crack generated by this distribution of activities according to levels of experience is very delicate if not addressed – the team is demotivated, the product is neglected, knowledge is concentrated in a few hands and, in many cases, ends up being lost.

Agile is a strong proponent of teamwork. Some of the frameworks under the agile ideal promote work with peers, from pair programming to extreme programming. This helps to generate a natural knowledge transfer among team members working together and also promotes good practices like constant feedback and an efficient and timely testing process.

Remember that in a cross-functional team we can all fall into the category of experts and apprentices from time to time, so we must eliminate the tendency to restrict activities. To the contrary, we must try to promote the homogeneous growth of the team in terms of skills, responsibilities, and knowledge. 

We know what to do with what we master but, what do we do with what we do not master!?

Teamwork: Communicate! Ask and Share

  1. Use what you already know

This is not about being a business analyst for years and then suddenly becoming an expert developer that builds a set of stories by yourself. Think in little steps. For instance, you could lean in on your end-to-end knowledge of business rules to design functional tests. In doing so, you'd be switching hats from analyst to a developer, junior developer indeed, but developer nonetheless. You could even run those scripts yourself, switching hats again from analyst to tester.

  1. Don't fear, guide and trust your team

People are afraid of not being indispensable once everyone starts doing everything. But there is no reason to feel uncomfortable. The expertise of a tester, for example, goes far beyond just functional testing. The mastery of techniques and tools to identify risks and generate non-functional tests, such as safety, stress, performance, and quality, among other testing types, gives the testers the lead in their area. They will always be needed to provide guidance and share best practices.

Yet, this methodology gives them the opportunity to switch hats from a tester to an analyst, and build solid, realistic, and efficient acceptance criteria. By shifting into the developer role, they can provide unique insights when it comes to suggesting clean code. In the end, this cross-functional experience is highly valued in the labor market. 

  1. Expand your responsibilities naturally

Shredding a story in the early stages of the sprint, like in a refinement session, is a common scenario that sees developers switching hats to analysts. They could also make the shift during the sprint if more work is required and some stories are stuck on the board that requires further research because they are still at a very high level (epic or features). Developers will also be great analysts if the team needs more stories on the board or more acceptance criteria on the story.

Testing is usually difficult to complete if you are not involved in an agile real framework, so it is usually left as the very last activity on the sprint, just like in the old days of waterfall. What ends up happening is that the quality and quantity of the tests suffer due to lack of time. Of course, everyone can switch hats to testers – some teams do this, as a rule, every time a certain number of stories are accumulated in the 'ready to be tested' stage. It is part of the effort of becoming a true cross-functional member of a work-in-progress cross-functional team. 

  1. Embrace the challenge

More mature teams already know this motion of switching hats is expected on each sprint. That’s why they distribute their individual capacities into research, development, and testing tasks, as part of their end-to-end user story ownership.

The most difficult part is getting rid of these fears, taboos, and bad practices. You can do this by trusting that your team will support you in the areas that you don't master and supporting your team in the same way. It’s to be expected that the team's velocity will decrease on the sprints while adjusting, but eventually, knowledge will increase uniformly in the team. In the end, this will allow each person to accept more and more responsibilities and bring their unique perspectives to new challenges as part of their cross-functional scope.

Switch hats! Become a cross-functional team member.


Back to listNext Post