What is a "Walking Skeleton"?

42

12

One of my agile teams has taken an interesting approach in the early stages of their project. Instead of starting the project with a Sprint 0 where they setup code infrastructure and decide on the solution architecture, they have started building a "Walking Skeleton", which they describe as a DevOps practice.

What this seems to come down to is building something very small (in the case of an API a single endpoint that just returns 200-OK), getting this working in continuous integration, and building out the continuous delivery pipeline to deploy this through each of the environments:

Development ► Test ► UAT ► Pre-production ► Production

In the process they have managed to tick off many of the non-functional requirements that could have been missed if deployments were left to the last minute.

My question is this: what is a "Walking Skeleton" and what benefit does it provide to a Agile team following DevOps practices?

Richard Slater

Posted 2017-03-29T11:11:04.717

Reputation: 8 732

1Love this one, I can share an actual (last week) thing and what was the outcomes from this after lunchTensibai 2017-03-29T11:13:34.877

Answers

38

A "Walking Skeleton" is a form of "proof of concept" of your basic architectural concept. Where a proof of concept typically focuses more on a single functionality, a "Walking Skeleton" is a minimalistic end-to-end implementation. A "Walking Skeleton" is not an outline of your concept (only a "skeleton") but is really executable and shippable (it can "walk" :O) and should be accompanied with tests.

Alistair Cockburn has described it (and is being quoted often):

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.

The advantage here for DevOps is that a "Walking Skeleton" should be developed early on in the project and results in working, shippable and testable code. This way DevOps can set up a full continuous integration chain early in the project, instead of being onboarded in the final phase of projects. This means that any issues that would arise are also being tackled in an early stage instead of rush work at the end.

7ochem

Posted 2017-03-29T11:11:04.717

Reputation: 814

4Well, it's not just the CI chain, but it could literally cover the end to end production pipeline, including delivery and deployment. A skeleton of that as well - you don't need to have all QA verifications for the final product in place on day 1, you can progressively add verification "meat" to this skeleton as the story "meat" accumulates on the walking skeleton.Dan Cornilescu 2017-03-29T12:59:49.520

1I like the "meat" term, fits really well with the terminology used :P7ochem 2017-03-29T13:01:34.750

3Great answer. I guess it's the delivery pipeline equivalent of a minimum viable product.Adrian 2017-03-29T15:39:02.237

4This does sound similar to minimum viable product, but at a more granular level- "minimum viable component" perhaps. Returning 200 from a service just to get it "running" sounds like a stub to me.Dave Swersky 2017-03-29T16:55:50.270