If you want your cross-functional teams to be successful, the first thing you need to do is to make sure that your organization can adapt. The software you create reinforces the culture of your company.
Agility is not the goal: it’s a method to solve a problem. Since the external environment can change faster than a company itself, it may need to change its pace as well. But it isn’t about sending out an email to all employees that the organization applies Scrum starting from next week: the transformation must happen on all levels. You need to make sure that there aren’t any roadblocks within your company that could slow down the speed of information. This applies to everything from feedback loops to knowledge centers that everyone can access, so they don’t need to spend time looking for the information they want to use.
Company culture must be prepared to support the transformation and adapt agile practices. Most people try to avoid being part of the ‘company transformation process’ since mass layoffs usually accompany it. Give people time to adapt and the resources to make it easier for them. Also, if you try to transform the middle managers into coaches first, they can support their colleagues well.
Functional vs cross-functional teams
A team completely owns a product during its whole lifetime. They don’t just create it, they are also responsible for maintaining it. This makes cross-functional teams perfect candidates for building microservices.
In project management, products are the formal definition of the project deliverables that make up or contribute to delivering the objectives of the project.
Separating teams by functions creates distance between them. If a separate QA team does the testing and developers are strictly focusing on writing code, they often don’t care much about testing and your product can end up with a lot of features that don’t work properly. A cross-functional team has individuals with different roles like database engineers, testers, infrastructure engineers, etc. As we can see from numerous examples (such as Amazon, Netflix, and Gilt for example), this can result in an excellent product that works as intended and the users love it.
Functional (or often called “siloed”) departments often adopt an “us vs. them” thinking against other teams. Instead of better productivity, this is more likely to result in hostility against each other. Working with people from different backgrounds also enables you to view the project from a different point of view. This helps understand the real reason behind a conflict and resolve (or even prevent) it.
Project: a piece of code that has to offer some predefined business value, must be handed over to the client, and is then periodically maintained by a team.
Cross-functional teams can ship code faster than functional teams because they can make their own decisions and work independently within an organization. The teams can focus on improving their cycle time and implement continuous deployment in order to solve the challenges they face almost instantly.
Teams can be formed by a manager or by the team itself. In both cases there is an important question that needs to be answered: how should people be grouped together? The two options are by similar function or by similar business.
Similar function
Grouping by similar function means that managers work with other managers, engineers with engineers, or marketers with fellow marketers. Melvin Conway’s law states that “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” This is as true today as it was half a century ago. These are called functional units. They work the best if you can manage to hire the best people to build a superb team of specialists who are truly experts in their own field. The similar community enables them to learn from each other to master their job. The biggest challenge is that departments usually have difficulties when communicating with each other. For example, if the task of the UI team is to do an overhaul of the interface but the backend guys are still in the middle of something else, then the whole project will be delayed until the backend tasks are done - since the UI team can't even start the project.
Watch out for these signals. Constantly ordering work across capabilities, splitting stories between teams, having to move people around towards tasks, deploying in lock-step and fan-in for end-to-end testing all mean that Conway’s law is in effect in your organization.
Similar business
In this case, the people work together to deliver the same business value: a new feature a new project, or even a new product.
The teams need to be stable enough to get the job done and in exchange, they can move faster and more efficiently than teams grouped by similar functions. The communication is more likely to be oriented around the goal itself and not around the communication or management issues
across functional units, making this approach more efficient.
Challenges
Nearly 75% of cross-functional teams have challenges with at least three of the following five criteria, according to Harvard Business Review:
- meeting a planned budget
- staying on schedule
- adhering to specifications
- meeting customer expectations
- maintaining alignment with the company’s corporate goals
The Kanban community points out that reorganizing already established teams can cost a lot more without having a system to organize the tasks for the teams. Before you decide to reorganize your whole company it may be worth to take a look at what already works and what doesn’t. If the not-so-optimal pace of the organization originates from the confused state of tasks on a low-level, then the reorganization itself won’t do much.
Building microservices
Microservices should be:
- cheap to replace;
- quick to scale;
- fault tolerant;
Above all: they should allow you to go as fast as possible.
Siloed teams spend weeks with iterations. Because the teams build tightly coupled services, manual tests need to be performed at the same time for all services. This is far from going fast: the tests can often last for weeks.
The first steps towards cross-functional teams
When building microservices, teams can be organized around a single business purpose, and focus on continuous delivery to skip the long-lasting test periods.
Continuous delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.
To achieve this, you need a collaborative working environment for everyone involved in delivery. This environment is the first step to have cross-functional teams.
What it means in practice: merge architects, testers, operations and development teams into a single (no bigger than 10-20 people) cross-functional team. This way, teams don’t have to pass a project around until they get the feedback they need, and delivering services don’t need to happen once in weeks.
James Lewis recommends using these best practices on the different levels within your organization:
- Top-layer, at the line of business (across the whole company)
- semantic versioning (define a major version of the software that every team can use within the company)
- Value streams (group of teams within an organization that can deliver business value to the customer)
- semantic versioning
- consumer-driven contract testing
- Inter-team layer (relationship between the individual teams)
- tolerant reader
- consumer-driven contract testing
How to make cross-functional teams efficient
To make cross-functional teams truly effective, they have to be able to operate independently. This way, the unit can complete a project or even a whole feature without requiring regular coordination or micromanagement. Of course, you need to know about what’s going on, but if the goals are clearly set, you don’t need to interfere, and all the tasks get done in time. There can be someone that reports to the VP’s or C-level executives, but the QA managers and the other mid-level managers are not a must anymore.
Constant re-evaluation assures that you’re making progress. If the market changes faster than a project develops, it may be necessary to kill it to save precious resources and divert them to another project that could achieve greater results within the same period. It’s not an easy thing to do, but it’s not worth to chase something into a dead end only to find out that you need to turn back.
The optimal size of a microservice is not necessarily ‘micro’. Amazon uses the size that a ‘two-pizza team’ (around a dozen people) can maintain, but there are setups where half a dozen people support half a dozen services. The concept of self-contained systems suggests using services larger than a microservice but still small enough to keep a team busy and provide meaningful value.
Netflix
Netflix decided to go with highly aligned and loosely coupled teams. The company set clear, specific, and broadly understood goals. The interactions between teams are focused on strategy and objectives, not tactics. Although it requires a large investment in management time to be transparent, they feel it was worth it.
Their teams try to keep meetings at the minimum. This is possible because the teams truly trust each other - without requiring layers of approvals. The leaders reach out proactively to help whenever they feel it’s appropriate and don’t focus on supervising each task of the team members.
Cisco
Cross-functional teams need a good project manager more than anything else. Cisco implemented a 3-layer structure: a group of specialists working on their tasks, a smaller core of people who communicate back to their teams and two vice presidents at the top. The conclusion was that every project should have an end-to-end leader who oversees the whole operation, and the individual teams should also have a leader as well. If the goals are clearly established, this setup helps to make sure that the teams won’t miss them.
Takeaways
- The success with microservices isn’t just about using the right cloud service or container system. Organizations that embrace cross-functional teams can scale more quickly than a company with siloed teams trying to move to a microservice-based architecture. The key for that is effective communication: the right information goes to the right place at the right time.
- Teams building microservices need sophisticated monitoring and logging setups for each service to keep track of both operational and business metrics. Trace allows you to measure both.
- Conway’s law creates a loop: teams not just create a software that mirrors the structure of the organization, but it also reinforces the existing hierarchy.
- Open source projects are a good example to follow: people work together from different functions towards a mutual goal. These projects also follow Conway’s law and become modular and easy to scale.
Our recently published report aims to address questions of Node.js adoption into enterprise organizations for cross-functional teams.