Incremental development approaches: walking skeleton or start from the end

Agile methodologies are replacing waterfall software development in the software development industry. Instead of a big design up front, they apply processes that encourage incremental development and early integration of functionality. Agile development means more than just small increments, but in this post I want to concentrate on this aspect.

Read more: Incremental development approaches: walking skeleton or start from the end

Companies adopt agile concepts because they come with a number of advantages compared to waterfall methodologies, such as improved planning accuracy. The basic idea is that delivering functionality in short increments makes the overall progress more tangible, which in turn improves the manageability of the project.

This suggests that it is better to have smaller increments. But how small? I think that those increments can be pretty small. In my experience, when we as a development team learned to create small user stories, the planning accuracy improved a lot. Splitting stories made it also possible to change priorities of the work as the business priorities change. But eventually we hit the bottom: making stories even smaller would increase the overhead of managing the backlog too much. This is an interesting result in its own: in the past, we had big stories that we felt were impossible to split, but today the stories are so small that splitting them would be a waste of time.

As far as I can see at the moment, there are two main approaches that can be applied to split a large feature into user stories that are so small that a number of them can be delivered in a single sprint. I’ll call those walking skeleton and start from the end, for lack of a better name.

Walking skeleton

When you search on the internet for “Walking Skeleton”, it turns out that people may attach a different meaning to it. The C2 wiki cites Alistair Cockburn (who first defined the concept) as

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.

Alistair Cockburn

This definition is centered around software development, where most architectural decisions are not yet made. However, there are also people that relate it to the Minimum Viable Product; but this is the product as seen from user perspective: what is the minimum set of functionality that the user needs the product to do before it is actually usable.

This definition assumes new development, but the walking skeleton approach is also useful when applied to new functionality of existing software. The walking skeleton approach basically consists of two steps:

• Implement the walking skeleton itself: the smallest possible end-to-end version of the feature
• Extend on the skeleton to flesh it out to a complete feature or product

This approach optimizes for early delivery of a working product. This has big advantages. It ensures that people are on the same page when talking about the product, as it has become tangible. People can experiment with it. And, once the skeleton walks, there tends to be much flexibility in choosing the next steps. Will you improve the user interface? Or improve error handling? Or support more database? That even can be worked on in parallel.

As you can see from the quote, it assumes that the main architectural components already exist. I think this is not necessary, although it helps to have an idea of the architecture. Since we’re talking software, the architecture can also be developed iteratively. This makes it possible to postpone architectural decisions until we have the needed information.

Start from the end

For many things, it can be useful to start from the end and work backwards to the beginning. This can also be useful when developing software.

If the end product is not very clear yet, you can start by building a user interface that is fed with mocked data. That way, stakeholders such as product owners can develop a vision for the product. This basic UI-without-actual-functionality can be used to derive which actual functionality is required. You can use it to show potential users and see how they like it. This can be a very useful approach to establish what the minimum viable product must look like.

Compared to the walking skeleton, this approach optimizes towards the desired output of the product, be it computation data, user interface or the API to be exposed. This can be useful when the definition of the output must be established early on, for example when other teams use that as input for subsequent processing steps. However, this comes at the cost of delivering functionality early. Another drawback is that the work order is more fixed.

I think it is important to make clear that working from the end does not mean that the end must be completely implemented before the next step can be made. Having a perfect user interface cannot be a goal in itself. When employing start from the end, the goal should be to work backwards as early as possible, so that a functional product emerges as early as possible. You want to spend as little time as possible to the mocked data, since it must be thrown away later. Also, working with real world data provides often feedback that mocked data cannot provide.

Now the starting from the end and walking skeleton approaches are not strictly separate. They can be combined to some extent. For example, the first priority may be to define the output correctly using mocked data, and using that, the remainder of the walking skeleton may be implemented.

In my opinion, I think the walking skeleton approach is usually the most useful. Providing working software is more important than having the outputs clearly defined. However, I came across situations where this was not the case, where starting from the end turned out to be a useful alternative. Starting from the end can also be useful to get user feedback quickly, and then refactor the product into a working one.