Cross-functional teams and self-organization in the heart of Agile, part 2

While the first article of this series was about Agile culture basics: its principles and values, prejudices about Agile — this one is going to be about cross-functional teams.

Cross-functional teams

Speaking about cross-functional teams, we may often face lack of understanding and even some misinterpretations of the approach.

The term itself comes from the Scrum framework. However, many projects all around the globe and my personal experience have both proven that approach to be the best way to provide on-time delivery of high-quality solutions while optimising the delivery flow and eliminating impediments. These are the basic principles of Kanban and Lean, so it gives us a right to declare that cross-functional team forming approach can be applied in other Agile frameworks.

For those of you looking for the term’s definition I highly recommend the one given by the Scrum Guide:

Scrum Teams are self-organizing and cross-functional… Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.

First of all, it means that to be really “cross-functional” a team should be formed not only with technical specialists (Back-end, Front-end developers, QA engineers, etc.). Such team should include Business Analysts, Marketing and UX specialists or anyone else taking an active part in the project. It gives us an opportunity to fulfil the following:

The team model in Scrum is designed to optimize flexibility, creativity, and productivity.

Roles in a cross-functional team

What roles do cross-functional teams provide? Since we have already started working with the Scrum Guide, let’s take a Scrum team as an example:

The Product Owner — is responsible for the product: forming requirements, roadmap and release planning, working with the backlog and feedback loops, negotiating stakeholders;

The Scrum Master — helps a PO and team to establish and develop Agile mindset: following Scrum rules, making adjustments, events facilitation, resolving conflicts and impediments;

The Development Team — Back-end/Front-end/Mobile developers, UX/UI specialists, QA engineers, Business Analysts, etc.

It is essential that there is no division based on “responsibilities” or grades within a Development Team — every team member has equal rights and is a part of any team’s success or failure. That’s why some teams may have no dedicated QA specialist. To maintain a high quality of the product, many teams apply specialised development practices, e.g. Test-Driven Development(TDD) and Pair Programming taken from the Extreme Programming (XP) framework.

Possibility to use any tool or technique that team finds useful is another advantage of Agile.

Cross-functional team forming approach can be applied in any Agile framework, but you should always remember about the team size limitations. It isn’t formal, and you may not follow the one given in the Scrum Guide (3–9 team members), but don’t forget about the formula from the Project Management Body of Knowledge (PMBOK):

A total number of Communication Channels will be n(n-1)/2, where “n” is an amount of people participating in the project.

It means that a team consisting of 10 members, total number of Communication Channels will be 45; 36 for a team of 9 and so on. It is easy to prove. Every team usually uses at least these 4 Communication Channels:

1) Verbal communication;
2) E-mail;
3) Messenger (Slack, Telegram, Skype, etc.);
4) Issue tracker (Jira, Redmine, Asana, etc.).

Add comments from your SVN system, additional messengers your team can apply and this number will become even bigger.

In my humble opinion, an optimal team size is 5+/-2. But remember that Scrum puts Scrum Master and Product Owner outside the Development Team (they are a part of the Scrum Team).

Advantages of the cross-functionality

What benefits does cross-functionality give?

To answer that question, let’s get back to our list of Agile principles that we have discovered in the previous article. Using cross-functional team forming approach, we make half of them possible:

• Quick hypothesis testing — having all required specialists on board, team is able to go through all feature development stages (analytics > design > development > testing > deploy) in one short iteration, e.g. during one Sprint in Scrum. Applying CI/CD and metrics gathering automation is another great leap forward;
• Frequent product delivery — balanced team is able to make development stages predictable and increases our chances of on-time delivery;
• Transparency is achieved through the events that make team gathering and communication frequent. Almost every Agile framework offers regular activities that foster the spirit of collaboration and shared understanding within the team, e.g. Daily Scrum. Scrum Master or manager may facilitate these events to make them more productive and useful. In fact, he is ought to do this until his team becomes mature;
• Equality of participants — activities such as Sprint planning and Retrospective develop the culture of equality between the team members. But it’s a Scrum Master’s work to make everyone take part in a conversation and listen to others. Of course, when we speak about some technical decision, Team Lead’s or Senior’s opinion is going to be more relevant than Junior’s one, but it should not stop Junior from expressing his opinion or possible solution.

Gathering a cross-functional “dream team”

It is impossible to come up with some “silver bullet” advice or solution about team composure, but I’ll try to provide you with some recommendations and tools that may help you to form the best possible cross-functional team for your project or product.

These factors should help you to make sure that everyone you need is on board:

• Product Roadmap — it is impossible to form a relevant team without such things as product’s vision and goals and long-term product development forecast. Of course, this forecast AKA Roadmap should be revised and updated regularly basing on new inputs and gathered feedback;
• Team’s Backlog — to make requirements and expected result clear to the team, the closest short-term part of a Roadmap should be converted into User Stories or technical tasks, depending on the framework you use and your own needs. The process of making and keeping it prioritised, estimated and cut into releases may be done by a Product Owner/Manager himself, but it’s much better to collaborate actively with a team;
• Minimum external dependencies are achieved with team’s cross-functional composure. The less external dependencies you have, the lower will be the rate of forecasts failure due to lack of QA specialists, UI components or even content translations;
• Balanced team composure — usually there is no need in having two QA Engineers for a team including only three developers. Making up a team of Junior developers only is also a bad idea. Even if they can achieve real cross-functionality, someday that may bring a crucial architectural problem that kills your product;
• The general level of Agile culture in a company — it is impossible to create a really efficient cross-functional team in a non-Agile environment. Even the best team will start failing often if it regularly face a frequent priorities or scope change. And you definitely won’t be able to apply some team rotation practices if no one else in a company understands practices and tools you apply.

I hope you have managed to find some useful information about cross-functional team forming approach and its benefits in this article. The next article will be about a self-organization principle, lying in the heart of cross-functional teams.

To be continued…