The technical walking skeleton

A walking skeleton as meant in story-mapping, being the minimal marketable/ shippable feature set, is not always feasible. When working from existing system environments I am quite inclined to argue that in these situations it is often the best route to base your first product slice on risk rather than end-user value, but only if the support is there to enable you.

I encountered a lot of story-maps based on this principle in financial services lately. The “hello world”-first slice, or walking skeleton, comprised of nothing more than the bare minimum technical necessities to get a working chain environment end-to end. Later being fleshed out with additional functionality.

Most of the times this is the right thing to do, because in most cases there are dependencies with other systems and internal “suppliers”. The risk to see whether the system would work with these external systems later on in the project is too big to postpone, to when the features come up that possibly depend on these external pieces of the product puzzle.
Getting these dependencies out of the way, means seeing a working chain and having a better picture of how things work, mitigating the risk associated with delaying dependencies. For the external factors it means building the essentials and stubbing the rest, creating the barest technical walking skeleton possible, a working end-to-end chain.
Strangely some projects I saw with large amounts of external dependencies did see the value of this possibility, but still decided to go for a more functional first slice of the product, leaving them struggling for months before delivering end-to-end working software. How could this be?
The issue here was, that at the start of the project people all saw the dependencies but none of them could be addressed effectively. The major issue was the fact that all but one external supplier to the project were actually other internal departments that couldn’t/ wouldn’t lend resources and rather stick to their own release calendars (making them real old skool stakeholders by the way which is pretty evil). They also had a lot of problems getting their own environments from outside of the project, which didn’t help as well.
In the ideal world this project should not have started without the necessary support in place to complete the first ideal optimal technical slice in a couple of sprints. Which is actually not so different from when you create a regular walking skeleton come to think of it ☺. Remember to keep a technical walking skeleton an option when working in complex chain environment and or existing system environments. You might be amazed how fast you can get the first feedback, from customers and other stakesharers.
Should you have some interesting other slicing dimensions you would like to share, or you totally disagree with me, please leave a comment below! Many thanks in advance.