Horizontal vs Vertical slicing

I recently started playing a bit of a release manager role for some projects at work, and one of the interesting conversations I’ve been having with people are the merits of slicing projects horizontally vs vertically.

Horizontal slicing

With horizontal slicing, projects are broken up roughly along architectural lines. That is there would be one team for UI, one team for business logic and services (SOA), and another team for data.

One advantage of slicing your application horizontally, is you get good communication and consistency within each slice. Everyone does things the same way.

The downside of slicing your projects this way, is that until you integrate every thing together, you really haven’t delivered anything of value.

Your customer can’t go into production with screens, services, or well normalized database schemas.

Only when all the layers are hooked up do they offer any value.

That’s why agile is so big on slicing projects vertically.

Vertical slicing

Agile is very big on the concept of one team. There is no UI, SOA, or data team. There is only one team, focused on delivering a suite of features for the customer.

The other advantage of slicing vertically is you are more efficient. You don’t have the overhead, and effort that comes from trying to coordinate activities across multiple teams. No need to negotiate for resources. You’re all on the same team.

No. Not always.

Whenever you have legacy systems (mainframes), core business entities consumed by many across the enterprise, or anything where the technology dictates how the application needs to be built, you may be better off slicing that body of work horizontally.

That doesn’t mean you can’t work with them in an agile fashion. More that they will have a certain way of doing things, and you will have to adapt.

So go vertical when you can. And horizontal when you have too.

Thanks to John Kordyback for sharing his thoughts on this subject.