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.