38

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?

  • 1
    Love this one, I can share an actual (last week) thing and what was the outcomes from this after lunch – Tensibai Mar 29 '17 at 11:13
33

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.

  • 4
    Well, 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 Mar 29 '17 at 12:59
  • 1
    I like the "meat" term, fits really well with the terminology used :P – 7ochem Mar 29 '17 at 13:01
  • 3
    Great answer. I guess it's the delivery pipeline equivalent of a minimum viable product. – Adrian Mar 29 '17 at 15:39
  • 4
    This 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 Mar 29 '17 at 16:55

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.