The power of POC in agile projects

pocPOC stands for Proof Of Concept. Even though the title says about agile projects, POC are performed in other environments as well. I feel more confident considering them in the agile area. Certain forms of POC are a must regardless of methodology. It is almost not possible to build complex solution with no research. Some projects have an opportunity to use lessons learned from others. POC are less or more expensive. They are the initial investment to research feasibility before running a project. This post focuses mainly on POCs in software development projects in agile environments.

1. Introduction

Project is considered here as an implementation of a whole product or as a certain part of a product. Scale of time, money and other resources varies from project to project. Every project by definition is different which implies dedicated approach in order to succeed. There are also related terms like prototype, spike. They are often used interchangeable with a POC. There is a difference between them and it is covered here.

POC

“A proof of concept (POC) or a proof of principle is a realization of a certain method or idea to demonstrate its feasibility,[1] or a demonstration in principle, whose purpose is to verify that some concept or theory has the potential of being used. A proof of concept is usually small and may or may not be complete.” [1].

Spike

The word spike is the most connected with agile among all of the mentioned words.

“A story or task aimed at answering a question or gathering information, rather than at producing shippable product.” [2].

“A spike solution is a very simple program to explore potential solutions. Build the spike to only addresses the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away. The goal is reducing the risk of a technical problem or increase the reliability of a user story’s estimate.” [3].

Spike or POC?

Spike is to examine a certain object against defined criteria. POC is something bigger (or not less) than a spike, provides any output and allows to assess project success. A POC may take into account outcome from spikes, analyze them in order to answer feasibility questions. POCs emphasize on research and development activities. The outcome could be an object (product) or a summary in any format. In POCs the outcome should be a proof whereas in spikes it could be only an observation.

Comparing definitions of spike and POC we can conclude that spike can be a certain case of POC. Let’s compare them: POC – “is a realization of a certain method or idea to demonstrate its feasibility” and spike – “a very simple program to explore potential solutions [...] The goal is reducing the risk of a technical problem”. It is not a (big) mistake to use these words interchangeable.

Prototype

“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. It is a term used in a variety of contexts, including semantics, design, electronics, and software programming. A prototype is designed to test and try a new design to enhance precision by system analysts and users.” [4].

Prototype is a way of implementing a POC or a spike. It is a thing, a (partial) product. Spikes and POCs are activities producing outcome which may be in particular a prototype.

2. Scheduling a POC

POC can be small, eligible to complete in a one iteration. Let’s consider the following use case.

Introducing multi-threading API into Java web project

There is an existing Java web project which already deals with multi-threading. The project will be extended into new functionalities requiring multi-threading as well. The existing project uses low-level approach to concurrency (creating threads through new Thread(), synchronization by Object.wait() and Object().notify() and so on). You consider introducing either modern concurrency – java.util.concurrent API or a third party API framework called SuperAwesomeThreads. The new code will use the chosen API for implementation while current solution will be re-implemented with the API.

Goal

Implement/re-implement web project with the new concurrency API

Challenge

Choose appropriate concurrency API; project implementation

Is it a spike or a POC?

The purpose of a spike here is to research APIs in order to recognize their possibilities and project fit. However a goal is to implement the project with a new API. The spike is a first step that selects the right API. The POC takes the API and uses it to build such a solution that will move toward the goal. The solution may have a prototype form. The POC outcome should allow assessing possibility of implementing the project using chosen concurrency API.

A way to achieve the goal

Schedule a POC that will revel an API that will be best suited for the web project. Once you have concurrency API, move to project implementation. Assuming 2-4 weeks iteration duration it is possible to do a research on APIs and choose one of them for the project. Plan the POC with your team on the iteration planning. New iteration task board should then contain a task called e.g. “Spike: research concurrency APIs for Java web project”. Once the spike is finished, the “POC: provide concept project implementation using chosen API” can be created. There are given below some suggestions worth to consider when you are about organizing a spike/POC.

Factors which can be taken into account

  • Developers experience with the APIs
  • Framework support and documentation
  • Characteristic of the project – which API will meet all project’s concurrency requirements
  • Estimating time to learn an API
  • Estimating time to implement solution with a certain API

Exemplary research activities

  • Analyze project’s existing concurrency code
  • Collect project’s concurrency requirements for a new implementation
  • Get familiar with APIs basics
  • Re-write selected parts of existing code with new APIs
  • Compare implementation processes of those two APIs
  • Collect an outcome of the research (report, code, prototype)

Results

After performing the POC you have a clear picture which API will be the best for the target implementation. The POC results are then consumed during actual project development.

3. Investigating POC nature

Let’s do the investigation with simplified SWOT analysis.

Strengths/opportunities

  • Fail fast. Allows avoid failure on project level, POC are on pre-project phase.
  • Assess feasibility of a project.
  • Saving resources: time, money.
  • Risk is taken into account. It is easier to accept negative outcome.
  • It makes fun – “Trust me I am an engineer”. Yes, it may be fun working on new things and using different technologies. There may be an opportunity to experiment.
  • Set good direction of a project.
  • Lessons learned. Research’s outcome can establish heritage for further activities on similar areas.

Weaknesses/threats

  • Requires awareness of a non production-ready solution. First, management and development team has to be aware what is the purpose of conducting a POC. Second, there are cases when customer should be familiar with this as well, particularly when a time to market from a prototype is not short.
  • POC and NFRs. Concurrency, security, performance and extensibility are often corrupted.
  • Prototype never emerges – a threat. As long as a prototype provides working-like solution it is not re-investigated or re-implemented. It is extended into new functionalities when required but the core remains still on a prototype stage.
  • Testing. When tests are missing in a prototype, they should be implemented together with re-coding/refactoring

How agile is it?

Manifesto for Agile Software Development [5]:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

How does POC fit in the manifesto?
What can be found in POCs from the manifesto?

POCs are all about working software. If software is not working then a POC shows that as well.
POC should be light and should allow avoiding overhead of running a whole project without initial feasibility research.

4. Before staring a POC

Here are some questions you can ask when you consider executing a POC

  • Does your team have a feeling of a high uncertainty of a way to implement tasks? If something is not clear it should be addressed. In other words, we should know what we do not know. The mystery thing is then a subject of a spike.
  • How many tasks are spikes/POCs on your task board?
  • Is it possible to implement final, decent solution following elaborated prototype? Prototype does not have to deliver a whole solution. It should not. However it should prove that it is feasible implementing at least one case of all from a certain class problem.

5. Summary

The power is that POCs could be agile. When they are, they really boost creating agile projects. It is easier to introduce POCs in agile environment because POCs reveals agile nature. On the other side agile supports them. Let’s be agile and try it!

References

[1] http://en.wikipedia.org/wiki/Proof_of_concept
[2] http://agiledictionary.com/209/spike/
[3] http://www.extremeprogramming.org/rules/spike.html
[4] https://en.wikipedia.org/wiki/Prototype
[5] http://agilemanifesto.org/

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>