Vertical Slices and Scale

Last week, I tweeted,

Among the many responses, Luke Woydziak asked

and as clarification about “at scale,”

What do I mean by my original tweet? How are vertical slices a keystone habit?

Before we get into the relationship between working in vertical slices and working at scale, let’s make sure we’re clear on what I mean in the original tweet…

“Vertical slice” is a shorthand for “a work item that delivers a valuable change in system behavior such that you’ll probably have to touch multiple architectural layers to implement the change.” When you call the slice “done,” the system is observably more valuable to a user. This is contrasted with “horizontal slice,” which refers to a work item representing changes to one component or architectural layer that will need to be combined with changes to other components or layers to have observable value to users.

vertical-vs-horizontal-slices

When teams work in vertical slices, they

  • Make value explicit in their backlog
  • Have more conversations about value
  • Tend not to accidentally build low-value changes
  • Get value sooner
  • Get earlier, higher-quality feedback
  • See constraints and inventory more easily and can respond accordingly
  • Become more predictable in delivering value (because working software becomes the primary measure of progress)

I could go on, but that gives you the idea. When my colleague Peter Green and I mapped out the various habits we see in successful agile teams and how they relate to each other, we found working in vertical slices enabling or at least related to virtually every other habit.

Decomposing big ideas into vertical slices at different levels of detail requires skill, a set of skills that most people haven’t developed. But they’re reliably learnable, and in a relatively short time. Using my free user story splitting resources, I’ve seen teams go from novice to proficient at slicing big stories into small ones with only a few hours of deliberate practice. For the big idea → minimum marketable feature (MMF), MMF → story, and story → scenario levels, students in my 80/20 Product Ownership course (online or in-person) develop proficiency in only 20-40 hours of practice. Compared to other skills we use in our work (like, say, programming in a new language), this is a remarkably small investment of time for a huge return.

Can you use vertical slices when you have 100+ people working on a single product?

When you have multiple agile teams working together on a single product, there are two primary ways you can organize: feature teams or component teams.

Feature teams are organized so that each team is sufficiently cross-functional to deliver complete slices of value (i.e. “vertical slices”) over some or all of the product. Depending on the size of the product, feature teams may specialize in parts of the product, effectively creating sub-products, or they may be able to work on whatever is most important across the whole product.

Component teams, on the other hand, are organized such that each team focuses on a particular component, architectural layer, or technology. Delivering a complete slice of value requires the coordination of the efforts of multiple teams.

Let’s consider a specific example of a fairly large business application. I was just looking at an accounts receivable report in QuickBooks, so that’s fresh in my mind. Let’s use that. (Note: I have no idea how Intuit’s QuickBooks teams are actually organized or what the technology looks like, and it doesn’t matter for now. We just need a familiar software product to reason about.)

We use the QuickBooks Online product. There’s a web front end. I presume it talks to a back end of some sort, probably via some service interface. There are batch processes like pulling transactions from banks, processing payroll, paying bills, and doing various things with taxes.

With a component team structure, you’d have web teams, for example, who could make changes to the web user interface but who would likely depend on back end teams making corresponding changes to their part of the system. Coordination across teams would focus on making sure their work aligns to provide value.

With a feature team structure, you might have a team or small group of teams responsible for, say, the general ledger part of the of user experience, another responsible for the reporting, and a third responsible for payroll. Each of these teams would have the front end and back end skills on their team. In this case, coordination across teams would focus on making sure design and architecture align throughout the product.

The same product, but with teams organized two different ways for two different sets of outcomes and tradeoffs.

So, the answer to the question of whether vertical slices are relevant at scale depends on how you’re organized. Component teams are an explicit decision not to work in vertical slices. Component teams could coordinate their work around larger vertical slices like MMFs, but at the work item level, they lack the cross-functionality required to complete a vertical slice within a team. In other words, structuring into component teams intentionally gives up the list of outcomes above in order to optimize for something else (usually easier architectural alignment or higher utilization of specialized technical skills).

Feature teams, of course, make the opposite tradeoffs. They’re designed to deliver vertical slices and get all the benefits I listed above (with the cost of needing to explicitly coordinate for architectural alignment).

Feature teams vs. component teams is about the primary organizing approach. Naturally, there are nuances and hybrids and change over time. I’ve blogged about this before, particularly in the context of transforming an organization with a big legacy product.

Should you ever have 100+ people working on a single product?

Now, there’s a more important question in my mind, which is this: Regardless of whether or not we can use vertical slices on a large product or project—and as I’ve shown, we can if we organize in feature teams—is it actually effective to have that many people on one effort?

Each person or team added to a single product (or project) brings some productivity and some coordination overhead. A project of one is nearly pure productivity. Add a second person, and you don’t get twice the productivity—you get some incremental productivity, but some portion of both people’s time is now devoted to coordination. Add a third person, and you again get an increment of productivity plus increased coordination overhead. This coordination load increases exponentially with the number of connections between people.

We mitigate this to some extent by organizing into teams, so that each person only needs to coordinate on the details of their work with a small number of people, and by attempting to divide the work between teams to minimize dependencies. But the more complex the work, the less predictable the dependencies, and the more likely coordination between teams will need to happen.

Thus, at some point, adding another person or team not only fails to add an increment of productivity but also imposes a coordination cost across the whole system, such that the overall productivity goes down.

value-coordination-team-size

Exactly where this point is is highly context-dependent. But the shape of the curves ought to at least make us suspicious of large projects and hesistant to add people or teams.

This is especially the case for complex work, where we’re likely to learn about the problem and solution as we do the work. And in software development, complexity seems to be highly correlated to value. If it’s valuable, it probably doesn’t exist yet. And if it’s new, we’re highly likely to learn something as we do the work.

Conclusion

Yes, you can work in vertical slices at each level of detail and on large and small efforts, and there is great value in doing so. But at the larger scale, you need to organize in a particular way: in feature teams, or in some hybrid that emphasizes the delivery of features. And while you’re at it, it’s worth considering whether being that large actually serves your needs.

Last updated