Applying agile in POCs for emerging technologies

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.