Technical Debt and Prototyping

Currently I am preparing for my IREB Requirements Engineering Certification and I read (and already knew before) that in Requirements Engineering creating a prototype is a method and tool to validate requirements.
A prototype should always answer a beforehand defined set of questions. Further, there are two basic types of prototypes.

1. Throwaway Prototype - the prototype is not used further in the development process apart from being a technical example.
2. Evolutionary Prototype - the prototype itself is continuously developed further until it becomes the final (or a shippable) product.

The question is, what role does prototyping play in agile development?

Let's first have a look at the dimensions of a prototype. The wikipedia article about prototyping describes the two dimensions of a prototype as

• vertical (in german also known as "Durchstichprototyp"), in the meaning of a slice of the system to be developed, including frontend, business logic and persistent.
• horizontal, in the meaning of an almost complete implementation of a single layer of a multi-layered architecture. I guess, the most common example of a horizontal prototype is a UI prototype. Also common are interface stubs.

I would assume, that vertical prototypes are closer to the principles of agile development, as they are more "something that is done" than a horizontal prototype.

Why is that?

In agile the concept of "technical debt" is known as a measure of design or software quality, or better, the lack of it. There are some strategies to deal with it, as described in the DAD's "11 Strategies to deal with technical debt".  Further, agile or scrum, aims at producing increments that provide value to the customer, in most of the cases, the "value" reflects some additions or changes to the UI, that the customer can validate relatively easy.

A vertical prototype is a potentially shippable or consumable piece of software in the meaning of agile. It is functional and it is done. Maybe it needs some refactoring, but basically the amount of technical debt is relatively low. One could even say, that producing an evolutionary, vertical prototype is doing agile (if done right).

On the opposite, a horizontal prototype produces only an artifact on one single layer of the software, which is in most cases the UI. The customer can validate, if the prototype reflects the requirements. But, the prototype itself provides no real value, as it is a dysfunctional piece of software, as all the stuff behind the UI is not implemented. In other words, a horizontal UI prototype is a huge pile of technical debt. The more complete the prototype is, the higher is the debt.
If a evolutionary, horizontal prototype is the starting point of the implementation (i.e. the product of a pre-project or the first iterations), it is relatively difficult to plan backlog entries for the further iterations with increments that "provide value" from a customer perspective. Ways to deal with it could be:

• deliver only small increments that add value (i.e. slight adjustments to the UI) but that take more time than one would assume they would take. For example changing the background color takes a week. 
• define the disabling of elements of the UI as added value and focus on only one element that is actually implemented, and the continue as ususal. This means actually to make the evolutionary prototype a throwaway or least major parts of it.
• call a spade a spade and track it as chores that provide no actual value but a reduction of the technical debt and the stakeholders have to bite the bullet for getting several iterations with no added value

My suggestion would be to use either horizontal throwaway or vertical evolutionary prototypes.

The throwaway protoype - especially UI prototypes - could enrich the requirements descriptions as it provides a clearer vision, how the system should look like and partially how it behaves. Creating this prototype should be the job of the product owner or her assistant's. Wireframe models are a good example of such a prototype. The prototype can be decomposed into smaller user stories or tasks the development team implements, while keeping the entire prototype as a detailed version of a vision.

The evolutionary prototype is actually developed during iterations of the development process and it should always be of the vertical dimension which ensures, that every iterations produces something that is done.

Concluding, I would make the three suggestions:

• if using a prototype as part of the requirements definition (job of the PO), use a horizontal throwaway prototype. I'd recommend a wireframe model.
• creating a vertical evolutionary prototype is developing the product in an agile or at least iterative way
• avoid creating horizontal evolutionary or vertical throwaway prototypes as they produce high technical debt or are unfinished work, which is bad.

tl;dr

	horizontal prototype	vertical prototype
throwaway prototype	good done by PO as part of requirements	bad, use only to demonstrate general feasibility to reduce high risks (proof-of-concept), produces waste
evolutionary prototype	bad, produces high technical debt, avoid if possible	good, actual potentially shippable increment, done by development team