Prototyping in Agile Environments

In my blog post a couple of days ago I wrote about prototyping and technical debt. After some discussions with my colleagues about the value of prototyping I want to refine my statements a bit further.

What is a prototype?

First of all, what is a prototype? Wikipedia states "A prototype is an early sample, model or release of a product built to test a concept or process or to act as a thing to be replicated or learned from". There are several types of prototypes which basically breaks down to the two dimensions:

• Horizontal vs. Vertical Prototype
• Evolutionary vs. Throwaway Prototype

 To help understand the relations and implications of the various kinds of prototypes, have a look at the following diagram. (The diagram assumes, that front-end (UI) aspects are on the upper side while backend aspects (logic, processing, persistence, etc) are on the lower side and time flows from left to right.)

Basically, a prototype should answer questions to the solution to be built. Therefore, an intrinsic value of a prototype is to help reduce a kind of risk by giving those answers.

Horizontal and Vertical Prototypes

A horizontal prototype may help to reduce functional risk, so the customer can validate if the solution to be developed meets her requirements. A vertical prototype may help to reduce technical risks as it proves that certain architectural or technical decisions are viable. A prototype may also be combination horizontal and vertical aspects, but typically should focus only one of these, for example verifying if certain UI components can be integrated together in the UI framework focuses more on vertical than horizontal aspects.

Nevertheless, in the lean world, most types of a prototype are waste (throwaway prototypes) or potential waste (horizontal, evolutionary prototypes). In order to reduce waste, efforts of producing a prototype that will not become part of the solution should be minimized. The prototype should focus only on reducing risks and giving answers to a predefined set of questions. In other words it should have a narrow and defined goal.

Technical Debt and Technical Credit 

Two aspects of prototyping in agile environments are technical debt and technical credit.  The latter being a concept you do not read often in the agile literature, but which exists if you think the concept of technical debt to the end.

The following diagram depicts the concept of technical credit and is a variation of the first diagram.

It differs from the first one in three areas:

• a vertical throwaway prototypes does not necessarily have to start at the front-end. It could actually cover any part of the technical stack.
• a horizontal evolutionary prototype may also cover other layers of the software, not only UI, and therefore may produce "Technical Credit" as the opposite of technical debt. 

Technical Debt

As it is obvious, a horizontal prototype that is part of the solution produces a lot of technical debt in the first place, especially if the prototype targets at the UI. The customer perceives the solution as finished, but it is dysfunctional from a technical perspective, and most of the feature promises are broken until the technical debt is worked off.

Technical Credit

The opposite of technical debt is technical credit. Technical credit is generated, when something is developed and delivered in advance, that does not provide any immediate and perceivable business value. An example could be an architecture refactoring that provides a simple extension mechanism so that business functionalities can be developed more rapidly. This could cost more in advance than is perceived as returned business value but could cost less afterwards compared with the business values additional functionalities provide. But still there is a great risk of producing waste, for example if the requirements change.

Functional Debt and Functional Credit

The other dimension of debt and credit is the functional. A project starts with a certain amount of functional debt - the product backlog, which is worked off continuously. Further, the requirements engineering discipline refers to the Kano model of success factors:

• Basic or Threshold Attributes - if they are missing, the solution is not accepted at all
• Performance Attributes - some attributes could be missing, but the more are implemented the better
• Excitement Attributes - the customer does not even know they want those. They could compensate for missing performance attributes and may help to exceed the customer expectations (making her a more happy customer).

Functional Debt

Functional debt are features that are implicitly or explicitly (Basic and Performance Attributes) required but are not yet delivered. Working off the functional debt of the backlog is exactly the concept of a vertical, evolutionary prototype, and therefore an intrinsic mitigation strategy in agile processes to reduce functional risks of overall project and maximize the work not done according to the principles of the agile manifesto.

Functional Credit

Functional credit on the other hand is generated, when Excitement Attributes are delivered. Functional credit may help to compensate for functional debt (missing Performance Attributes) or even more help to exceed the customer expectation by raising your functional balance above 0.

Nevertheless, concentrating on generating functional credit - in the meaning of developing something that is not implicitly or explicitly required - poses the risk of producing waste. For example, you cannot guarantee for sure the developed feature is an Excitement Attribute. The customer may even get upset that you do not provide what has was agreed on, but still it could be a risk worth to be taken - depends on the situation.

Theory applied

How will all this theory impact our daily work? Basically, it should help you to make informed decisions and know of the implications of using one concept to your project.

The following diagram depicts a possible situation in a project where the above discussed aspects have been taken into consideration.

The diagram shows:

• a limited horizontal evolutionary prototype with a limited scope that anticipates what has to be developed in the next iteration. This could support marketing operations by showing what the customer could expect soon and prove that it's vaporware.
• a lightweight horizontal throwaway prototype (the bar smaller than in the diagrams above) to support the vision (using a wireframe) that goes beyond the evolutionary horizontal prototype to mitigate functional risks
• maximized amount of work not done
• several proof-of-concept lightweight vertical throwaway prototypes (bars are more narrow) that cover combined the entire technical stack to mitigate technical risks.

Further, the diagram shows several iteration increments with growing perceivable value but also with growing technical debt (which might occur in every project). The next diagram depict how the iteration scope may have looked like (yellow), how it should look in an ideal world (green) and how it should look to reduce the technical debt again (red). The latter effectively depicts to the approach of producing only something of little business value but with a big (estimated) effort.

Of course it's better to avoid technical debt in the first place, but when you have created it you have to deal with it. The Disciplined Agile Delivery framework lists 11 strategies of dealing with technical debt.

Concluding Thoughts

There might be occasions where any kind of prototype has it's value and helps the project. But if you choose a certain type of prototyping approach in your project, keep the implications in mind. Always try to reduce waste and technical debt and maximize the work not done, while minimizing the risks.

Good practices for prototyping should include:

• Reduce functional risk without producing technical debt with a wireframe mockup (horizontal, throwaway prototype)
• Reduce high technical risks with a limited proof-of-concept throwaway prototype (horizontal or vertical). Define a set of questions to be answered by the prototype to limit the production of waste. (i.e. "is the architecture feasible and matches our criteria?", "does the framework to be used matches our needs?", "are the performance criteria achievable?", "does the solution integrate into the environment?" etc.). Such a prototype is always a tradeoff between waste and risk reduction and requires thorough considerations.
• Avoid producing a horizontal, evolutionary prototype. But if you do it, limit it's scope to limit production of technical waste. Anticipate only a small and manageable number of iterations (i.e. 1-3) and define a strategy along with the prototype creation how to work off the technical debt. Make it transparent.
• Do vertical, evolutionary prototyping whenever possible.
• Have a strategy to deal with technical debt.

tl;dr
The world of prototyping is not black and white, it all depends on the situation.