Evan's Agile Manifesto - Part II: Defining Your Products and Teams
Welcome to Part II of my series on executing Agile fundamentals for software engineering teams. Be sure to check out Part I: Introduction first, and you can also check out the rest of this series under the tag #agile-manifesto.
Properly defining your products and teams is a crucial part of getting started with Agile. All of the good things that can come from Agile development, like predictability and transparency, are built on a foundation that expects you to have a good definition of your products and teams first.
Define your products
What even is a product?
The first thing you need to do is to define your team's products, even if you're leading an existing team or business. You may already know what your products are - perhaps the product was given to you or you inherited it, or perhaps you developed it yourself and are leaning on its implicit definition based on the vision in your mind. Either way, you should take time to explicitly define your products, who are its customers, what are the key use cases it serves, and perhaps even your high-level vision for the product over the next 1-3 years. (Note: If you have product management partners, this is a really great time to engage with them and collaborate!)
It can be tempting to dig into the nitty-gritty details of your product up front, but for this first exercise, start simple. You can always add more definition later, but you need to nail the basics to get started. I recommend thinking about your products with this lens: A product is something that your team develops which provides customer value. I'll use the term "customer value" throughout this guide, but that isn't strictly limited to external customers. Depending on the type of product you're building, your products may serve internal customers, or even your team itself.
In some cases, your team may own a part of a larger system. That's perfectly fine; it's totally valid to say "my product is a product within larger product". For example, perhaps Team A owns a website platform (whose customers may be both external, as well as internal engineering teams as a development platform), and Team B owns a specific customer-facing feature within the website platform. In this case, you could say that Team A's product is the website platform, while Team B's product is a specific feature within that platform.
Many teams don't have existing clear lines of demarcation around their products. This is especially likely when teams go through periods of rapid growth, when teams go through organizational changes like mergers and acquisitions, or simply by the evolution of your product into something different than what it was when it first launched. In those cases, ignore the existing team structure of your organization (in the spirit of Melvin Conway), and instead zoom out to define your products by the customer value they provide. Once you've defined your organization's products, you (or your leadership team) can restructure your teams to better align with those product boundaries – your teams will perform better if they are aligned to cohesive product areas.
How many products can one team own?
It's very common for teams to own more than one product. Ultimately, how many products a team can effectively own is highly variable and often comes down to the team's ability to support and develop all of their products without having one important product becomes a bottleneck for another equally important product.
Product cohesiveness is also an important consideration when thinking about whether or not to introduce new teams or move products to other owners - are the products your team owns complementary to each other, or are they serving completely unrelated sets of customers and use cases?
And if you aren't sure: lean on empiricism and experiment. Ignore team boundaries, carve out your product descriptions, and run time-bound experiments. If you have a team that owns multiple products that seem to lack cohesion, try experimenting with forming two internal virtual teams, giving them each a more cohesive charter, and measuring the results. Perhaps you'll find a great opportunity to start scaling your organization, or perhaps you'll find other inefficiencies that can be solved with improvements to your product definition or development processes that were unrelated to your team structure.
Mapping your product to its constituent services and systems
If you own an existing product, now is the time to map out the systems and services that compose your product - after all, these are the things you'll be modifying to build new features.
Notice how we're talking about our technical systems and services after defining our products? That's intentional - in order for us to define our products correctly, we need to think about them from the perspective of the value they provide to customers, and not the (arbitrary) technical components that compose them. (If you already have backlogs for your team that are modeled based on your services and not your products, this is a great area to start refactoring towards a product-based backlog.)
Products aren't limited to just one service or system - it's very common that teams own multiple services that, when used together, produced a feature for customers. Many teams think of each of their services or systems as a product, but many times, these components only provide customer value when integrated at a higher level (especially if your organization is biased towards service-oriented architecture). These services on their own are not the product. Another way to test which components compose your product is to ask yourself "What systems would be involved if I wanted to add a new feature?".
Define your team
Agile teams are a cross-functional collection of individuals needed to deliver customer value. You may already have a team of individuals reporting to you, but that may not be the real team that you work with to deliver customer value.
To start, decouple your concept of "team" from "the direct reports of a particular manager or team leader". As a simple example, imagine you own a website. To add a new feature, you may need some back-end developers to build back-end business logic and persist data, a UX designer to develop mock-ups and designs for the user experience, and front-end developers to implement the user interface. In some organizations, you may have quality assurance engineers or deployment engineers who are critical to getting your product to production. All of these people should be included in your definition of a "team", and should be included throughout the process described in this guide.
In many organizations and companies, you may not be able to literally restructure your teams. That's totally fine! You can still run your team as a virtual team, although you may need to get some buy-in first (or better: give it a try while minimizing overhead, and share the results!). Maybe you directly manage an engineering team, and you have partner teams, led by other managers, that are focused on aspects like User Experience and Quality Assurance. Even if those individuals formally report to other managers, you can still draw a dotted line around all of the individuals needed to deliver customer values. Ignore those arbitrary organizational boundaries!
In the past, I led an engineering team that built full-stack customer experiences for a large cloud computing company. The engineering team was already cross-functional - the majority of the team could work across the front-end, back-end, and testing/continuous deployment (helped in part by some of the agile principles I'll cover later in this guide) - but that wasn't the full picture. We had valuable Product Management and User Experience partners who were critical to our end-to-end development process, although they reported to independent organizations and therefore technically weren't part of the "team" (as defined as my direct reports). Regardless of reporting structure, I simply had the whole team to sit in the same team area, defined the team's chat rooms and mailing lists to be inclusive of the full virtual team, and ensured everyone was included in our agile ceremonies like sprint planning, daily scrum meetings, and demos. The end result was fantastic: when we wanted to build new features, we had product and UX to help with definition and design, fungible engineers who could produce the entire technical product, and when there was feedback, everyone was on the same page and could adapt quickly to changing circumstances. We didn't need to schedule a meeting in two weeks with product, we didn't need to have long feedback loops with our UX organization - everyone was together under the same (virtual) roof.
The optimal team size
Team size is highly variable, especially from company-to-company. But this is an opinionated guide, so here are my guidelines:
As the scrum guide says, the optimal size of a team is small enough to be nimble, but large enough to get meaningful work done over the course of a sprint. Generally speaking, if you have fewer than three individuals on your team, scrum is probably more overhead than you need to manage work across such a small set of individuals. It doesn't mean you can't leverage some of the processes and rigor that come from effective product definition, story breakdowns, etc., but the cost/benefit of other scrum ceremonies may not be justified.
If you have more than 10 individuals on your team, the communication and planning overhead required by scrum starts to scale poorly. You may be managing so many products and dealing with increased interpersonal communication and coordination (see also: The Mythical Man-Month) that you'll spend more time managing overhead than getting things done.
My ideal team size is between six-to-nine individuals, not including the team's manager. This gives you enough development power to get a solid amount of work done during a sprint, but not so much that communication overhead gets in the way. I've found Amazon's model of Two-Pizza Teams to be really effective team size philosophy – the idea is that you should be able to buy two large pizzas, and feed your team so that nobody is hungry and there aren't any leftovers. And although it's a metaphor, you can also very easily measure this one.
What do you do when your team gets too large? That's where you need to start leaning on the work you did earlier - your definition of cohesive products, your experimentation with how many products any given team can support - and scaling your large team into multiple smaller teams. Sure, there can be some growing pains as teams learn to work independently of each other (and I should probably write an entire post about what to think about when forming new teams) but the best thing you can do is to partner with your teams in this process, set clear goals, and experiment while measuring results. What might this look like in reality? You start with a team of five, which grows to 12. Partnering with your teams, you find that you can restructure the team into one team of seven that owns two products, and one team of five that owns one product. You hire a manager to lead Team A, and you promote someone from within to take over the manager position for Team B.
Throughout this section, you might have noticed the repeated focus on "communication overhead". This is one of the most important aspects of my definition of team, and something that I'll be addressing specifically the next section.
Your team is not a collection of individuals working independently
This the most common anti-pattern I've with the way teams are structured: Many teams are only teams in name only; when it comes down to doing work, it's a bunch of individuals working independently, each assigned to their own functional areas and not collaborating. As a manager, this is one of the first things you need to change: your goal is to transform your team into a "black box", where the team is responsible for completing the work, regardless of the individuals assigned to the work. The team, not a specific individual, develops your products, adds features, fixes bugs, and delivers customer value. Only once you change this culture can you start reaping later benefits of predictable and durable teams.
This doesn't mean that you won't have specialists or experts on your team. Quite the contrary; scrum teams are self-organizing, which means that they (not just the manager) need to determine the right composition for them to get work done. It's perfectly natural for experts or specialists to emerge based on skill, personal interests, or professional aspirations. But here's the key: the team should all be able to develop and support the products owned by your team. That doesn't mean everyone will have the same level of skill or expertise, but at the end of the day, if your team were to lose their "Product A" specialist, they're all accountable for its continued development and support.
If you're a manager whose team is a collection of individuals working independently, I have some bad news for you: you're likely the biggest source of the problem. I get it; it's just so easy to point to an individual and say "That's my Project A person", or "That's my Feature B person". You have to change your way of thinking so that your team is the entity doing the work, and not a specific individual. You can still have key leaders for each product, but they can't be the sole contributor.
When you treat your team as a real team, giving the whole team projects and features to deliver, they'll start to collaborate organically, and they'll recognize products on which they aren't sufficiently cross-trained and take action to mitigate the risk. If this is vastly different than your current team's culture, you may need to help support the process at first. But, many times, you don't need to mandate anything – this will most likely happen naturally once you start exposing them, as a team, to your projects and features.
Personally, I've seen both sides of this. I was once on a team where one individual had single-handedly developed a significant portion of the team's systems over the course of several years, and therefore was the sole holder of critical technical and business knowledge. When this individual (inevitably) left the team, the team was left with a huge knowledge-crater which took months of pain (slow development, inability to solve urgent issues, operational problems) to recover from. Conversely, another team inherited a complex legacy system in which only one out of seven team members had any technical (or even functional) knowledge. Simply by treating the team as a black box, and letting them work on products as a self-organizing team, they self-mitigated this serious resourcing liability on their own in a short period of time. After two months, the majority of the team was effectively cross-trained, which they immediately benefited from once the original developer took a vacation which had no impact on the team's productivity.
But what about measuring performance?
Some managers are understandably concerned about transitioning from the "collection of individuals" model to a real, collaborative team model, because they are unsure of how they'll measure individual performance when they can't simply say "this is my Project A" person anymore. This is a very common concern, and I'll assure you: it's a simple problem to solve.
First, you'll still be able to measure individual performance when your team is working as a team, and second, individuals will likely have a more opportunities to gain valuable experience because they'll be able to seek out challenges across multiple products, rather than just whatever their current project assignment happens to afford them. Need more API design experience? Cool, Product A has a need for that. Want to learn more about distributed systems? Great, Product B has a need for that. At the end of the day, individual performance management doesn't require them to be anchored (or chained) to one project. On top of all of that, as a manager, you'll start to recognize the significant value of prioritizing team performance, because, ultimately, your team will do a much better job of getting work done efficiently and predictably than a collection of individuals.
I've lead teams across multiple development processes - waterfall, kanban, scrum, scrummerfall, etc. In my opinion, I was better able to measure individual performance using the scrum process, aided in large part by the clear definition of user stories (and thus the clear definition of individual output), and the built-in ability to estimate and measure the effort of stories and tasks.
Help! My product or team situation is complicated!
For some teams, this process of defining your product(s) and team(s) might be really straightforward. Perhaps you already have well-defined product and team lines that work out of the box. If so, congrats!
For some other teams, you may start to recognize that you don't have a good product definition, or your team is spread all over multiple unrelated half-products, or you don't have the right team composition to be successful. In these cases: fear not, it's solvable, but you need do some organizational legwork. You can be the catalyst for change, as long as you've taken the time to get the data and describe the problem and recommendation clearly.
If your situation is complicated, here's what I recommend: Define your products as I described earlier in this guide, but try to ignore existing team lines or product structure. Perhaps you're getting too wrapped up in the implementation details of a system, rather than focusing on the "customer value" aspects it provides.
Once you've defined your products - or at least what your products should be - write a document describing how you'd match those product(s) up with the appropriate two-pizza teams. If you don't have the ability to make these changes on your own, share this with your manager or your leadership team. You will have to be the champion for organizational change; don't wait for someone to do this for you (or for your teams to fail in order to visualize the problem). If you have fundamental problems with your product or team definition, you'll struggle to execute a process like this.
As mentioned earlier, it's common for teams to be a collection of individuals, rather than a black-box team. In many of cases, you can fix that as a manager. But, sometimes you're under organizational pressure to loan out individuals on your team, essentially making them subcontractors around a larger organization. I get it: organizations often need engineers to be fungible to help support other projects. But there's a cost: predictability decreases substantially when you introduce churn to your people or products. I know it's hard, but for this to work, you have to get your organization structured so that cohesive teams own cohesive products, and you can't be messing with the team composition unnecessarily without paying the price. It's perfectly fine for teams to change – people will join your team, people will leave your team, new products will be created and old products will be sunsetted – but you shouldn't take ad hoc changes to your team composition lightly. Every time you do this, you're changing variables that will have an impact in your team's predictability and performance. If your organization is already doing this, they might not be doing a good job of measuring the impact of these changes on team performance. If that's the case, do the empiricist thing: control variables, measure, review. I expect you'll see the correlation.
Additionally, organizations have to change as well. Re-orgs are an important part of growing (or even shrinking) organizations, and while they shouldn't be taken lightly, they also shouldn't be avoided. The important part is that you and your leadership team needs to understand the impact these changes can have when it involves changing team composition or product ownership. It can take months for a team to recover its original velocity after significant team composition or product changes (I've measured this!). That doesn't mean you need to avoid change, but as a manager, you need to be able to measure your teams performance empirically so you can clearly communicate to your leadership how organization changes will impact your ability to deliver results. If you can measure your team's performance empirically, you'll help your leadership team to make better decisions.
That's the end of Part II: Defining Your Products and Teams! If you found this to be useful, consider subscribing to my newsletter (it's free!) to get notified as additional parts are published, which will be posted under the tag #agile-manifesto.