Frame of reference for vertical slicing

Question

We have been hearing the concept of 'vertical slicing' a lot lately. I think we have been doing a better job of creating smaller, more well-defined stories. When I was searching for info on vertical slicing, no one has been defining how large their systems were. For example, I saw one where Adobe contracted with mountain goat software to come up with a solution for getting features done vertically, even across several teams.

For more info on me, my background was with a larger corporation where teams were responsible for certain back-end systems, and we'd have to work over at least two sprints to get things done as a 'feature'-- there was the back-end work for the other system, and the integration work for our system. My point is that the frame of reference for vertical slicing in that company was somewhat at the 'project' level. A project can be a complete set of databases, backend server, background services, message queuing/processing, etc., but it was well defined around a central company project.

Our client-facing web app, for example, had multiple DBs of its own, it pulled from several data stores that other projects dumped information into, had batch apps that ran nightly, read and wrote from and to several message queues to send emails to customers, etc. Even with all of that, all the 'deliverable features' were vertical within the 'project'. The stack usually went: client -> web server -> database or web service.

At the new company, we have a pretty tangled network of projects with only a few devs (I had more devs on my team at the last company, and we mainly just integrated with other systems).

For any given feature lately, we have to make changes to the following:

1. Data work in a popular cloud-based CRM (there is a separate team for this)
2. on-site database work, usually only 2 or 3 of the DBs are touched for a given feature 3.Two separate API service apps - one is in maintenance mode until all the apps can be upgraded to the new API. Both integrate with 1. and 2. above.
3. Multiple clients that connect to the old API
4. Multiple clients that connect to the new API (some connect to both)
5. The old API calls the new API for some stuff so we only integrate major logic in one place as we are waiting for the clients to be updated.
6. We have multiple processes run as service apps or batch apps on app servers.

* note that each web client also has its own back-end server, not shown in the diagram.

My frame of reference for attacking this and creating user stories is similar to my experience at the previous company, mainly because of the following factors:

1. Team size (2-3)
2. User Story size (8 pts)
3. Sprint length
4. varying client-side technologies
5. I feel that a user story should be able to be tackled by a single person in order to track completion more easily. In some cases, the work could be split, but it'd likely be at the horizontal level at that point ("Can you do the database work while he does the back-end logic, and I'll do the UI?").

I think the biggest thing that we're worried about is the 8 points. Management is flexible on this, but not very. It's hard when story points are 2-3 hours. What I've proposed is that we have a 'project' frame of reference. I believe that getting the feature implemented in the new API, for example, is a good accomplishment in 8-13 points. This can include the database layer, etc., so it's still a vertical slice within that ecosystem, but we're horizontally slicing the systems.

After that, each client app can be its own story, as they each have their own client and server code, as well as the API integration.

We (devs) typically try to use one [TFS] feature for the main back-end systems (business logic) and one [TFS] feature for client apps (integrators of the back-end systems). We track large-scale 'features' requested by the business as Initiatives or Epics when they touch a wide range of applications, and for those we could have one feature per client app. We could tackle 2-3 features in a sprint like this, and it's easier for us to track as devs vs. trying to have one story to accomplish this, which spans multiple service implementations and web apps.

Are there pros or cons to either approach, and do you have any additional experiences with vertical slicing across a large chain of applications/services?

Answer 1

The main disadvantage of doing the horizontal slice of 1 back-end story and N front-end stories is that you will have nothing to show to the customer if you have only implemented the back-end story. This means that the customer can't give feedback if there was a misunderstanding and the back-end does not retrieve quite the right information.

As an alternative, you could start with a story for 1 front-end application and the API of the back-end. In this story, the back-end would just return plausible dummy data without actually touching the database. This gives the customer the possibility to give feedback, even though the system as a whole is not fully functional.
In the following stories, you can implement the actual back-end and the other front-end applications.
_{If your team is confident they can deliver both the first front-end and the full back-end in one sprint, then obviously they can skip the stubbed version of the back-end in that case.}

In the slicing theory, the story of the initial front-end with a stubbed back-end is still seen as a vertical slice, because it delivers a tiny amount of business value to the customer. The thing to be really careful about is to avoid that the customer starts to think that the stubbed back-end is actually fully functional.

Answer 2

I find that when you have many dependencies like this it 'breaks agile'. Basically you are forced to write a spec for the dependent system changes, even if it's just 'in your brain', based on your expected requirements for the end product. These then turn out to be wrong, or delayed, or dependant on another team, or whatever and muck up your sprint.

One way to get around this is to make your dependant services more generic. So instead of service.getCustomers, service.GetOrders for example you expand it to be service.queryAnythingDymanically.

Instead of DataAccessLayer.RunStoredProc you change to DataAccessLayer.ExecuteEntityQuery etc

This then reduces the situations where an upgrade to the dependant service is required by a 'front end' change.

There are downsides though. The more generic a service is the harder it is to test, performance may drop and security is harder to verify.

Another approach is to use a microservice architecture. This can reduce the difficulty of adding new features because rather than having to change an existing service you simply add a new one.

for example service1.getOrders -> service1.getOrders + service2.getNewStyleOrders

you still have to implement the features 'all the way down' but you are freed of some of the backwards compatibility and dependency concerns.

However, moving to this style of architecture is not as easy as it may seem. where before you had a clear service1.getOrders endpoint to connect to, you now have a more asynchronous message system, watch for lost messages, have to know what types your service can handle and ensure the whole thing is orchestrated etc