Be a samurai, not a lumberjack

Chris Combe (he / him)
4 min readAug 14, 2022

Or breaking down work into small slices of value, rather than big chunks of stuff.

Photo by Krys Amon on Unsplash

Lately, my team and I have been discussing how we best build up a set of practices that can be used to educate and crucially empower teams to deliver value. One of those practices and one of the most important but often neglected areas is user stories and slicing stories by value (vertical value).

Vertical slicing is akin to taking a slice out of a cake and getting a taste of all layers, the icing (frosting), the sponge etc.

Horizontal slicing is akin to taking a layer off the cake and eating that e.g., the icing by itself

There’s other examples people use like a hamburger a bite of the burger vs eating the bun by itself etc.

Rather than profess to have cracked the code or produce my own unique view on how this should be done I thought I’d spend some time highlighting some amazing people and references for you to leverage instead.

One of the natural tendencies of people moving into new ways is to break work down by deliverable (a thing to complete). This has typically been the case because in a project mode where you don’t have cross-functional teams you often have to break work down by the team, rather than by items of value.

When you don’t have cross-functional teams, you are often optimizing for schedule, funding, and scope and quite often that means spending the money you have allocated to the project to get work done in time, even if that piece of work on its own is useless from a user / consumer perspective. Quite often teams are organized by technology or architectural layer (often due to Conway’s law) e.g., the front-end team, the back-end team, the testing team, the release team etc.

If you are breaking down work by teams, you are often breaking it down to a granular level and giving the team a requirement / demand rather than a specific problem to solve. This leads teams to do what is requested and doesn’t give them much of a chance to think creatively and solve problems in novel ways. That is because teams set up by architectural layer can’t understand the wider context — missing the why and crucially how the work they are doing contributes to business value and outcomes.

When you move to cross-functional / product teams, you are assembling a group of people who have the necessary skills to deliver something of value (ideally end to end but sometimes that takes time to evolve towards). That doesn’t imply that your cross-functional team know how to break work down by value in vertical slices as they are often used to getting work handed to them to deliver.

This new skill / capability isn’t something they’ve needed before, so it does require time, focus and practice to get half-way decent.

In a subsequent article I’d also like to explore slicing of value at the portfolio level, and getting the entire system to think in terms of slicing by value e.g. a project or an initiative that only spans 2–3 months and the portfolio itself has a WIP limit on it. That way we are using feedback loops and learning to drive our future direction rather than top down ‘opinion’ pretending to be a strategy.

References

If you have any other’s you’d recommend, please add them in the comments

--

--

Agile architect (socio-technical), coach, ways of working enthusiast. Professional nerd, recovering CTO, explorer, retired DJ and enthusiast of tasty food