↓Skip to main content

Break down silos with a walking skeleton 💀

#designpattern #planning #collaboration #architecture

Software projects often suffer from silos—frontend and backend teams working in isolation, discovering mismatches only late. A walking skeleton prevents this by connecting all parts of the system from day one.

A walking skeleton #

The term “walking skeleton” was defined by Alistair Cockburn in the late 1990s and popularized within the Agile movement. The Pragmatic Programmer also argued for a similar approach, but using the metaphor “tracer bullets”.

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.

Each subsystem is incomplete, but once connected they stay connected. Unlike a prototype or spike, a walking skeleton is not meant to be thrown away. It is built with production coding habits and is used to kickstart the development of a project.

Illustration of a walking skeleton that connects tiny pieces of each part of the system
A walking skeleton connects small pieces of each system component

As a simple example, the walking skeleton may include a frontend with a single button. The backend API has one endpoint. The authentication layer may accept a hard-coded password. The database has one table. The important part is that all components are connected. A click on the button in the frontend should actually make a call to the backend, passing through the authentication layer, and reach the database.

Each new ticket then adds functionality, putting meat on the bones of the skeleton.

Technical benefits #

There are several benefits of building a walking skeleton from a technical perspective.

  • It proves the architecture: all major components can work together.
  • It shortens the feedback loop, surfacing misalignments and reduces technical risk.
  • It helps the team understand the system, not just from diagrams but by running it.
  • It enables end-to-end tests to from the start.

Walking skeleton as an organizational tool #

A less obvious benefit is that it forces developers to talk. This helps avoid the “silo-by-default” scenario. No longer can the backend and frontend teams go build stuff in isolation and only talk months later when it is time to integrate.

An architecture diagram alone isn’t enough. Teams may still make different assumptions on how the components will actually integrate. The differences will not show up until you actually connect the components.

You may be familiar with Conway’s Law which suggests that an organization will produce software designed to mirror the organization. In this light, a walking skeleton is an “inverse Conway maneuver”, a way to use the software design to change the communication patterns within the organization.

By forcing developers to talk early, you make it harder for technically oriented silos to appear. Instead, it helps discover the natural service boundaries and API contracts in the business domain. Instead of silos based on technology, you can form cross-functional teams that align with distinct parts of the product.

A walking skeleton is not just technical scaffolding, but also an organizational design tool. It aligns both code and teams from day one.