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.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

  1. Great article and completely agreed. In addition to your list of vertical slice benefits, I think there is a psychological aspect to delivering complete end-value as a team and seeing it improve the life of the customer. It is motivating to see your slices create an awesome product the customer (and team!) falls in love with.

  2. I just stumbled upon this article and it’s exactly what I needed to present the case of how to restructure teams to facilitate bringing problems to the team instead of having individuals tasked with specific components of the system. Once again, thanks Richard!

  3. I know this post is 2 years old but it is very relevant to what we are going through here. My biggest challenge is source control. I see the same issue whether feature teams of component teams are used. In a source controlled environment we work in branches – say one DEV and on RELEASE to keep it simple. My problem is that the DEV is in constant evolution. So let’s say we have a fairly narrow vertical feature slice that involves all components from the transport layer to the UI. When DEV is done and it’s been tested along the way (lean teams in place), we are ready to release – even internally to our QA environment. The code is then promoted (or merged) to the RELEASE branch and DEV continues to the next vertical slice. Now let’s the QA team finds a major issue in a foundation layer. The first vertical sprint has to be reworked and the modifications will be done in code that has evolved since then. When the fix is done, how is the first sprint redelivered to QA via a merge in the RELEASE branch without including the not-yet-ready second DEV sprint? Cherry-picking should not be an option.

    • Hi Patrick,

      Thanks for the comment. Sounds like this is telling you something about the time it takes to get feedback on what you’re building. This is why Scrum assumes QA is part of the development team rather than a separate team. So, I’d be looking for ways to get better, faster feedback about the doneness of a thing before moving on to another thing. You want to get to a place where a feature is actually done when you call it done. The answer is probably a mix of better integration of QA into development and better engineering practices.

      Richard

      • Thanks Richard. In fact, we do have several procedures here to put in place before everything runs smoothly, and your article will be referenced in my proposal. Good work!

  4. I see two levels of scaling. Scaling in terms of product size versus scaling across an enterprise supporting multiple products. I agree that vertical slicing (feature organization) is appropriate within a product, but when complexity crosses various products, I’d rather split the work than split the teams.

    As an example, let’s say that Quickbooks changes from a client app to a subscription based web app. We now have a new feature in Quickbooks – renew subscription that must interface with work in Intuit’s Billing and CRM systems. How do we slice this work? I’m suggesting dividing work among the Quickbooks app teams, the CRM team, and the Billing team versus pulling members from each of the three teams to create a new “feature” team. The existing teams will efficiently deliver the required work after architects divide placement of function across the teams and the teams agree to interfaces.

    • For a one-off effort that involves multiple products, I’d agree. However, if the customer experience cuts across what the company considers products and there’s ongoing work in this area, I’d consider whether it needs a cross-functional team. The question of what’s a product (and, related, what’s a vertical slice) should be answered from the customer’s perspective more than the code perspective.

Richard Lawrence

Is co-owner of Agile For All. He trains and coaches teams and organizations to become happier and more productive. He draws on a diverse background in software development, engineering, anthropology, and political science. Richard is a Scrum Alliance Certified Enterprise Coach and Certified Scrum Trainer, as well as a certified trainer of the accelerated learning method, Training from the Back of the Room.

Connect

richard.lawrence@agileforall.com Twitter LinkedIn Subscribe to RSS Feed Blog posts by this author