Ever since it’s inception in 2001, the Agile Manifesto has been utilised successfully by many teams to deliver various projects and has been adopted as the favoured approach for software delivery teams. However, even before the Agile Manifesto was written, Agile ways of working were being used.
Agile teams are those who deliver work packages in small and iterative ways, favouring showing something tangible and learning from the feedback rather than waiting until large swathes of work have been completed. This allows the teams to find out that something was built incorrectly earlier, before a lot of time has been wasted, or alternatively, identify an opportunity which can be pursued more promptly.
As far back as the 1990s, mentions can be found of recommendations that agile teams should be ”cross-functional”, but what does this mean and how do you know if your team is cross-functional? Read on to find out more.
What is a cross-functional agile team?
Cross-functional teams are teams comprised of people who have skills in multiple disciplines with the ideal team having all the skills necessary to complete what they need to in order to finish their work, without unnecessary harmful dependencies.
Fast forward to the current day and cross-functionality is a cornerstone of many agile frameworks. It is beneficial to implement a scaled Agile framework since new teams may be too large to execute Scrum or other development frameworks effectively.
However, care should be taken to limit the scope of cross-functionality to a sensible and proportionate amount. For example, a small cake-making shop would want to have someone who could bake, add frosting, and make fillings, but would not want to employ someone as part of the team who could fix or construct ovens (at least, not whilst the company is small!). Not every dependency needs to be mitigated in this way.
Dependencies: always a bad thing?
We all depend on others from time to time, despite what some commentators say. If a team had no dependencies and was cross-functional, the entire company would be on it.
Some product-focused startups or smaller companies can operate this way for a time. In startup or pre-revenue companies, the CEO attends daily product team meetings to ensure everyone has the answers they need.
"Company as one team" only scales so far, and when C-level stakeholders have more than three or four team meetings a day, it becomes unmanageable.
Unhealthy or unsustainable dependencies cause problems. Dependencies are a problem when the dependent capability isn't timely or robust. This affects other teams' delivery and can cause a domino effect.
Bringing that capability into the team may or may not be the right move. Whether it's in the team's and the organization's interest to include the capability as part of the team or to address why it can't be fulfilled elsewhere must be determined.
Roles in cross-functional agile teams
The simplest and smallest agile team needs three capabilities. These are “The What”, “The How” and “The Doer”. Let’s look at these capabilities in turn, which may be fulfilled by separate individuals or more than one role may be undertaken. For more details, check out our separate article on the software development team structure.
Product Manager
Every team needs some direction over what is being built. If this isn’t present, there’s a real risk that things get built in the wrong order or worse, that aren’t even needed. Such direction is best provided in an ordered or prioritised list from which the team can choose which item they do next.
The person that helps the team with their priorities is the product manager or product owner. This person understands the needs of the user, what the product needs to do, and navigates the complex web of internal stakeholders and customer requirements. Product managers aren’t the only pipeline for new requirements to reach the team, as the best teams are self-organising and able to engage directly with users, but product managers will be heavily engaged with any new demand and always available to provide clarifications to the team.
Delivery Manager
Once teams know what needs to be done, they will need to understand how they are going to work together in order to achieve it. Often, the best person to help scrum team decide upon an effective way of working is someone who can take a neutral stance.
The reason for this is because there is an inherent conflict of interest between the person requesting, or doing the work and the process of making a decision about how the work is to be performed. For example, product managers are often incentivised to see new features being built at the expense of the quality of the product (sometimes called accruing technical debt). Delivery managers help to mediate between the team members and product managers to ensure that the product’s technical debt is paid down at an appropriate rate.
Product Developer
The doer is the team member that will actually turn requirements into some sort of tangible working product. This is also the role that requires a cross-functional focus, as the previous two roles are usually standard in any team. The skillset of the doer however is entirely contextualised depending on what is being built.
When choosing the various “doers” you will need in your team, it is better to focus on capability rather than role title. For instance, an average software development team might need the following capabilities:
- Front end development
- Back end development
- Platform engineering
- Database administration
- Manual Testing Quality Assurance
- Automated Testing Quality Assurance
- UX and Design
- User Research
The above capabilities do often lend themselves to separate role titles, however, that's not to say that there must be a one-to-one mapping. It's common to see “Full-stack” developers who are able to perform front-end and back-end tasks, as well as QA Engineers who conduct both manual and automated testing. It’s common for developers to be able to conduct quality assurance work, and also with the advent of DevOps, to be skilled platform engineers also.
Benefits of cross-functional agile teams
Faster delivery, better decision-making and design, and more user-centric product are some of the benefits of cross-functional agile teams. Building cross-functional teams removes unhealthy dependencies on other teams and third parties. Cross-training boosts retention and helps avoid situations where one key knowledge holder becomes a bottleneck. Direct engagement with end users leads to meaningful and useful feedback.
Faster delivery
Building cross-functional teams removes unhealthy dependencies on other teams and third parties. When development teams rely on an external resource to complete their items, the external resource may not deliver in an acceptable timeframe or quality.
Managing external dependencies is time-consuming. First, teams must establish a waiting procedure. Wait or move on? Who chases and how often? Who escalates? What if your work falls behind others'?
Context switching can halve a team member's productivity. It's better to focus on fewer items at once than to have to catch up on a task that was offloaded to a third party and is now back on the team's plate.
Without costly hand-offs, conflicting priorities, and context switching, teams can control their own destiny, make realistic plans with fewer unknown variables, and deliver items faster.
Allows for cross-skilling
If the team has many skills, they can be shared. Front-end experts can learn from database experts and vice versa.
This helps avoid a situation where one key knowledge holder becomes a bottleneck, disrupts the team, or leaves the team permanently.
Cross-training boosts retention. When there are no development opportunities, many employees leave. Cross-skilling can be used as a performance goal to help employees get promotions or pay raises. This benefits both the company and the employee, who becomes more skilled.
Better decision-making and design
More team knowledge means better product design from the start. This prevents the team from building functionality that doesn't meet the non-functional needs of other teams, requiring costly rework.
It's better to design a solution when all the ecosystem variables are known, as this may rule out certain avenues early on, preventing the team from going too far down an architectural or functional dead end.
More user-centric product
Technical delivery teams often build large pieces of functionality without engaging a user (the end user). This can lead to unused or unsuitable system features.
Cross-functional teams encourage direct engagement with end users rather than assuming it's been done elsewhere. This leads to meaningful and useful feedback and a more engaging, higher-performing product that will achieve its goals sooner.
How to build a cross-functional agile team step-by-step?
The most important thing when building a cross-functional agile team is to ensure that everyone on the team has the necessary skills and knowledge. This can be done by conducting a skills analysis, encouraging knowledge transfer between team members, and hiring new team members with the required skills
Conduct a skills analysis
Before starting the journey to cross-functionality, organisations should spend time determining which capabilities they need to hire, which they need to improve, but more importantly which capabilities they already have a high level of maturity in.
A good way to do this is by using a skills matrix. Take the list of skills that are required and create definitions of 0-5 which represent the level of mastery for this skill. 0 would be “No or very basic familiarity”, 5 would be “Industry expert, regularly presents at conferences”. For each team member, ask them to self assess their expertise based on the given descriptors.
This will allow an “at a glance” view of the areas in which the organisation is lacking, and therefore which capabilities need to be targeted.
Knowledge transfer
The most cost effective way of building cross-functional teams is to upskill the team members you already have. One great way of doing this is by taking the skills matrix you prepared in step 1 and encouraging those with higher knowledge in a particular area to run workshops, mentoring and knowledge transfer sessions with those individuals that have weaker knowledge.
The skills matrix can also help you align gaps with formal industry training courses, allowing your team to be trained and certified in areas that the organisation is lacking.
Many people learn better on the job, so it may be useful to rotate team members into the teams that have knowledge experts present, allowing them to begin conducting work in the area they need to up-skill in under the watchful eye of an expert.
Hiring for a cross-functional agile team
When building cross-functional agile teams, it is possible to go to the open recruitment market and hire those individuals that hold the skills you require for your team to be successful.
It can often be difficult to find those individuals who have an exact match for the specific mix of capabilities that you require however, so hiring managers should maintain a degree of flexibility when reviewing candidate profiles. Instead of requiring experience with specific branded technologies, look for how willing they are to take on extra responsibilities.
A common approach is to hire so called “T Shaped people”. This to say hiring people with a breadth of experience in a number of different areas, but extensive knowledge in one particular area. This provides enough versatility to move items along, whilst providing the ability to be a subject matter expert in one particular capability area.
It is also advisable to inform potential hires that there is an expectation for them to operate in a truly cross-functional team. Some individuals do not want to do this, preferring instead to keep their work activities to their chosen specialism.
Outsourced team augmentation
When the appropriate skills are too difficult to find on the open market, it may be worth augmenting your team with resource from a third party. Our article Insourcing vs Outsourcing talks more about the pros and cons of this approach.
Software development team augmentation can be particularly useful when you have the requirement for a very specialised skill within the team, but do not require a full time employee to provide it at all times. This is when making use of a “retainer” with a third party can help, so that you draw on the resource as and when the need arises.
Hiring in a resource from a third party can also be a useful way of upskilling your team, as you can make knowledge transfer part of the contract, allowing the expertise to be retained in the team longer term, and ensuring that over time the reliance on an external resource provider disappears.
Conclusion
The more stages of the delivery process that are under a teams control, the greater their success is likely to be. Realistic cost/benefit choices should be made regarding the amount of the “vertical” stack which a team should seek to own. An analysis should be conducted of the dependencies they are subject to and whether these dependencies are likely to be healthy or present bottlenecks.
Organisations should take a blended approach of hiring, cross skilling, on the job and formal training to build the desired team mix. The mix will need to be constantly monitored and feedback loops created to allow continuous improvement.
If this approach is followed, teams are likely to experience far fewer blockers and build the right thing at the right time, to the right level of quality.