Do you have to deliver working software in an Agile timebox/sprint?

Question

In the Agile manifesto one of their values is:

Working software over comprehensive documentation

This got me thinking does this value stand in all circumstances? Especially in the circumstance of an Agile timebox (also known as a sprint). Does an Agile timebox/sprint have to deliver working software?

The reason behind these questions started with two other questions:

• Why do we have sprints? I've summarised the most important points of my thoughts as follows:

Projects are large pieces of work which at the beginning lack detail in implementation and have lots of unknowns. Sprints allow us to tackle a project through smaller chunks of work delivered frequently. This reduces the risk of spending resources on the wrong implementation as we can deliver things earlier, learn from it through testing and adapt to what we learn from uncovering the unknowns.

• What are some abstraction layers are in product development? I've summarised my thoughts as follows:

A product is something that satisfies an end user desire or need. It takes end user input and outputs end user value. In between the input and output is how the product functions. If the product is a service, as is often with software, the middle bit can be described as business rules. Essentially how the business converts end user input into end user value. Code is a material in what a service is built, codifying those business rules; in the same sense that wood is a material in what a good may be made of. End users can't use code directly so there's a user interface – this is another layer: UI and UX.

Given the thoughts above, I'd like to make a presupposition:

Business rules introduce the most risk in a product because it is the core of turning end user input to end user value. A product could have the slickest user interface but be useless for the end user because the underlying business rules don't convert the end user's input to value well.

As a result we want to test those business rules before committing a lot of resources into a polished user interface. Let's look at an example:

Imagine a world with no technical constraints that is just moving from a bartering system. One problem you want to solve is how to exchange goods for a medium of exchange (money). You hypothesise some fancy electronic point of sale system is the way forward. You don't have the resources to build it yet or the risk/reward ratio of software is too great (the material, code, is expensive because you have to hire designers and engineers). Consequently, in your first sprint you test out a person acting through certain business rules as a point of sale system (for example: checkout clerk with a paper inventory, a calculator and a ledger).

Now with the above it seems like we have started a project with Agile methodology. Here is how we stack up against some Agile values and principles:

• Working software over comprehensive documentation.
• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

We delivered something working, something to satisfy the customer early and can continuously refine it, albeit not software. We achieved one of the goals of sprinting: reducing the risk of spending resources on the wrong implementation and getting data to learn from for future iterations.

Here are some more detailed questions that may help frame your answer to the overarching question:

• Do the thoughts above mean an Agile sprint/timebox does not have to deliver working software but only something working, where working is defined as something that can test a product hypothesis?
• Given a sprint delivers something that can test a product hypothesis, are there limits to this? Taking the example of a sprint testing business rules, could a sprint deliver just the business rules written down on paper then sending a person out to interact with an end user and compute the end user's inputs by following the rules and measuring if the end user derived value from the output?

Writing this question has been super helpful in organising my own thoughts and consequently I've got some meta-thoughts (which may conflict with other thoughts) I'm still working through which you might want to comment on:

• What I'm describing is just a product development methodology and Agile is a subset of that.
• Writing down business rules is just documentation which isn't as useful as working software. Related to next point.
• Not implementing software means you're testing in an environment too far removed from what an end user actually experiences which introduces risk.
• Building in the order the layers described (business rules, code that computes those rules (which usually live on the backend), UI) is waterfall and introduces the risks of waterfall.

Answer 1

Beyond the four values, these principles are also relevant:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

and

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

and

Working software is the primary measure of progress.

The advantages of Agile Software Development are best realized through frequent delivery of working software.

It's also important to point out that timeboxes are not inherent to Agile Software Development. The words "iterative", "incremental", "iteration", and "timebox" do not appear anywhere in the Manifesto. However, some methodologies are based on timeboxes - Extreme Programming and Scrum are two popular frameworks that use timeboxes. Others do not - Kanban can be used with a continuous flow.

You'd have to ask the creators of each methodology why they use timeboxed iterations. There are some advantages, especially for less mature teams, to ensure that all of the things that need to happen are actually happen. When different events and activities happen just-in-time, it's easy to neglect or short-change events.

The outcome of each iteration depends on the framework. For example, Scrum calls for Product Backlog Items that change the state of the product to be completed in every Sprint. Other methodologies may not have this strict definition. You could define a methodology that delivers value. Various "dual-track" methods also define value in terms of discovery and delivery work.

I would consider your product development process to be Agile if it follows the Manifesto for Agile Software Development's values and principles. In terms of how frequently software is delivered, the only requirement is on the frequency of "a couple of weeks to a couple of months". If you use timeboxes or not or deliver working software at the end of every timebox does not make you Agile or prevent you from being Agile.

Answer 2

Do you have to deliver working software in an Agile timebox/sprint?

If you are building a software product using sprints, then yes, you should deliver working software each sprint. The point of a sprint is to have a cadence of activities and an inspection point where you look at what you've built, collect feedback, adjust your understanding based on the input received and on the current context, and plan your next steps towards your goal. If you don't produce working software each sprint, then you loose on this opportunity to inspect and adapt.

It may happen to any team to have a bad sprint from time to time and not deliver an increment on the product at the end, that's not really a problem, it can occur. But if it constantly happens, then you lose a lot of the opportunities to find out if you are building the right thing. Twelve months later you have a product that the client can't use and you get told that you should have done it some other way from the first month if only you would have had something to show for your work.

However... you introduce an interesting perspective with these questions:

• Do the thoughts above mean an Agile sprint/timebox does not have to deliver working software but only something working, where working is defined as something that can test a product hypothesis?
• Given a sprint delivers something that can test a product hypothesis, are there limits to this? Taking the example of a sprint testing business rules, could a sprint deliver just the business rules written down on paper then sending a person out to interact with an end user and compute the end user's inputs by following the rules and measuring if the end user derived value from the output?

I answered your question in the title with "If you are building a software product", and I said yes. If your product is software, the next increment, or enhancement of the product, will of course be in the form of software. What you are asking about with the other questions looks to me more like an exploratory study or some discovery activity to determine what should go into your software product.

In this case, you might use a Spike inside your sprint to do the exploratory study. Then at the end of the sprint you deliver some functionality in the software product (not as much as other sprints because of the spike), plus the result of your study (in the form of paper forms or whatnot). You then can use the new form of the product and the paper forms to decide what to do next (what to add to the software, if you need more exploratory studies, maybe the paper forms can be enhanced, changed, etc, to gather better information, etc).

In case the spike swallows up the time of the entire sprint, I would pause the sprints while I don't do any work on the software. The new work you add to the software product needs to respect some sort of "definition of done" so that it's safe to release to customers, and this needs to hold from sprint to sprint. If one of your sprints would produce paper forms, then those won't have anything in common with your "definition of done" for software features. So it doesn't quite fit with the rest of the sprints that produce software. In that case, you go back to using a spike of less time, or (personally) I would use a different product track for it:

• one software track to develop the product and deliver software;
• one exploratory track that delivers information, knowledge, insight into what should go next into your software project.

You can then switch between these tracks as needed, like this:

or like this:

You thus keep things nicely organized, you don't have to mix different results with the same "definition for done", your metrics don't get messed up from one type of sprint to the other, etc. Both tracks can also go on at the same time if you have people that can work on the software product while others mess around with paper forms in search of insight.

Of course, this is more work and needs more coordination than using a spike with other work on a single track.

An even simpler approach would be to use Kanban and give up on sprints and spikes and tracks altogether, and just work on the next thing that's needed and brings value (be it paper forms, interview with users, or building features into the software), then decide on a cadence for introducing some inspection points so that you can still gather feedback and adapt your next steps towards your goal.

Answer 3

As mentioned by others already - sprints are part of Scrum. They have nothing to do with Agile.

It used to be that Scrum Guide stated the ideas clearly, but the further we go the more obscure it becomes*. Current Scrum Guide says we have to deliver an increment by the end of the sprint, and the increment relates to "value". It seems that the authors are trying to cover a large number of situations with 1 tool and that's why they're trying not to be precise. So.. I think that the document itself is trying to say that no - you don't have to release a new piece of functionality to PRD at the end of the Sprint. But what most people consider Scrum - would result in a release at the end of each Sprint.

Why do we have sprints?

That's a great question. And I hope that you (and everyone else) will realize some day that we don't need them.

Sprints allow us to tackle a project through smaller chunks of work delivered frequently.

Sprints by themselves don't facilitate frequent releases.. You can do this w/o them. Moreover - oftentimes you could deliver faster than Sprints. You can use Just-in-time and/or Continuous Delivery to release software much more frequently than what you'd do with sprints.

What I'm describing is just a product development methodology and Agile is a subset of that.

Agile development simply means that if you see how you can improve your process - you improve it. It's not a methodology, it's a mindset that allows to create/change your process.

Writing down business rules is just documentation which isn't as useful as working software. Related to next point.

Writing requirements (seems like that's what you mean by documentation) could be a stepping stone to a working software, which is done later. So sure - the working software is better because it means that more work has been done. Both in continuous methods (ToC, JiT, CD) and in the time-based approaches (Waterfall, Scrum) you'd first write requirements, then you'll write software.

Agile Manifesto when talking about software-over-documentation refers to:

1. Dev processes where if you want to do something (send code for testing, deploy to some env, change configuration, etc) you'd have to fill plenty of documentation. So it's about red tape.
2. Cases when you'd write lots of requirements upfront before implementing it. And this isn't cool because after your first release you'll find out that you've made many mistakes and a lot of those requirements are useless. In ToC & JiT this refers to terms "unfinished work", "work in progress", "inventory costs" - the more you've done which isn't released the more it slows you down.

Building in the order the layers described (business rules, code that computes those rules (which usually live on the backend), UI) is waterfall and introduces the risks of waterfall.

Waterfall can mean many things. In most cases people refer to dev processes which release rarely (e.g. once in 6 months). And this is not necessarily bad! Some projects do require a lot of thinking, modelling, simulating, testing before they go live. There are use cases for waterfall (more than many people think).

You keep mentioning "user input" - but that's NOT what we need to build great software. We need information. And depending on the project the most important information may vary:

• Feasibility: are we sure can really implement such an idea - maybe the technology isn't there yet? Or maybe the technology is there, but the idea is prohibitively expensive/slow/inconvenient.
• Education: the more we implement (not necessarily release) the better we understand the domain and the idea
• Investment: are we sure we'll get funded for this idea? Maybe what we need is a prototype and not a real software in RPD.
• And of course the typical goals like: are we sure we're solving our users' problems? That's the case that would definitely benefit from frequent releases.

This also may relate to the stage at which the project is. E.g. at the beginning we'd need a lot of upfront work (some projects need 6 months, others - 3 years). But after the initial work is done we may want to release more frequently. And not only because of the feedback.. Maybe we made a bug and we'd like to fix it soon, or marketing needs this feature quickly because they already promised.

*It looks like they're trying to cover their tracks because each time I'm trying to find the 1st version of Scrum Guide - it gets harder and harder :)