Vertical Slice Vertigo

verticalHow many ways can you slice a loaf of bread?…  all right – now substitute the term work for that loaf of bread.  Not everyone is new to the concept of a vertical slice, but if you’ve just heard the term or it was thrown around in training somewhere- A vertical slice is taking the simplest feature and bias path (happy path) through all the work.  What is the minimum workable software that may reach from the depths of the architecture and up into the user interface (UI)?  This is without shortcuts, and means it is tested to the same high quality as any other deliverable.  We have unit tests, may have test automation, meets the definition of done.  It is another way that a scrum team learns a play from the best practices book in order to reduce risk.  Nor can it be the only play a team ever knows.  We rely upon and trust the teams to consider what is the best play to use under the circumstances.  Many times however, a team can get very comfortable with a single play. They will not consider alternatives.  Hovering around in the same horizontal slice of architecture and not getting up into the light of day.   Take ‘Ro-Sham-Bo’ the gesture game of rock, paper, and scissors.   –  good old reliable rock!

Usually we are talking about a series of stories (work) that will last more than a couple sprints (weeks).  a product owner (PO) might be used to finishing off a single vast stage of development and move on, but early on – the lightest smallest feature through all layers, of the architecture would do several things.

  • Buy down the risk early on by getting a little into everything while not leaving a big unknown to the very end and not get hung up too long in any single aspect.
  • Vet out how to integrate with the tools and processes of an organization
  • Get early feedback from your customers. a single stage might last a couple sprints. that is a long time to not have some course correction, ignore most of the rest of the solution and get help early on for things that might be outside the control of the team.
  • Alignment with the business value.  Are we simply hanging out at this architectural layer because we are comfortable with it?  What if your organization has an adoption of a new tool of 6-8 months.  It may not pay to simply build out it’s integration and features because so much is left unknown about how it may be used.  Perhaps just like our customers vetting our solutions, if we align to more of a just in time as we need it – we will deliver better solutions.
  • Tie into emergent design – just enough to be knowledgeable for implementing and trying, and iterate on a better solution.
  • Keep us focused and time-boxed on a goal of delivering and not lost in a layer that can go on for a very very long time.
  • Train the team to be able to have the conversation up front and make trade-offs in scope and impact before the work is committed.

The Dark or Sunny Side of Software Development?

If as a lead, scrum master, PO or coach, are we sensing there is complete resistance to the idea? Really, this is just another way to think about how to solve a problem and deliver.  Anger and headaches point to immovable, inflexible thoughts rather than honest ability to explore, try and keep moving. Some have fear because so many layers might be involved… but if the exposure is focused and limited this is actually an opportunity to learn and keep the organization’s trust that the team is productive.  I’ve known team to get stuck by work that is HUGE and overwhelming, a vertical slice breaks it down into something far more actionable.  A plan from the bottom to the top.

That said – there are exceptions to most rules AND we ever rely on a balance… There are times when an architectural runway is needed Carefully designed and planned implementation IS absolutely required.  SAFe recognizes that role an architectural team can play in making just enough runway for the teams to use within a release, or the enterprise to set a direction/vision.  What about security and ensuring a best model is implemented? What about testing the performance of the entire release/deliverable?

Some other best practices come from eXtreme Programming (XP -Thanks Kent et al.)

  • Test Driven Development
    • Are setting our expectations first? proving the failure (red) early and often while getting to the pass, or refactoring and keeping it in the good (green).
    • How far upstream does our testing go or are we leaving this till last and having mini waterfalls and delaminating the team by role.
  • Emergent Design,
    • On a very small scale a refactoring of code can be emergent, unplanned and surprisingly successful.  Reduce duplicate code, a few lines that are repeated through several methods… Keep going… separate concerns, overload, pattern, and we might have half the code we did before and now it is much more extensible, robust, and maintainable.  It might even teach us a few things about an area of code we were leery about getting into before but now aligns perfectly with our work.  For very large scale can the experience we gain, when trusting to do a slice of the work, grant us the ability to ever make better decisions as we progress?
  • Pair programming
    • Are we teaching, learning, vetting better alternatives visibly, sharing… Or do we find ourselves wanting to withdraw into our comfortable cave and come back valiant with an answer.  Pairing teaches us to be in the moment sharing and exploring… and forces us into communicating!  Yes, even more brain activity. What about even being non-defensive about a better solution and learning what the impact may be?  Are we talking to convey quick ideas, context, and get some work done according to our goals for the day, sprint, or release? Do we have a patience to grow ourselves or even others?

These are not typically all or nothing. Stay calm and thoughtful for how much are we doing?  Where can we ever improve ourselves in leveraging them? Are we better than last sprint?


A team should not be afraid of getting vertical, of climbing straight up some rock wall.  Some people are afraid of the height and it causes them to stall.  Vertigo.  However it is one way to scale a mountain. Depending upon the difficulty of the work, having as many skills as possible and the flexibility to attack that mountain of work augments our outcome for success.  Keep these in mind as possible strategies to leverage and you will not only rock, you will paper and scissors too!


Please leave a reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s