#socrates15: Embracing the Walking Skeleton
From the sessions I joined at SoCraTes 2015 two of them were entitled:
Both sessions reminded me on a recent incident we experienced in our development team. And they were an eye opener spreading a new light on what I perceived as miserable failure before.
The team I am working in had the task to develop a feature set with huge architectural impact to the product. Over some weeks the feature set grew and the feature became alive and kicking. But after a code review we detected some architectural problems which from the outside could be perceived as stupidity. As consequence we spent one sprint in fixing and rebuilding the architecture.
I felt as if we failed miserably and could not answer the question: “Why did we fail?”
The Walking Skeleton
From Alistair Cockburn (2008):
A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.
Compared to a spike which as given by Alistair answers the question “Are we headed in the wrong direction?” a walking skeleton is able to provide answers very fast to the question “What are impediments we have to challenge?” This is where it becomes important to embrace failures.
Embracing failure actually means to accept the fact that we are all about to fail sometime. And instead of struggling with it take it as a chance to learn from it.
To me the advantage of embracing failures is to get decisions fast as it is no problem but even a chance for learning when failing.
Embrace the Walking Skeleton
Thus to me both mindsets/approaches are about speed. While you get your skeleton going it will fail. And it is good that it will fail as you will learn from it, help up the skeleton and continue. I even argue that you should push your skeleton to directions where it will fail even faster just to learn faster.
So give some free hugs to the skeleton 🙂
After these two sessions it was totally clear to me, that it was not important why we failed. It just was good that we failed and that we learned from it. Thus without having named it that way, we had developed a walking skeleton and bit by bit added some flesh to the bones. We mastered several challenges like architectural changes to the existing code and we learned a lot in a short amount of time. The failure I perceived just was a result of being fast.
At the end my summary is, that we could not have done better than that. Without having the skeleton walking we would have required weeks of planning, sketching and perhaps doing spikes. But having the skeleton the final architecture evolved quite naturally as every knowledge we missed before was at hand.
And now? We are just about to send another skeleton walking around…