The Jobs on a Software Scrum Team for Recruiters

The Agile Scrum methodology is pretty much the standard in corporate america software development these days.

A Scrum Team working on a software project has the goal of creating a product using an iterative approach. What this means is that they work on software and get feedback from the customer in small increments of work.

As a recruiter, it will be helpful for you to understand the composition of these teams and what each of these roles are doing because ultimately you might have the opportunity to place each of these people with your client.

By the way, I cover this information in part 2 of my free video series called Parts of a Software Project. I also recently went on the TechRecruit podcast and I talked a lot about how software projects are organized.

The People

Scrum is a project management methodology that can be applied to more than just software projects, but the focus of this post will be about software because that is what I personally have experience with.

Given this, you probably can guess that on a given software project the majority of the scrum team is typically made up of software developers of one sort or another.

But there are a few other roles! I'll break it all down in the post.

Overall team sizes and makeup.

There is an idea of a "two pizza team" that is ubiquitous in software development. That means your team should be no larger than 2 pizzas can feed. So about 6 to 8 people. Sometimes more, sometimes fewer. Usually this breaks down like so:

• 1 Product Owner / Product Manager
• 1 Scrum Master, Engineering Manager, or Project manager (depends on org).
• 2-3 Backend developers.
• 2-3 Frontend developers.
• 1 QA Automation engineer.

So as a recruiter, you can see right off the bat that there are going to be a ton of engineering position openings every time you spin up a new software project.

Sometimes you have projects that are strictly for building "services" e.g. it's all backend developers. You might get a team that looks like this:

• 1 Product Owner
• 1 Engineering Manager / Lead Engineer
• 4 Backend Engineers
• 1 DevOps Engineer or Site Reliability Engineer

Building large products

Another thing to note is that with microservice architecture, organizations will often divide up projects so that a single product may have multiple services and each service will be handled by a given team. So for a big ecommerce application you might have something that looks like this:

• UI Team
• Mobile Team
• Item Catalog Team
• Search Team
• Order Management Team
• Analytics Team
• User Management Team

So here you would have 7 scrum teams each handling different aspects of a large application. Each of these would have 4 or 5 engineers (maybe 35 total), and product owners, scrum masters, and engineering managers.

The Product Owner / Product Manager

The product owner (or product manager) is the person who communicates business needs to the engineering team. They deliver requirements and help determine how a business requirement should be turned into a software features.

They also direct decisions on how a product should be implemented. For example is there some argument about how some new feature should work in a software project? Usually the product manager will decide.

This role is critical for the success of any project and from what I have seen these people tend to stay in one organization longer and accumulate the most tribal knowledge about how the business works.

The Scrum Master

The role of the scrum master is to direct "ceremonies". I always thought this was a strange way to describe the weekly or bi-weekly meetings that are part of the scrum methodology but for whatever reason that is how these meetings are often described.

I'll list them out, but you don't really need to know these details as a recruiter:

1. Standups - a status meeting (typically happens every day)
2. Sprint Planning - determine what work will be done each "Sprint"
3. Backlog Refinement - comb through the backlog of slated work and estimate effort
4. Retrospectives - at the end of the sprint you reflect on what worked and what didn't

There is a "Scrum Master Certification" (called the "CSM"). It actually is just a 2 day course and then you have to take a test. Most people who do this as their primary job will have this certification.

I have actually taken this 2 day certification class before but I felt like as a developer it was not valuable enough to be worth even bothering to take the test and get the actual official certification.

Sometimes you just designate a person on the team as "Scrum Master", other times this is an official role and traditionally what a project manager would be doing. Sometimes the Product Manager will handle these responsibilities, it just depends on the organization.

Designers

Often you may have a UI designer working with the engineering team or product owner to help turn the requirements the business wants into features in the user interface of an application. Sometimes this designer is embedded with the team, or is part of a design team serving multiple product teams.

My experience is that it is more common to have a dedicated design team that does work for various development teams.

Frontend Developers

These are the engineers writing the code to make the user interface of the product. They are probably writing code for web applications (HTML, CSS, and JavaScript).

Usually there will be 2-3 frontend developers on a team developing a product, unless it is a dedicated UI team where every member would be a frontend engineer.

Here is a refresher on frontend vs backend if you want to take a look.

Backend Developers

These are the engineers writing code for the backend of the application. This is the code that runs on the server and interacts with the database. They are going to be using a backend language like Java, C#.NET, Node.js or Ruby.

On a "typical" team there will be about 2 or 3 backend developers. If this is just an API team it will be 100% backend engineers.

Fullstack Developers

These are developers that will pitch in on both frontend and backend work. Often times "fullstack" developers are sought out to work on smaller teams.

A development team may be comprised entirely of "fullstack" developers, but each engineer may specialize in certain technologies used in the application.

Typically, fullstack developers are actually stronger in either frontend OR backend. For example, I usually bill myself as a "fullstack" developer but I have more strength on the backend (although I keep getting sucked into complex React applications so maybe that will change🤔).

DevOps Engineers

By the way if you are not sure what this "DevOps" thing is, I wrote up an explanation here.

Depending on the size of the organization / project you might have dedicated teams of DevOps Engineers that provide support to the entire organization (which would follow a standardized process), or you would have these engineers embedded with given teams they are working with.

From what I have seen you either have a single supporting DevOps engineer on a general development team, or you have specific 100% operations focused teams. But, again, organization structures vary.

QA Engineers

Some companies are deciding that their engineering team should be responsible for "quality". They want to automate it as much as possible. Other companies make this QA automation a specific role. But there is often some QA team or engineer embedded in the process.

Manual software testing is pretty much dead so in this case the QA tester is probably an engineer familiar with automation tools. They might have a title like SDET (software development engineer in test) or QA Automation Engineer. Either way, it just depends on company and organization inside of a given company. From what I have seem the way people deal with QA is all over the map.

The Takeaway

Scrum is the de-facto standard methodology these days, but depending on the project the ratio of front-end to backend might be different but the makeup of the teams are pretty similar in terms of management / engineering ratios.

I hope this paints a bit of a clearer picture of what these software development teams actually look like inside of big organizations. Of course, when it comes to startups, all of this goes out the window! They may not even have a project management methodology they follow at all.