Vertical AND Horizontal Slices in Agile Software Development
--
If you’ve been around Agile Methodology for very long, you’ve probably heard the term “vertical slices” with reference to delivering cross-sectional slices of software functionality. And if you’ve read articles on it, you’ve undoubtedly seen diagrams of the horizontal layers through which the vertical slices cut. The best articles also include an image of vertical slices of cake.
This article’s featured image is a bit more sumptuous than a layer cake vector drawing. But I need to ground our appetite in software architecture, so here’s the vector:
This is a software architecture than many larger-scale companies adopt, as it readily separates (decouples) your data from your business logic and your business logic from your public interface. In essence, the data layer is for storage and access of business data, the middle tier is for processing and preparation of that data, and the user interface is for displaying and interacting with it in ways that are meaningful to the business context.
I have fully embraced the vertical slice approach in my day to day development as an engineer, yet I have consistently struggled with the concept. Not the slicing and eating of cake, but the notion that every user-facing story can and should be delivered in a vertical slice fashion. Each time the vertical-slice mantra has felt awkward, I’ve reflected on it a bit. This post explores pieces — slices, if you will — of that awkwardness.
Layered Cake and Layered Architecture
In my humble opinion, every theory must be tested. And in my hungry opinion, every cake must be tasted. But before you can taste it, you pretty much have to slice it. [Except for 1-year-olds with their birthday cake.] Before slicing the cake, it was baked, and before that, the ingredients were combined and it was put into the oven.
I’m sure you enjoyed the reverse-order look at making a cake, but we took that journey for a reason. If you play it forward, it begins with combining ingredients and baking the cake. And if it’s a layered cake, you first bake the layers, then stack them together. With a bunch of icing between the layers and on top, of course.
How is software built? In the same way. First, you combine the ingredients of setup, configuration, key software packages, and other tools to run each layer of architecture. This is code integration. Then you have to bake them, which you could relate to deployment. Once the basic infrastructure is deployed, you still just have three layers that aren’t connected. APIs (Application Programming Interfaces) are the icing that tastefully connect those layers together.
In the same way that it takes time to bake a cake, it takes time to set up, configure, and deploy horizontal layers of infrastructure. And in the same way that it’s a delicate process to ice in between the layers such that it looks like one impressive cake, it’s hard to navigate the complexities of connecting your horizontal layers to each other through APIs. Engineering teams are going to need to spend substantial amounts of time creating and maintaining horizontal layers and their APIs.
Adapting and Scaling
Being attentive to the horizontal layers is not just a one-time thing. You don’t just set up the infrastructure and do vertical slices ad infinitum.
Imagine a layer cake that can feed ten people. What happens if you need to feed ten more people, and they want chocolate instead of vanilla? You have to make another, different-flavored layer cake, which involves mixing ingredients, baking the layers and stacking them together, and adding every child’s favorite part (icing).
And what happens if you need to serve 200 people? It’s going to be much more efficient to make one or two large layered cakes than it would be to make twenty small ones.
These are the problems we face as we adapt, serving different user preferences, and as we scale, beginning to serve more users. We have to redesign to serve different users, and rearchitect to serve even more. Both of these require adjustments in infrastructure and are much more horizontal in nature.
Maintaining horizontal layers is going to take time and effort, and it has to be done in an ongoing fashion, alongside vertical slice stories.
Horizontal and Vertical Slices
Let’s explore what it might look like to allow an interplay between vertical and horizontal slices. First, here are some key indicators for when to focus on the horizontal or vertical:
Aim for vertical slices when…
- You’re adding to existing functionality in an incremental fashion
- There is strong alignment between your data and business logic
- You’re implementing new features with few dependencies
You may need to focus on horizontal slices when…
- New feature requests require new ways of thinking about existing functionality
- Your roadmap includes sharing functionality across previously siloed products
- You encounter scaling pain points
How might you integrate horizontal and vertical concerns as you develop the roadmap for feature work?
Probably the best approach is to determine the appropriate sequencing of your horizontal and vertical needs, then plan accordingly. Let’s say you are building an e-commerce platform and you are in the middle of developing features for product management. Next you want to tackle inventory management for those products. Perhaps it makes the most sense to finish off vertical slices for viewing and editing products, and then shift to horizontal thinking to ensure your infrastructure can support your inventory needs. If not, develop that infrastructure, and once it’s ready, it’s time for vertical slice mode.
If you’re following a framework like Scaled Agile with Planning Increments (PI for short), consider budgeting time at the beginning of each PI to take care of horizontal concerns before you shift to vertical ones. SAFe has a category of stories and epics called Enablers, which can be exploratory, architectural, infrastructural, and compliance-oriented. If you handle enablers up front, it will ensure that the rest of your PI can be focused on delivering customer-facing functionality in vertical slices.
If you’re concerned about horizontal slices taking too much space in your roadmap, you can try to weave horizontal concerns into your vertical slices. However, watch out for story bloat or engineers taking horizontal shortcuts to accomplish vertical goals. It’s called technical debt for a reason — you’ll have to pay it sooner or later. To get back to our cake analogy, a half-baked layer cake is only good if you like…half-baked layer cake.
Conclusion
Cultivating attentiveness to vertical and horizontal concerns will ensure you don’t get halfway into your vertical slice only to discover you’re eating mush instead of cake. If you want to deliver a stable, scalable product to your customers, take the time to consider infrastructure needs in addition to just delivering features.
Any way you slice it, if you’re delivering high quality software at all levels of your application, you’ll have happy engineers in addition to happy customers.
So now you can have your cake, and eat it too!
