There’s plenty of new and exciting technology for developers, engineers, and data scientists to kick the tires on, learn how to apply, and evaluate for potential business applications. To learn about it, technology and data teams often conduct POCs (proof of concepts) to validate use cases, performance, integration capabilities, and other requirements. IT and data teams conduct POCs on new JavaScript libraries, devops tools, public cloud capabilities, low-code platforms, database technologies, machine learning models, and data integrations.
Applying agile methodologies such as scrum to execute a proof of concept has many benefits. The agile team defines its objectives at the start of a sprint and then uses what they learn to prioritize new experiments and validations in upcoming sprints.
Using POCs to conduct rapid reviews of new technologies is relatively straightforward when the agile team or other technologists are the subject matter experts and can determine success criteria. Agile teams can then define spikes, a special card on the backlog indicating research-oriented work, to schedule the POC-related work in the sprint. The spike’s acceptance criteria help define success, and the team can decide when the technology is ready to go through change approvals. Even once approved, these teams can use feature flags to introduce the new technology into production slowly.
Apply agile methodologies in complex POCs
Planning and executing larger-scope POCs has additional challenges, especially when validating emerging technology in machine learning, artificial intelligence, the Internet of Things, or blockchain. These POCs are experiments in the underlying capabilities, selected platforms, applications of the technology, and the applied business requirements. Teams must iterate through a discovery process along all these dimensions and their dependencies to validate the business value, solution, and technological approach.
When comparing an agile POC on emerging technologies to other agile initiatives, there are several stark differences.
- Most agile initiatives are led by a product owner who works with customers and stakeholders on vision, priorities, and requirements. But in an emerging technology POC, the product owner must lure potential stakeholders into a discovery process without overpromising results. The agile process must help determine whether applying the tech to the problem results in a workable solution that creates sufficient business value. At the same time, stakeholders must agree to participate in the experiment’s journey through success, speed bumps, and failures.
- When working with emerging technology, stakeholders can’t easily provide requirements or acceptance criteria, and agile teams can’t estimate the work accurately. Working with emerging technology is a discovery process. Agile teams validate the technology’s capabilities and demo the results at sprint reviews to inform stakeholders. The agile team and stakeholders can then evaluate whether and how to proceed and determine which experiments to prioritize.
- Technology and data teams often conduct POCs on one or more comparable technologies in order to validate them against a set of success criteria. That’s harder to orchestrate in emerging tech POCs because teams are iterating on the success criteria, requirements, and technical capabilities concurrently. In addition, emerging technologies and architectures may yield solutions that are hard to validate against support requirements and future business needs.
Empower self-organizing teams in emerging tech POCs
POCs have their challenges, but successful agile teams know how to use self-organizing principles, adjust their agile management tools, and create a culture that fosters experimental innovation.
First review the sprint and release cycles for long-running POCs that require dedicated teams. Many agile teams working on application development, devops, and data science objectives settle on two-week sprints. It’s sufficient time to get user stories done, participate in agile ceremonies, and plan the upcoming sprints.
In longer-running POCs, agile teams may want to plan a more aggressive cadence of weekly or even shorter sprints. Shorter sprints work well when teams commit to quick experiments and stakeholders review and provide frequent feedback. These POCs often have fewer execution complexities, and the rapid feedback loops enable quicker course corrections and decision making.
When it comes to experiments, teams may benefit by defining the requirements differently than the format and success criteria applied in typical user stories. In agile user story writing, a story’s acceptance criteria bounds solutions to functional constraints, and non-functional criteria helps the team validate their implementations. Writing short but detailed user stories with acceptance criteria aids in creating a shared understanding between the product owner and agile team on the user, problem statement, and acceptable solutions.
Defining pass-fail acceptance criteria in complex POCs may be difficult. In these experiments, an alternative is to define unsuccessful criteria that help indicate when the wrong experiment was selected or when an experiment’s results are outside of targeted outcomes. When an experiment is deemed unsuccessful, teams can make better decisions on when to end it and prioritize different approaches.
For highly strategic POCs, technical and data organizations may elect to have multiple teams compete on technology selections and implementations. One option is to define short hackathons where multiple teams apply different technologies, approaches, and solutions. Hackathons should include the more junior developers, engineers, and data scientists; it’s an excellent opportunity for them to learn new technologies and agile collaborations.
Transitioning from POC to prototype and MVP
One benefit of leveraging agile on the POC is that it enables a smooth transition to new phases, such as developing prototypes and MVPs (minimal viable products). During the POC, agile teams collaborate and gain experience applying the new technology; stakeholders increase their understanding of the technology’s capabilities. More importantly, stakeholders witness the agile team’s velocity and gain a realistic expectation of what the team can complete during a sprint. The collaboration and empathy developed during the POC can yield promising results during subsequent phases, including developing prototypes and MVPs.
It’s important to remember that innovation does not end with successful POCs. They are just one step in the journey. Ultimately, organizations want to bring emerging technology innovations to production and realize the business impacts. Starting POCs using agile methodologies establishes a collaboration between business, technology, data, and other functions that must evolve their strategies, priorities, problem statements, and solutions during the process.
