Creating Your Super Scrum Development Team

You're all fired up about embracing agile software development and ready to build the ideal Scrum development team, but you’re not sure where to start. You might ask, "What is the perfect mix of team members needed to create my Super Scrum Development Team?"

The Scrum team is a collective group that works the magic of organizing a product backlog and getting things done on your software product.

A Scrum team includes a product owner, in charge of managing the vision of the product and communicating the needs of business stakeholders into the team. It has a ScrumMaster, who is the embedded Scrum coach on the team, helping team members consistently execute the Scrum process. And finally, it includes the development team, which is the group of individuals that builds the product.

In this post, I’m focusing on how to build your development team within the Scrum team. Let's review what it takes to create "The Super Scrum Development Team."

Scrum works because of cross-functional team members. That is, a Scrum development team possesses all of the technical skills necessary to produce a shippable product increment each sprint. So, it’s essential to select the right mix of roles.

Equally important is to have a balanced team. Even though we have cross-functional team members, we do play favorites, tapping into each team member’s strengths. It’s important to have balance within the team, so we don’t under or over utilize individuals.

Below is an outline for what I feel is the dream team. That is, if I could custom-design a Scrum development team for the highest possible performance, I’d put together the following:

• User experience architect
• Software architect
• Senior full-stack software developer
• Full stack software developer
• Front-end software developer
• Quality assurance specialist
• DevOps engineer

Your team may vary, depending upon the nature of the software you’re building. But for a typical software application that has a user interface, as well as front-end and back-end code, this is what I’d assemble.

Note that in Scrum, we try to avoid titles to the greatest extent possible, favoring the term “developer” for a member of the development team, to reinforce that the responsibility for each team member is to do whatever is required to deliver a shippable product increment.

My intent with the list above is to help you think about the background of the individuals, rather than reinforce a strong focus on titles. There is always an assumption that the “job” of a development team member is “Do whatever needs to be done, however it’s at all possible for me to help.” My goal is also to have you thinking about all of the different skill sets that are required.

There are a few things to notice about the team I outlined:

• There are only seven team members. Many organizations—ours included—have found that the sweet spot for the development team is seven people, reinforcing the common Scrum guidance of “seven plus or minus two.” That is, “Seven is the best, but you can go smaller or larger by two individuals and still get great results.” This provides enough horsepower to get things done but keeps the amount of required communication low enough to remain efficient.
• There are multiple generalist team members. Notice how many team members can code across the entire stack: the software architect and two of the three software developers. It’s powerful when there are as many cross-functional technical folks as possible. It ensures all team members contribute throughout the project and no one “runs out of things to work on.”
• There is a software architect. Whether you describe this person as a software architect, technical lead, senior software engineer, or something else, it’s crucial to have someone with a high degree of in-depth technical experience on the team. This team member typically acts as a spiritual leader of sorts for the technical team members. They help guide the implementation of the technology, ensuring it’s coming together in the best way possible. They also can act as the right-hand-person for the product owner—who is typically non-technical—to help them understand the more technical aspects of how the application is coming together.
• There is only one quality assurance specialist. A strong QA person is worth their weight in gold, focusing on creating the strategy for testing the software application, running manual tests, and working with the developers to reproduce bugs. Great testers can even help the team avoid bugs before they write code, leveraging their past experience to relay possible pitfalls in the architecture or design. There are likely times during a sprint where the team needs more than one person for testing, in which case the software developers can help. Software engineers can perform testing, but it’s not likely the QA engineer can sit down and write production-quality code, which is why I have a stronger emphasis on programmers than QA engineers.
• There is a front-end developer. Contemporary web development has shifted to a model where there is a sharp technical divide between the back end—the portion of the application you typically host in the cloud—and the front end—the portion of the application that runs within the end-user’s browser. With this divide comes a separate set of tools, techniques, and technical know-how. It’s valuable to have a front-end developer who knows the tips and tricks of getting the most out of the code, from ensuring it works as expected across the various browsers, to ensuring it functions correctly on a variety of screen sizes. Today that includes a range from the highest-resolution desktop monitor to the smallest smartphone screen. Note that this does not mean the front-end developer is only “allowed” to work on the front end. Since they are a software developer, they can help reproduce and fix bugs in other areas of the application, and pitch in to help with coding the back end if there are sprints with less front-end work. This drives cross-training and makes them even more valuable to the team.

This development team design is a suggestion that comes after many years of experimentation on my various teams. I’ve seen development teams with this structure, coupled with the use of Scrum, dramatically outperform teams that were larger and smaller—sometimes by a factor of as much as five to ten.

One thing to keep in mind is that not all individuals need to be dedicated full-time to the development team. You may find for example that the user experience architect and DevOps engineer can be shared among more than one team. Some teams share their architect between more than one team as well, to help with consistency with the underlying technical design of products within the organization.

If you don't have the resources or budget to put together a team like this, stay tuned for upcoming posts about how to build a team when there are constraints keeping you from utilizing this model and how you can be successful leveraging smaller teams and external resources to help you move the needle.

This post was previously published on the Ascendle blog.