One of the issues I see a lot out in software product land are teams trying to plan and jam big features or capabilities through their development cycles. Often these are discussed on the order of many weeks or months with multiple, complex, and interrelated projects to complete before any value is delivered to the business. When I ask to look under the covers of these plans, there are a few things (let’s call them symptoms) that show up pretty much every time:
- Horizontal Aspects – The features/projects/initiatives are expressed in terms of technology components or architectural concerns rather than the user or even business level objectives they accomplish
- Fuzzy Dependencies – There are blurry lines between which project will occupy which work and complete which part of the solution and what has to happen when to create something usable
- Value Confusion – There is confusion (or at least disagreement) on exactly when value will be delivered to the business and/or what that value will be
- Low Confidence – The estimates are low confidence hence there is low confidence on the ability to deliver
- High Frustration – The development team is frustrated, the product manager is frustrated, the exec team is frustrated, sales is frustrated = everyone is frustrated
I see this in organizations that think they are agile (or at least on the path). Many of these folks are doing SCRUM and other agile-ish things. Unfortunately, they’ve kind of missed the point by adopting book-agile rather than breaking down their processes and figuring out how to be agile. That’s a whole other blog post that I might write someday (or maybe not, it’s not been prioritized yet).
But I digress, back to the issue at hand: overly long product cycles with too much work in process (WIP) and no clear idea what can be delivered when. There is usually a cultural bias in play as well where the teams often believe that the feature/capability/project can’t be broken down anymore or in any other way without sacrificing the value. They believe that unless they deliver the entire ball of wax, there is nothing worth delivering. I’ve even had people tell me that an entire complex product module had to be 100% complete before there could be any value associated with or derived from it. I personally think this misses the point of iterative delivery and the value of early-feedback cycles entirely.
These symptoms are a pattern that can be traced to how a product backlog is broken down. One of the key drivers here is the use of Horizontal versus Vertical thinking, or slicing. One of the most effective tools I’ve introduced to teams in this state is Vertical Slicing.
Now would be a good time to point out that vertical slicing is not a new concept, and is a time tested and proven method for enhancing a team’s ability to deliver value and iterate on product features. I wish I could claim I thought of it first, but I’m sure I didn’t. While I’ve been using it for around twenty years and auto-discovered the technique, its been out in the wild and delivering iterative value for quite some time based on my readings.
The key to rapidly delivering value is to prioritize and pipeline the activities required to realize the desired value.
The idea behind vertical slicing is to think about the smallest set of requirements that make a feature go and then plan out what is required, and only what is required, to build a complete working version of that, from the backend, the needed services, and up to the user interface. Trim the requirements to the smallest unit of value and then constrain the technical solution to only meeting those requirements. Don’t worry (mostly) about what future needs the expansion of the feature will have. And do not, under any circumstances break the architectural concerns into separate initiatives- no back-end, no app server, no front-end work needed to satisfy the vertical slice can be done outside of the team, or outside of the project/sprint/cycle. The key to rapidly delivering value is to prioritize and pipeline the activities required to realize the desired value.
Ok, so let’s talk about the (mostly) in the above paragraph. We do want to know where things will go so that we don’t select an architecture or design pattern that won’t readily extend in that direction. But we also don’t want to build any of that extension yet. It’s good to know about, and fine to leave room for the future, just don’t try to build it yet. Every time you pull the future into the present, you delay the creation of value.
Every time you pull the future into the present, you delay the creation of value.
What does this mean in practice? That your backend will only implement the data storage needed for this iteration of the feature. Don’t design out the data structures that will be needed 3 versions from now, add those later. Same for any services you need, make them do only what is needed right now. The user interface? It’s the same thing, build only what you need right now. Make the smallest definition of the feature available work bottom-to-top and end-to-end. No more and no less.
Let’s look at what happens when teams learn to vertical slice features and iteratively deliver value. By the way, this is not theory, this is based on real-world results over decades. It looks like this:
- Vertical Value – The features are expressed in terms of business/user value, so everyone knows what the goal is and where the value comes from
- Higher Confidence (that gets even better over time) – The estimates are high confidence because the scope of work takes days to a couple weeks to deliver instead of months
- Solved Dependencies – The projects are isolated and independent with clear lines of what work happens where
- Clear Value – It’s 100% clear what business value will be delivered when the feature iteration is complete
- High Alignment – Everyone is on the same page with what is going to happen, when it’s going to happen, and what outcome is expected
- More Value Created– Early feedback and the ability to adapt without having to rewrite the whole feature over again allows an iterative process of delivering vertical slices of features. This allows you to react to feedback and improve the plans for the feature as you go, resulting in a better overall feature with higher user adoption and satisfaction when it’s fully fleshed out.
Learning to vertically slice requires the willingness to turn traditional planning on its side and rather than decompose fully fleshed out features by their technical tasks and architectural concerns, break them down functionally (functional decomposition) and get to the core of the feature’s value. Then do it again, and again, until you get a feature that the team thinks will take two weeks or less to build.
If you take this on and do it in earnest, you will be surprised by the results. It takes some time to re-orient the team to the change, and mistakes will be made- that’s part of learning and intersects with the need to be committed to continuous improvement, but you should see some early wins that can be reinforced and built upon.