Working Small: Skeletons Over Sprints

Several years ago I stopped using sprints to help newbies learn to be agile. I found that newbies manage risks better, experience less friction and achieve better outcomes when we remove the time pressure of working in sprints and instead focus on producing walking skeletons. This has surprised some people, particularly those who began their agile journey with some form of a timebox (sprint or iteration) and the ceremonies within and around it. I was one of those people too and I've changed. Why?

Before answering that question, let me pose another: What's the purpose of a timebox? The purpose is to complete a small, useful thing, from which you can quickly learn via reflection and/or feedback. Let's call that "working small." Scrum calls the small thing you focus on making a "potentially shippable increment." In the 1990s, Scrum and Extreme Programming began popularizing the idea of working in small timeboxes (where small used to be 6 weeks and has gradually shrunk down to 2- or 1-week).

The common notion is that sprints help us work small by adding a time constraint. If you don't get the small thing done by the end of the sprint, maybe the small thing was too big or maybe you're just not good at estimating? Whatever the case may be, if you don't get the small thing done by the end of the sprint, you might make some modifications. This is where inexperienced teams often get into trouble. Here are some unfortunate modifications that are commonly made:

• Lengthen the sprint: "Two weeks is too hard given our environment! Can we please make our sprints 3-weeks long?" This is unfortunate because it doesn't help the team get better at working small.
• Pad estimates: To be sure you can complete what you set out to complete in a sprint, you pad your estimates. Now you take something you could easily complete in two weeks and spend two weeks supposedly working on it.
• Decrease quality: When you're at risk of not completing your work by the end of a sprint, you find a way to get the work done by decreasing quality. In software development, this could mean not improving the design of your code ("refactoring") or failing to invest in future safety and speed by not writing automated tests. This is how software begins to become expensive to change and maintain.

These dysfunctional modifications make teams less agile.

I've certainly worked hard to train and coach teams out of such dysfunctions. But it's bugged me that the same problems keep arising with every new team. Stress responses due to timebox pressure were the main reason to focus on walking skeletons instead of sprints.

So What Is A Walking Skeleton?

A better way to handle unfinished work in a sprint is to understand why you were not able to complete the small item on time and with the appropriate level of quality (see Sufficient Design). The typical problem is that your small item wasn't small enough. This often means you've got more to learn about evolutionary design and how to produce a walking skeleton.

A walking skeleton is an extremely primitive whole, with little to no flesh on the bones. For example, if you're building a rental car reservation system from scratch, and you're given a problem like, "users need to be able to reserve and return a rental car", your walking skeleton could be an utterly primitive solution that initially allows the user to only reserve and return a basic vehicle from one city, with no support for upgrades, coupons or cancelled orders, etc. The user interface would be totally unpolished, you'd have some really basic middleware logic and you'd record the transaction in something resembling a database. Another term for this is a "vertical slice" because it cuts through the various horizontal layers (ui, middleware, database).

Most beginners need help at vertical slicing to produce walking skeletons. Beginners tend to put too much flesh on the bones, producing more detail or more functionality than is first needed.

Aren't Time Boxes a Good Forcing Function?

Proponents of sprints say that they act as a forcing function, a behavior-shaping constraint (in the form of a deadline) that helps newbies learn to work small. That's the theory. In practice, we often see teams doing the same work as always, only chunking it into 2-week sprints, or teams padding estimates or lengthening sprints, or not finishing stories and pushing them to the next sprint or decreasing quality to meet a sprint "commitment" (recently renamed to "forecast"). All of these maneuvers don't get the team closer to working small.

And that's one main reason why I prefer to skip sprints and focus newbie attention on successfully producing walking skeletons. Newbies need actual training in how to vertically slice work, followed by testing, building and integrating their work to produce a walking skeleton, followed by reflecting on how well they did and what they could improve.

I ask them to aim for the shortest window of time possible to complete the work. That tends to be between 1 and 4 days on most software projects. If they need to go into a 5th day to make sure quality is high, so be it. We're working small and we aim for the right functionality and quality given where we are in the evolution of our software.

Eventually, they'll be conducting rapid experiments that may take only hours to complete, followed by reviewing the data and deciding what to do. The cadence of this work doesn't fit neatly into a standard-sized sprint.

But Don't Teams Need A Regular Cadence?

I hear that a lot. And nothing stops a team from having a regular meeting on some regular cadence. For example, you could showcase the software you're producing to key stakeholders and other interested parties on every other Wednesday afternoon. Great, but you don't need to work in sprints to do that.

And what about coordinating the work of many teams? OMG, that's high risk! And when we have high risk we need walking skeletons more than ever! The various teams must effectively manage collaboration and integration risk by producing primitive, but working, versions of the product and adding flesh to the bones over time. A focus on evolutionary design helps you manage risk across teams far better than coordinating work around sprints. I've seen too many product teams organized as numerous component teams fail to integrate early and often, fail to produce working software and ultimately fail to hit important deadlines.

A Real-World Example

I once worked with a team composed of mainframe programmers, data warehouse programmers and Java programmers, as well as subject matter experts, product managers and others necessary to be successful on an important new product. It was a genuine cross-functional team, co-located in a fantastic space with caves (for private work) and commons for group work.

This team was tasked with re-building a vital report based on new data and new math. The report helped companies decide how to spend advertising dollars and was about 1 foot thick in height, with lots of complicated calculations to produce the final numbers. The team now had to change all of those calculations and produce a new version of the report with two sources of data, not one.

We approached this problem by identifying a vertical slice of the report: a one-line version of the report that would use the two data sources and produce a mathematically correct report. The mainframe programmers worked with the data warehouse programmers, who worked with the Java programmers to produce the 1-line report. It was a vertical slice that took about 7 days to produce. A bit long, but we reflected on what took so long and got better over time.

Before long, this team was pulling stories from Release 2 into Release 1 because they were so far ahead of schedule. They'd mastered the skill of walking skeletons and were easily completing work.

Sprints Are Deadlines - Am I Anti-Deadline?

Nope. Not at all. Deadlines are often inevitable. Some actually are made-up, but I won't get into those. For real product deadlines, you've got high risk. I approach high risk by producing walking skeletons (of what will eventually be a shipping product) as soon as bloody possible. The walking skeletons help people focus early on high value and high risk. Deadlines are far less scary when you bargain hunt, vertically slice, continuously integrate, showcase your work, learn from feedback and quickly iterate.

On the other hand, constant deadline pressure created by regular sprints may in fact be less helpful than we once thought. Hopefully this article inspired you to consider experimenting with alternate approaches. I'd love to hear what you think in the comments below. What did I miss? Why do you love about sprints or working without them? What do newbies need most and do you think they can learn to become agile faster without sprints? Please share your thoughts!