Agile Debate: Is Vertical Slicing Useful or Detrimental to Agility?

Agile technique or mechanism needs to follow agile principles of Improvement and customer centricity.

Agile as a set of values and principles - a philosophy for customer centricity and improvement. And it is a way people found themselves working. And there are many Agile techniques or mechanisms which were experimented or tested.

For example, vertical slices are often related to the dependencies between technical stacks. To avoid people wait for each others for progress, a common approach is to define interfaces and create/generate mocks. So people may focus on their slices, but is it still a “Waterfall” mentality? Or will it be detrimental to agility?

The term Vertical Slice implies a focus on the internal/technical aspects of a system, whereas your customers don't really know or care whether you have completed a Vertical Slice, or just tweaked the UI, as long as their feature/story is delivered. But the trick is to always put yourself in the customer’s position and consider whether the ways in which you break down work affect the time to deliver a single story viewed in isolation. No matter how you slice, you must reach agreements with developers who are the only group of people having most comprehensive knowledge of relationships between slices, vertical or horizontal, after fluent conversations. Otherwise, everyone will be in trouble, working in low efficiency while looking busy (some would interpret as productive and fast?). Ultimately, quality and customer satisfaction matter.

Only some simple projects could be sliced like a cake. The cake is not a good metaphor for typical software projects, and a house/skyscraper could be a better metaphor, with similar dependencies, coupling and cohesion etc. Iteration is more than going horizontally or vertically. Thinking that everything can be vertically sliced with high business value and fit into one sprint means not taking dependencies, complexity and risk seriously, which is ultimately a denial of engineering and reality, especially in the beginning of a project, where the team needs to build some foundations. How to communicate and handle this is another question, but it's more an expectation management issue. Technically, if you want to build a good product, you cannot afford not to take these factors seriously. From a management perspective, there is an equally fair option which is - accepting that one doesn't know how to do it. Agile will eventually effectively minimize the "intermediaries" which by nature, inherently are not adding value, but may be able to assist the others to create business values efficiently.

It also depends on the team’s maturity: When the teams are just starting their agile journey from the traditional waterfall, they generally tend to slice the stories horizontal since they are so used to it. Like design as a story, development as another and testing and so on. But training and particularly coaching the team is essential at this point. The sole reason why user stories exist is to create value. So the teams have to realize that functional slicing of the story doesn't create any value to the user and hence it's not a story but just a task within the story. Once the teams are able to grasp this and apply, they will no more create stories that are functional rather write stories as a whole to create the value. Vertical slices work well for mode-dependent real-time systems where functions must be synchronized and events checked in order to start/stop them. In addition, you need to check for exception conditions at the end of each slice to ensure proper operation and performance of the system. If you are going to slice vertically then your process for the vertical slice needs to cover everything you need to do - either in the work you do for the slice or in the additional work you do per iteration, such as the review and the retrospective.

There is a bit of a philosophical debate here. There are those who believe certain things/aspects need to be developed independently of a feature and others suggest that those aspects are developed as the feature is being developed. There is an equally fair option which is - accepting that one doesn't know how to do it. But alway keep in mind of the philosophy behind the Agile - Interaction, Iteration, and Improvement, and focus on customer satisfaction and speed, not just efficiency.

Posted in: Agile,CIO Debate