What roles do I need in my team?

"There’s nothing in the agile manifesto about how to make up an agile team. Scrum is clearer, specifying a product owner, a scrum master/agile coach and the team. However, there isn’t a great deal more help from this corner on what ‘the team’ should look like."

There are two reasons for this. First off - rightly or wrongly - the scrum guide only recognises three roles: the product owner, the scrum master, and the developers. This is unhelpful if you're not a pure software delivery team. We'll come back to this in a minute. Secondly, it's pretty hard to know what your team will be, especially in the modern world. Even within pure software development teams, the required roles will vary depending on what's being built. Take that out of just software development, and a myriad of roles creep in.

Great, you think. How am I supposed to know what roles I need in my team? Luckily, there's a really clear way of knowing what people you need, when you need them, and what they should contribute.

Let's look at a few things that will help you start to break this down. They are:

• what you’re delivering
• what stage of your project or product you’re in
• whether you’re set up as a fully agile organisation, or are in a process of transformation
• whether you’re a development team or a non-dev team using agile ways of working

The first two are key. If you don't know what you're delivering, how can you know who you need to help deliver it? I realise this sounds obvious, but the number of times I've seen teams get started with a set of roles without first fully understanding what they will be delivering is way more than it should be.

Secondly, your team make-up can and should flex depending on what stage you're in. For example, if you've just kicked off a new project or product, you should really be focusing on understanding what the parameters are, who uses the product, what they want, what the business wants and so on.

Yes, you should be building things to test with customers or users of the product, but you really don't need to be creating everything from scratch, or making sure systems talk to each other. Of course you need to understand these things, you just don't need to build everything right away. So therefore having a team that has multiple backend developers, a legal person, two solution architects, three business analysts and a priest isn't going to be the best use of time, money or indeed the skills of the people in the team. We'll look at a few permutations below, but knowing what you're trying to achieve the beginning really will help you build the right team.

A third thing to consider is size of team. There are multiple reasons not to have a massive team, not least of which is the lines of communication challenge. From a purely practical point of view, get over 10 people in a single team, and watch your need for meetings and longer stand-ups increase unnecessarily.

Diagram showing complexity in communication as teams grow (Source: Lighthouse )

The last two points above probably warrant posts of their own, especially the second one, as despite agile or analogous ways of working now being a norm across many non-software teams, we still seem to be stuck in the world of just for developers.

With all that said, let's have a look at the make up of a typical squad building a software product (with the promise that we'll look at what non-software teams might look like elsewhere).

Product owner

The product owner is the person responsible for guiding, and ultimately delivering, the product. They will set out what they want the product to be and do, in line with business goals and user requirements (including stakeholders). In a good agile workplace, both of these things will be emergent as the product develops, so will change or morph over time. This will be reflected in an ordered and prioritised backlog.

Whilst the product owner determines the overall vision, they are not responsible for how the work gets done. In scrum (and other forms of agile frameworks), it is the team who decide what to work on, based on conversations with each other and the product owner, who in turn will be speaking to stakeholders to determine what things to work on and when. In high functioning teams, these usually align, as everyone has a shared understanding. In newer teams, or less functional teams, there may be a degree of prescription by the product owner or business on what is going to be worked on. This is fine, as long as it doesn’t a) put undue pressure on the team, b) is fully discussed with the team and c) isn’t the de facto way of working forever.

So, the product owner is the keeper, sharer and orderer of the vision of the product, in line with wider business and customer requirements.

Scrum master

The scrum master is responsible for a few things. Primarily, they are the ‘keeper of the agile flame’, making sure that a team practices the values of whatever flavour of agile they have chosen to use. They will also be the key improver within the team, mentoring or coaching the rest of the team (including the product owner) to help improve things. Note that this is usually from a process point of view, helping to improve situations by practicing agile better, rather than being involved in the minutiae of ‘if you do x like this it will be better’.

This coaching and mentoring may (and should) extend to the wider business, helping people understand the benefits of working in this way. Scrum masters are also facilitators, helping agile meetings to run better, although over time this responsibility should be adopted by the team, helping them to become fully self-organising. In fact this idea of doing oneself out of a job is the goal of any good scrum master, although as usual, reality will differ from what you might read. I’ve worked with very few teams who could operate without a scrum master and continue to be high performing in its truest meaning.

The term 'scrum master' is rather misleading, as teams don’t have to be practising scrum in order to have one. Rather, this role is about helping the team to adopt, understand and better use agile practices to improve the product, their ways or working, and the team itself. You may see this role referred to as agile coach, delivery lead, kaizen coach, or similar. The basic premise remains the same, although there are subtle differences in these roles.

The team

As mentioned above, this will vary depending on a number of factors. Before a project is set up, you should look at what team member requirements are, and what they might look like in the future. More on this later. For now, here’s a fairly typical snapshot of roles within an agile team, based around building a digital product. Two notes on team member composition - although you definitely want experts in their field, try and make sure you have people on your team who want to get involved in other areas (this is known as ‘T-shaped people ’) and who play nicely together, although this isn’t always a known quantity until you assemble your crew. You may hear this referred to as ‘no rock stars/ninjas/gurus’, meaning that whilst these people may be brilliant at their respective roles, they don’t work hugely well as part of a non ego-based team.

Secondly, try not to flex the make up of your team too much, too regularly. New teams members can certainly help the team develop, but any additions or subtractions - especially on a regular basis - will change the dynamics of the team, and will slow them down, at least initially. If you make looking at the near to medium term future a part of your product development, at least in terms for what you're likely to be doing, this makes it easier to adjust the team. Don't be afraid of helping existing members of the team develop new skills or specialities if they show an interest - not only is this great for career development, it also means the team grows in terms of its capabilities.

Developers

These can be front end, back end, mobile, app, full stack - the list goes on. You’ll most likely know which ones you need based on whatever it is you’re trying to deliver. Developers are responsible for building your product. For example, if you’re building a website, you’ll need front and back end (or full stack) developers to create the frameworks.

If you’re building apps, you’ll need app developers skilled in the language of the platforms you’re releasing apps on. A good approach is to pair developers (known as pair programming) which helps to ensure consistency of approach, creates bonds between team members, reduces errors, and shares knowledge and best practice. This can be especially fruitful if you pair junior with senior, or across different disciplines, such as front end and backend, helping to spread knowledge across the team.

Testers

At least one of these is a good idea if you're building software, as they are responsible for ensuring the product you release isn’t riddled with bugs. Although the team in general should be responsible for ensuring high quality, a test person makes sure of it. The best testers will add far more to the team, for example, helping the developers to create more robust code. In one team I worked with, the tester also helped massively with a lot of the process stuff, ensuring the team remained true to their agile values, and assisting the team with things like release notes and story creation.

Testers should be firmly embedded with your developers, and although all agile teams should work closely together, this is especially important here, as it can help with test/behaviour driven development. Note that things like quality assurance can be carried out by the team - if you're creating newsletters or media for customers, get the team (including product owner and scrum master) to quality assure it. Having this sense of ownership means a better, more functional team, and most likely a better end product.

Designers

In the digital realm, designers will probably overlap at least a little with user experience. This is because rather than just create pretty things, designers will also be responsible for user interaction, design patterns and style guides, all of which have some bearing on how users interact with the end creation. Digital designers will also be much more collaborative, and less focused on producing gold standard designs every time, as lots of design assets will evolve rapidly across the course of developing a product, in line with user feedback.

As an example, some of the best designers we’ve worked with have also created clickable prototypes to test ideas, have included other members of the team in design sessions (these collaborative sessions mean everyone gets a shared understanding of the design process), and in some cases, have run user research sessions, which can be especially difficult when users tear your beautifully crafted experiences to pieces.

User experience (UX)

This is a wide and varied role, and can encompass other disciplines, such as customer experience (CX). At heart, the UX person is responsible for making sure that users can use and understand a product. This may involve creating mockups to test with users, running user research sessions (although having a dedicated user researcher is always preferable), helping to create user maps, user journeys, user profiles and so on. The common thing here is that whatever they do, it will be with the best interests of the user at heart.

A good UXer is invaluable. They will help use modern web standards to create experiences that users can interact with intuitively. They will work alongside (and sometimes instead of) digital designers to make sure websites, apps and products look and respond correctly. They will help to put the user front and centre, and they will help the wider team to understand why doing something a certain way is better.

Business analysts

BAs are information gatherers and disseminators, and in some cases translators. They will help to gain a wide picture of the market in which you’re operating through things like competitor analysis, gap analysis (what’s missing), looking at search logs to see what users want, pulling together reports showing you how people use, view and interact with your product. They will work as a bridge between technical and non-technical folk, helping turn non-specific requirements into actual deliverable chunks that can be built and tested. The best BAs understand both worlds - the strategic and technical - and help to ensure that what the team delivers straddles both.

These tend to be the key, core roles of a development team, and can include one or more of the roles, depending on what’s required. Bear in mind that team makeup should be evaluated regularly to ensure the right people are involved [example?].

Here are a few other roles that might be considered - again, it will depend entirely upon what you’re delivering at what time, and this is by no means an exhaustive list.

User researcher

One of agile’s key points is ‘inspect and adapt’. There is no better way to inspect your product than by getting feedback from the actual people who use it - namely, your customers. This can be done in a multitude of ways, but usually comes down to either qualitative (speaking to people face to face) or quantitative (analysing data sets or evidence bases). A user researcher will help to construct ways to not just collect and analyse these touchpoints, but to make sure you have things like customer understanding (segmentation, personas) and tie back what you’re doing to actual user needs, rather than just strategic decisions (more on this tension in the future).

One point to note - user research should be a ‘team sport’ - this means the team (and ideally involved stakeholders) attend user research sessions and get involved in analysis. This helps to invest the team in what they’re doing - building stuff for real people - rather than keeping it abstract. Actually hearing what works or what is frustrating for your end user motivates and focuses a team like nothing else.

Content editor

If you’re creating customer facing content, it is essential to get a content creator in. Not only because creating words and compelling content is a specialist subject, but because things like a style guide, tone and subject matter, and the ability to write in a way that engages with your audience and helps funnel them in whatever journey you’re trying to create are vitally important. Expect this role to have a close relationship with your user researcher and experience roles.

Technical architect

If you’re in a build phase (rather than concept testing), working out how what you’re doing fits in with existing things will also be vital. This is where your technical architect comes in, as they’ll align what you’re building with what’s already there. In my (sometimes painful) experience, the moment you think of scaling a potential product into a real one, you need these people on board.

Other analysts

If your work involves another area of expertise - financial for example - consider getting someone in the team who can reduce the amount of time you spend asking questions elsewhere. When working with a team who were building healthcare products, we had a clinical analyst in the squad for a while, as the amount of regulatory information we needed to deal with meant that introducing them into the team kept our work on track without having to go through endless sign off processes, as well as keeping key stakeholders - in this case the clinical risk function - informed early as to what we were doing.

The point with any of these roles is to make sure you have expertise in your team, and that you’re able to deliver value as quickly as possible. Your world will no doubt look different to this but regardless, some work up front of identifying the necessary components that make up a team is time well spent, and will result in faster, smoother delivery, and happier, more fulfilled teams.

Another consideration is how you interact with areas of expertise and knowledge that you rely on, but that don't warrant being in your team full time. There are multiple ways of doing this, some of which will be a future post, but for now make sure you account for this, and set up some way of working with these teams early.

As mentioned above, it’s highly unlikely that the make up of your team will remain static or ring-fenced. This is especially true if you are testing concepts to see if they are worth pursuing further* as your team or organisation seeks to identify the next great product. In this state, you’ll most likely need less developers - aside from those required to build the lowest fidelity usable prototype - and more researchers and analysts. The point here is to decide whether or not a thing is worth building.

There should be a healthy tension between this stage - deciding what to build - and the actual building of the products/features/etcetera that emerge from this. Lots of teams will spend a portion of each sprint doing this, or have an up-front period (called a discovery) to determine what goes forward and what doesn’t. There’s no right way to do this; as long as you’re actively testing the waters and not just building every idea that comes along without rigour, you’ll be in a better, more agile place.

* a note on this. When a team first sets up, having a period of pure discovery is a great idea. As they start to settle on ideas to build out further, discovery should become a key part of the product lifecycle, both in terms of looking at new opportunities and refining what's already built. The best teams balance these requirements, and often have a rule or principle determining how much of each phase is brought into each sprint.