I recently had a conversation with two colleagues where I was trying to explain the advantages of frequently delivering thin vertical slices of value, versus working on separated components and integrating at the end.
I have been familiar with this concept for so long, and generally give it for granted, but while explaining it, I found myself at a loss and only after a good while I was able to make my point. That conversation prompted me to write this article so that myself or anybody else can use it in the future for this purpose.
Let’s imagine a typical web application with a UI layer, a service layer and a database layer. Let’s consider the very common case scenario, where our developers are specialised and can either do UI or services or databases, no cross skills exist.
There are generally two approaches to deliver this application:
- Create component teams that define interfaces between the components and deliver each component in isolation
- Create a team that contains all the 3 skills required and deliver small increments of value, i.e. small deliverables that include the 3 layers and are releasable.
The first option, believe it or not is the generally preferred one by most developers and traditional software development managers. It gives the first ones the ability to use their main skill, and the second ones the illusion of efficiency as they think they are using the right skills for the right purpose.
Usually the dreams of component teams are shattered at integration time. Let’s imagine they deliver monthly sprints. Each team at the end of a sprint will believe they have their sprint done, because everything works in their context. What happens in reality is that at integration time, what seemed to be perfectly defined in the interfaces generally is proven incorrect. Things don’t work, teams defend their component design and implementation, blame other teams for the integration failures and nobody takes responsibility for the most important thing of them all: the customer can’t use the value.
By the second sprint, generally the teams decide that they need an “integration testing sprint” [sic] to fix the issues that the teams couldn’t prevent by using predefined interfaces.
This is generally the sign of the start of a slow death of the company ability to deliver customer value.
Time goes by and teams become more entrenched in defending their component and blaming the other components for any failure. Integration testing becomes lengthy and painful and the customer becomes less and less important than defending the status of our component team.
Have you been there? I have, and I bet you did too.
There is a solution.
The secret is to shift, from delivering a component, to identifying a thin slice of value that cuts through all components and the customer can use.
It seems easy, and once you get used to it, it actually is. The problem is the mind shift from system to value. People are used to delivering systems and not to resolving problems, if you want to identify thin slices of value to deliver you need to focus on resolving a problem for your customer abstracting yourself as much as you can from the underlying systems.
The first thing you need to do is to have teams that have all the skills required for the full stack of technology so that each individual team can deliver customer value independently. Like this:
Each user story will deliver a thin slice of value, developers will collaborate and pair instead of communicating through interfaces and the ownership will be on value being delivered instead of software components.
Working like this, the integration issues will appear immediately, as soon as we connect the layers with the first slice of value. This in turn will help us not to build too much software based on wrong assumptions. The first thin slice might be challenging and take some time, but it will contain a huge amount of learning that will be used to reduce the time to build the subsequent slices.
We can expand this same concept to product development.
Let’s imagine our company is an international online wholesale store where clothing shop owners can buy their stock. We now have an opportunity to expand our market by introducing jewellery to our products. The business owners are very excited because they believe that the new product could increase our revenue by 30% and they have identified the suppliers to get cheap stock.
The project Jewellery is starting! Everybody is excited.
After a short period of research we find out that customers living in the Democratic Republic of Regulationstan have some restrictions over the quantity of jewels that can be bought by an individual shop in a period of time. The amount varies depending on the jewels type (gold, silver, platinum). Also, other 10 countries don’t allow watches to be bought in bulk and to make things worse, in the country we live in, Paranoidland, regulation exists for jewels sellers to obtain and store Know Your Customer information for up to 10 years for jewels that contain diamonds.
We could design a complex system that is able to comply with all the limitations and the regulations, implement it and deliver it to be consumed by the whole world in 6 months. Or we could take one category of articles that don’t need to comply to our own country’s regulation and target a rich market that doesn’t impose regulation and deliver it in a week.
The choice will depend on so many context specific factors that I cannot possibly imagine, so I won’t make it.
What I know for sure is that, if we use the second option, there will be a massive difference in the output, the difference is that after one week, our product will receive feedback from its customers. With the customer information available we discover unknowns and making decisions on what to deliver next becomes much easier.
What’s this got to do with component teams and vertical slices teams you might say.
Everything.
By delivering a vertical slice of value in a short period of time, we are able to evaluate it meaningfully, and use the feedback to decide what and how to build in the next slice. More than likely the first slice of value will give us enough information that makes less important or even completely irrelevant some of the slices we were planning to build in the future.
By doing so, we are deliberately discovering the unknowns and using learning as our guide.
The feedback we receive after each thin slice is our compass, every time we release, we get new directions and make sure we are never too far off the path to success.
| Reference: | Thin Vertical Slices of Value from our JCG partner Augusto Evangelisti at the mysoftwarequality blog. |
