No matter what your industry vertical is, if you ship software, you're in the software business. Even if the only software you ship supports the rest of the business, you still need that software operating at its best.
The teams that build and support that software need to be effective and efficient. How those teams work, and how you organize them, is a part of your organization's culture.
While there isn't one single best way to organize software teams, certain team structures handle particular problems better than others. In recent years, organizations large and small, all around the globe, have found success organizing their teams into delivery teams.
In this post, we'll talk about what delivery teams are, how they're organized, and how that organization can help you deliver better software, faster.
What Is a Delivery Team?
A delivery team is a way of organizing your software team so that everyone needed to deliver a product all works on the same team. Instead of each person on a team having similar skill sets, a delivery team covers all necessary skill sets in one team.
Who Do You Need in a Delivery Team?
The idea behind a delivery team is that you have everyone you need to ship a product. But just who do you need to ship a software product? Let's run down the roles that you need, no matter what. We'll also talk a little about some other roles you might find helpful.
Product Manager
It's important to note here that we're not talking about a project manager. Product managers and project managers serve two different and important roles. Specifically, the role of the product manager is to thoroughly understand the product you're creating. Their role in the delivery team is to be an advocate for the customer.
While you should set a goal to regularly get your product in the hands of customers, those customers can't provide feedback every day. That's the product manager's job. The product manager is here to constantly push the product forward and identify the best ways to improve the product regularly.
Designer
The second key role for a product team is a designer. For a lot of software, this means a UI/UX designer. Usability is a key—and often overlooked—part of software.
Poorly designed software frustrates users and testers alike. It's more likely to have bugs, less likely to be used regularly, and less likely to be used effectively. The designer's job is to work with the product manager closely to devise software that enables users to do what they want quickly and painlessly.
While you might have some developers with a knack for design who can handle this role, you'll often need someone dedicated to design to achieve the best results.
Developer(s)
For a lot of software teams, this is their whole team. The only role they staff for is developer, and everything else falls by the wayside. Often, these developers are organized into a team for the duration of a project, and then they break up once the project is "finished."
While this approach can and does work in many organizations, it suffers from some inefficiencies that we'll talk about later.
The role of developers in our delivery team is to write the actual code you're going to ship. Without that code, you won't be building a whole lot of software!
Quality Assurance (QA)
Embedding QA within a delivery team is one reason it's so much more efficient than other types of team organization.
In a normal project progression, the engineering team codes a feature and then figuratively throws it over a wall to the QA team. At that point, the QA team needs to learn everything about the feature.
- They need to learn how customers want to use it.
- They need to learn the design constraints that went into the UI.
- Each person who tests it has to spend time familiarizing themselves with how each part of the feature works.
That kind of mental acclimation slows down quality assurance and reduces the effectiveness of the QA engineers.
By embedding QA within the product team, QA is present for product decisions from the beginning. They're able to think about how users will use the software, and they can approach the feature with an eye toward how it might break.
My experience is that having QA think about and discuss product decisions during the early parts of a product's life cycle brings valuable perspectives to delivery teams.
The idea behind a delivery team is that you have everyone you need to ship a product.
Who Else Might You Need?
The four roles above are non-negotiable, but they're not the only roles a delivery team might need.
DevOps
One of the most common roles is someone to focus on DevOps. One of the underpinning ideas of DevOps is that every developer contributes to operational tasks like software builds or deployments. While that's a worthwhile goal, some of the work for DevOps requires focusing on specific tools. For instance, container orchestration and continuous integration pipelines require using specialized tools. Every developer will have different skill levels when working with those tools. That's normal; think of it like having a dedicated designer.
Software Architect
Another role you might find useful is a software architect.
It's uncommon to want a fully dedicated architect on each software team. Many organizations choose to share architects between teams. Like designers, the role of an architect is to understand the feature. Like a UI designer, they design how parts of the software will work. However, instead of designing the interface the user uses, the role of an architect is to understand how different parts of the software fit together.
Much like design or DevOps, you may find that you have a developer who fills this role well.
Why Do You Want a Delivery Team?
The key thing you gain when moving toward a delivery team is efficiency. It may seem obvious, but the goal of software is for people to use it. In order for people to use that software, you need to ship it.
Moving toward a delivery team refocuses your teams away from siloed, individual roles. You no longer organize teams that think about just product design or just writing code or just QA. Instead, each team is focused on the most important goal for a software team: delivering software that customers want to use.
The key thing you gain when moving toward delivery team is efficiency.
In a traditional project structure, each transition from one team to another comes with costly context switching for the team. Each time the project moves from one step to another, it requires people to learn about that feature and internalizing the goals of the feature.
With a delivery team, the opposite is true. Every person who represents a link in the delivery chain is part of one team. Instead of costly context switching, each member of the team understands the feature they're delivering from the beginning. That means teams ship better features, more quickly.
How Can You Get a Delivery Team?
Moving away from project-based teams toward product-based teams is a process. It requires rethinking how you organize your teams. But it also requires rethinking how you organize your projects and how you measure success for your teams. It might require hiring people or training people in new skills.
Fortunately, Liatrio has been through this process many times. They know how to transition toward a product-oriented team, and they'd love to help you on your journey as well.
This post was written by Eric Boersma. Eric is a software developer and development manager who's done everything from IT security in pharmaceuticals to writing intelligence software for the US government to building international development teams for non-profits. He loves to talk about the things he's learned along the way, and he enjoys listening to and learning from others as well.
