Over the last years, I have worked on many prototyping initiatives, with duration ranging from one week to six months. I have used such experiments to reduce risks associated with new and unproven tools or services. I am specializing in data analytics, data engineering and cloud infrastructure (Azure). All those areas are evolving rapidly, and it’s a challenge to stay on top of the latest updates. Hence, prototyping helps me to identify technology weaknesses early in the process.

In October 2017, I spoke at Agile Tour 2017 conference about my prototyping experiences.

Reducing Technology Risks Through Prototyping from Valdas Maksimavičius

Here are my 8 insights from the talk to help you use prototyping more efficiently:

1. Agree on naming

There is nothing more important than a consistent dictionary. Proof of concept, prototype, and pilot mean different things, but often are used interchangeably. However, the main difference is the scope and the underlying costs.

I approach a proof of concept as an isolated exercise, that takes a few days to implement. For example, are newly released database features relevant to our project?

A prototype for me is a system simulation. I like to understand in detail how I can integrate it with our existing tools. For example, can I integrate it with our CI/CD pipeline?

Minimum Viable Product (MVP), or sometimes referred as a pilot, tests the subset of functionality in production with real people.

Here is my another post on differences between proof of concept, prototype, minimum viable product.

2. Determine the proper questions to ask

Developers by nature are eager to explore new tools, try cutting-edge technologies, get hands-on experience. However, to get the most out of prototyping, it is recommended to define questions you want to get answers before your team starts coding.

[…] teams have followed the “Let’s just ship a product and see what happens” plan. Unfortunately, if the plan is to see what happens, a team is guaranteed to succeed - at seeing what happens - but won’t necessarily gain validated learning. - The Lean Startup by Eric Ries

The first step is figuring out the problem that needs to be solved by forming questions and assumptions.

My eight most favorite quotes from The Lean Startup by Eric Ries

3. Define the hierarchy of needs

It rarely happens that new tools or services offer everything you need, without any hidden costs or limitations. If you think that’s the case, verify all once again. Technology selection and experimentation is a constant balancing act: what features are crucial and what are unimportant.

Abraham Maslow created the original hierarchy of needs and argued that “One must satisfy lower level basic needs before progressing on to meet higher level growth needs.” You can define your project’s hierarchy of needs, for example:

Start your technology evaluation experiments from lower levels and proceed up.

4. Identify your knowledge gaps

It is wise to assess your group skills before starting such activities. Learning-by-doing is a viable approach, but if a team has absolutely no relevant experience, your prototyping initiative is doomed.

If you are evaluating a commercial software, reach out to the sales team with your questions. Don’t dwell on it surfing through the whole Google to find the answer. Can’t see required details in the documentation? - The sales team can connect you with a technician. Did your trial end too soon and you didn’t test it properly? - Ask them to extend it. It’s your call to choose the offering or go with the competition, but make sure you use all available channels to gather relevant information.

5. Review the architecture

Your early decisions make the biggest impact on the eventual shape of your system […]. It’s a terrible irony that these very early decisions are also the least informed - Release It! by Michael Nygard

Software Architecture for Developers by Simon Brown is a practical guide to software architecture, specifically aimed, as the title suggests, at developers. Simon proposes to have architecture reviews and let all team members express their opinion about all components. Whiteboarding with color stick papers is a good start to help you identify weak points in your design.

Prototypes don’t have the cleanest structure, but with such architecture retrospectives, you can keep the team members informed about all workarounds and hacks. Have a process to avoid surprises once you ship it to production.

6. Track your efforts

A spike is a task aimed at answering a question or gathering information, rather than at producing a shippable feature. There can be two types of spikes: technical and functional.

The technical spike is used for evaluating the effect new technology has on the current solution. A functional spike is used to determine users interactions with a new implementation, test business assumptions.

Learn more about spikes

7. Document

Probably one of the biggest mistakes I did while prototyping was lack of proper progress documentation. Record not only successful attempts but put even more efforts to describe the failed opportunities. If an experiment failed because of poor functionality, it might change with a newer version. You don’t want to repeat all tests, just focus next time on what failed previously.

I am using Evernote as my getting things done tool. I love Evernote <-> Google integration because now I see my old notes if I search for something similar. It happens that I find an interesting article about a new tool, and eventually decide it’s not relevant now. But in a few months/years, it might be applicable. Evernote helps me to track my previous readings.

8. Stop starting, start finishing

Learning IDE shortcuts is one out of many useless things you can do during prototyping. Instead, focus on answering your questions (look at 2. Determine the proper questions to ask), stick to the agreed scope, get it done as fast as possible. Spending days configuring an environment, learning IDE shortcuts is apparent procrastination.

Another significant aspect is finishing what you started and documenting the results. Just take a look at this brilliant illustration. CommitStrip - Side Project