The powerful art of slicing
One of the most difficult things about product development is to deliver razor thin, vertical slices. It’s also one of the most important. Especially during early days of whatever you are building.
Nothing reduce risk like delivering something that integrate the entire value chain, no matter how tiny and useless it might seem. And «deliver» means to put it all the way into production. Ever had problems with networking or firewalls? Misunderstandings on how an API communicates? Access to a database? A third-party that takes weeks to respond to any request? How would you like to find all those problems within the first couple of weeks instead of towards the very end?
The worst thing I see is a team building stuff in the front-end while «waiting» for a component team or third-party. Don’t you dare! No, the user story isn’t done until it works all the way through in production. No, moving on to the next API because the component team below you isn’t done is not okay. I once introduced an “Almost done” column for a team to call out this kind of behavior.
An example
The problem: One of my favorite stories on the subject is a about friend who was a project manager for a new ticketing system. The system would be installed on a client computer in convenience stores. There were loads of integrations to have the whole thing working. To the register in the store, to APIs towards the train company, to a payment module, etc. The system also contained lots of business logic. The ability to buy a bunch of different ticket types (single, return, weekly, monthly), to-from all the different stations, the ability to refund.. you get the idea.
The solution: While discussing this risk over a couple of beers, we came up with an idea. What if you build one feature, make one API integration to each system while hardcoding everything else, and then install a pilot of that initial version in one convenience store?
The result: What they built was this: An alfa version with one button in the UI. Click the button, and it sent an order for a single ticket from the station located next to the pilot convenience store to the next major city. No option to select to/from. No option for other ticket types. No refunds. But in a short time they reduced a ton of risk by identifying any problems with the integrations necessary for the final system. They verified that they were actually able to make it run on the client computer, and connect to the register. They had actual customers walk into the store and buy tickets. They cut lots of risk in a couple of weeks, that they would otherwise be pushing in front of them for months and months.
Think outside the box, and you will always find ways to do stuff like this. It will eliminate or identify risk very early on, and perhaps even detect that the entire project is doomed to fail.
Slice early, slice often!
