Agile - Beyond Roles and Job Descriptions

When we talk about Agile, we usually say it is a mindset meant to address complex problems. We deal with complex situations when it is impossible to identify the “correct” solution in advance, no matter how much analysis or planning we do. Due to the inherent uncertainty of the problem, the best approach is to “probe, sense and respond” or, in other words, “experiment, inspect and adapt”.

Since we don’t know the solution at the beginning, it will continually evolve, and so must do the teams and the people building it. Roles in the team cannot be rigid anymore and people cannot simply work according to their job description. They must be flexible and adapt to the new problems they face “daily”.

When we accept to evolve our mindset beyond fixed roles and job descriptions, we start to think of individuals bringing various skills to the team and adjusting these skills over time. People will need to diversify their skills to remain competitive on the market and not rely on a single skill that could become obsolete. In the same lines as an investment portfolio, we can think of it as a?skills portfolio?(term coming from the Professional Agile Leader book). Some of our skills (or investments) bring value today, and we invest in some others that might become more valuable in the future. We might also let go the ones that have no valuable future anymore.

You might have heard of this concept as X-shaped individuals. Different sources have different definitions for each of the letters, but they usually go along these lines:

• I-shaped?individuals are very specialized. They do one thing, and they do it extremely well. They have limited interests or skills to support colleagues in other functions. Example: C# programmer focused exclusively on backend development.
• T-shaped?individuals have a (vertical) specialization, but they are also (horizontal) generalists. They can support colleagues in other functions with non-advanced tasks. Example: C# programmer who is also able to automate basic test cases.
• M/π/E/comb-shaped?individuals have multiple (vertical) “specializations”. They have a deep understanding and expertise in multiple areas and can contribute as different “roles”. Example: Team member who is able to write quality C# code, create advanced automated test cases and write challenging SQL queries.

How Is This Related to Agile Teams

Agile promotes collaboration. Having a wider understanding of the work everyone is doing in the team helps collaborate more effectively, exchange ideas, learn from each other and understand what our colleagues expect from us.

Scrum, in addition to calling everyone who contributes to the product a “Developer” to remove the focus on the roles, even?prescribes?cross-functional teams. From the?Scrum Guide:

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.

While this applies to teams and not individuals, in most cases a team made exclusively of specialists would be too large to be effective, especially if we need to have more than one person for each role. In these cases, a lack of cross-functional individuals leads to a lack of cross-functional teams, which creates silos and prevents Scrum from working as intended.

Even if the team has all the skills required to create the increment, the workload for each function is not going to be the same all the time. There might be too much work for the testing specialists in a Sprint, and not enough in the next one. A typical, but adverse workaround for this issue is to plan the Sprint according to the load of each individual rather than selecting the most valuable items based on the Sprint Goal.

Grow Yourself and Your Employees as Multi-Skilled

The main prerequisites to grow as multi-skilled individuals are mindset and curiosity. You can lead a horse to water, but you can’t make him drink. Some people like to continuously discover new things, some others are more comfortable doing only what they master. If you are in a manager position, try to understand why your employees don’t seem interested in learning new skills. It might be a personal trait, or they might feel they have to pretend they know everything. They might also be too busy to learn or they could feel they would not look busy enough if they can afford to invest in themselves.

Using practices such as pair working or peer reviews can be great techniques to grow new skills, build a shared understanding in the team and create a culture of collective ownership. If these practices are not used in the team, discuss with your colleagues if it could be something worth trying. Experiments tend to be better than opinions and trying something new doesn’t mean you have to commit to it. If you are in a manager position, try to understand why these practices are not adopted in your teams. Did your employees decide not to use them because they don’t work for them, or are they afraid it might look too expensive (see The Costs and Benefits of Pair Programming) to have two developers working together? Do you have a culture of trust and knowledge sharing in the team, or do people feel they need to “defend their territory” to be seen as irreplaceable? Having a team-driven skills matrix can also help finding great opportunities for mentoring and learning within the team.

If you are in a manager position, also see yourself as a skills developer. Coach people to understand they own their skills, and they should invest in themselves. Also allocate time for your employees to learn, help them find opportunities and reward exploration and cross-skilling. Lastly, lead by example and show that you are continuously learning as well, and you learn outside of your main skills area.

I frequently use the following quote from Andrew Clay Shafer:

You are either building a learning organization, or you will be losing to someone who is.

When speaking about individuals and skills, I like to adjust it to:

You are either a learning individual, or you will be losing to someone who is.

--

Carlo Criniti is an Agile Coach & Trainer at Credit Suisse. He trains and coaches leaders to transition organizations to an Agile way of working and teams to adopt practices that will increase their satisfaction and enable them to deliver more value.

Disclaimer:?The?views?and opinions expressed in this article?are?those of the author and?do not?necessarily?reflect?the official policy or position of?his current or past employers.