The 12 Agile Principles Reimagined for Market Research

Derived from the Agile Manifesto, the 12 Agile Principles have served as the foundation of all Agile frameworks over the past twenty years. Here's how research organizations can rethink the 12 Agile Principles as we usher in a new decade of innovation. 

The Origins of Agile

What comes to mind when you imagine software development? Chances are, you are probably picturing a small team of programmers huddled together in a brightly lit room, working seamlessly to push out line after line of code. 

While this may be the image associated with modern-day programming teams, this was not always the case. For a long time, software industry projects were in deadlock. What should have taken weeks, took months, and what should haven take months, took years. Owners and sales teams complained that developers weren’t producing enough, while developers complained that the requirements were constantly being changed.

Free eBook on the state of A.I. in market research! - Download Here

How Companies Operated Before Agile

A large part of why expectations and reality conflicted in development can be attributed to how companies and startups used to operate. Faced with situations of high uncertainty, companies were afraid of getting their product launches wrong, and dedicated the bulk of the project’s time towards researching and planning. 

Why Alternatives to Agile Didn’t Work

Yet, after all this time dedicated towards planning, product launches still tended to fail. The reason was simple - customers were only able to start providing genuine input about the project after they had seen the first release of the product. 

If it takes the entire length of the project to achieve feedback, then a development team only gets their first round of input near the end of the project, leaving them virtually no time to make necessary adjustments.

In view of this, Agile techniques were developed to provide focus and sanity to teams operating in environments of high uncertainty. These techniques helped teams disprove or prove their hypotheses as early as possible so that they could focus on the educated guesses they knew to be true.

Agile Outside of Software

Beyond software development, recent trends indicate that Agile techniques could find applications in other industries. Within the consumer products industry, approximately 95% of the 30,000 new products that are released each year tend to fail. At the same time, consumers still expect and demand product innovation from the brands they purchase from. Being able to apply Agile principles in these fields thus becomes crucial.

Of the 12 guiding Agile principles that are used throughout the innovation cycle, we believe at Remesh that the principles fall under three broad pillars, namely:

1. Continuous and direct communication
2. Embracing uncertainty
3. Constant collaboration

Embracing all three pillars of the Agile principles is crucial for any organization to truly operate in an Agile environment. 

Pillar One
Continuous and Direct Communication

Agile Principle #1:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software products & services.

The start of any project always exists within an environment of high uncertainty. These environments are defined by low amounts of quantitative data. If your client or brand is building or advertising a new and innovative product or service, by definition there is no data, standard, or benchmark that can predict success.

At the start of a new project, a qualitative understanding of the target population’s behaviors, problems, and needs are the only data points available with which to make decisions. This means that good, qualitative research becomes the foundation of successful innovation. Delivering products and services regularly becomes a crucial means of collecting these insights and understanding your customer.

Pillar Two
Embracing Uncertainty

Agile Principle #2:
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

The start of a new project is when you know the least about what the final end product or service should be. So, spend as little time as possible planning for the end product and instead:

• Formulate your hypothesis about the target population
• Attempt to invalidate them through qualitative research
• If these hypotheses are not invalidated, proceed with the project

Through this process, technology provides a valuable opportunity to speed things up.

Online tools such as online focus groups, message boards, and video-enabled 1:1 interviews allow you to reach and interact with audiences quickly. The greater scale enabled by these digital platforms can ensure you don’t miss a minority—but important—viewpoint.

Technology can also help you make sense of responses more quickly—particularly when operating with the kinds of data that come from larger-scale studies. While AI and automation tools are no replacement for a talented researcher, they can assist and augment by creating faster workflows and better organizing information for analysis and presentation.

Agile Principle #3:
Deliver working products & services frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.

Once enough assumptions have been validated, the next step is to launch.

This step flies in the face of traditional research and planning. How can your clients or brand proceed with an idea when so little is known? The simple fact of innovation is that customers cannot tell organizations what to create to meet their needs.

At this point, no matter how much up-front research and planning is done, the first iteration of your product or service is likely going to fail. There are simply too many questions you can’t get answers to.

So, get something out there that you expect to fail and learn from it. 

In Eric Ries’s book The Lean Startup, he introduces the concept of Minimum Viable Product or MVP. This is the absolute smallest, lowest effort product or service that can be provided to customers in order to learn more about what they need. Releasing an MVP quickly allows you to gain early customer insights, and make any necessary pivots as soon as possible.

Agile Principle #4:
Working software (i.e. end products & services) are the primary measure of progress.

Releasing the product or service provides valuable quantitative data that presents itself in the form of questions such as:

• Did the customer purchase it?
• Did the end user make use of it in the way it was intended to be used?

Understanding why a customer purchased your product, or used it the way it was intended to be used, forms the next step in the cycle for qualitative research. A few crucial follow up questions you may want to pursue are:

• What were the barriers to adopting the product or service? 
• Did the population know about it? 
• Did they understand it? 
• Did it solve their problems? 
• Was it priced, delivered, and supported correctly?

For 100+ open-ended market research questions, click here.

The Lean Startup refers to this process – from planning through release, plus gathering new information – as a Build > Measure > Learn cycle. This process is repeated for every iteration until the product or service has met its goal, or it becomes clear that the goal will not be reached.

Agile Principle #5: Simplicity – or the art of maximizing the amount of work not done – is essential.

This principle suggests that products should be released every couple of weeks to every couple of months. While these time scales may seem to only apply to the software industry, flexible manufacturing, rapid prototyping, direct to consumer eCommerce, and advances in shipping and delivery mean that this methodology can be applied to other industries like consumer packaged goods, media, or even finance.

While the two weeks to two months time frame might not be possible for everyone, after taking these advances into consideration, there are very few industries who couldn’t reduce their time to launch significantly and start seeing benefits over the competition.

The key to achieving this is the MVP, or minimum viable product. By releasing quickly and iteratively, you are never that far from course correcting, so missteps are less impactful. The benefits of quick, directionally correct business decisions far outweigh the risks, particularly when the risk of not making a decision in a timely manner means losing your window of opportunity.

Agile Principle #6:
Continuous attention to technical excellence and good design enhances agility.

It is crucial to balance quality with speed.

Unfortunately, much like the term “Agile,” the term “MVP” is often co-opted to mean “a subpar version that we rush out the door in the name of speed, and hope it succeeds.” Rather than being designed as a starting point for customer input, MVPs often turn out to be a half-baked version of what teams think the final product should be.

Remember that the “V” in “MVP” stands for “value.” To truly be innovative, value comes in two forms:

1. Successful products and services which meet the needs of your target population in a way that is viable for the organization
   
   OR 
   
   
2. Iterations that move you closer to the above by providing learning

Testing and iterating on poorly designed work often results in inconclusive findings that don’t add value. To avoid this trap, move away from the MVP to the related concept of the Riskiest Assumption Test or RAT.

Technically, the RAT is not a new type of initial release, but the original concept of the MVP renamed for easier understanding. Both RAT and MVP involve building just enough of a concept to test it, with the key difference being that RAT allows you to first identify your riskiest assumptions and build around them.

Neither the MVP not the RAT are complete prototypes.

Both the MVP and RAT are intended to be experiments that test your assumptions. The key difference, again, is that a RAT spells it out in more detail. The first step of RAT is to identify the riskiest assumptions you are making about your customers’ needs – these are the assumptions that, if untrue, will negate your idea entirely. 

Second, you design your initial release as a means of testing those risky assumptions. This helps to identify and invalidate key misconceptions as quickly as possible and determine whether customers are fundamentally interested in the concept before building anything.

Rushing into poor experimental design at any stage, whether qualitative or quantitative, isn’t going to give you the outcome you need. Rather, you should aim to get as close as you can to the right answer without excessive testing. Here, online tools can also offer added benefits:

1. increased candor as a result of anonymity
2. greater freedom to speak without being drowned out by the loudest voice in the room
3. wider reach and greater scale to capture populations and audience segments you may otherwise have missed

Pillar 3:
Constant collaboration

Agile Principle #7:
Business people and developers (all stakeholders) must work together daily throughout the project.

During the following events, it is crucial to have all relevant stakeholders in the same room:

1. 1. discussing goals of research (business questions)
   2. designing research
   3. running research
   4. making recommendations/business decisions and following up

While it may seem counterintuitive, involving more people during these crucial decision-making events is often faster than working on specialized, but siloed teams. This cuts down on back and forth time involved in making and communicating decisions from group to group, and eliminates miscommunications that result in wasted time working towards the wrong goal.

Virtual rooms enabled by online and mobile technology make this possible with clients, researchers and participants anywhere in the world.

Agile Principle #8:
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

While a collaborative team is central to Agile methodologies, there is still a need to avoid design by committee and trust in the skills and expertise of each member of your team. While the client understands their business domain and constraints better than you, ultimately you are the expert at how best to get the answers they need.

Agile Principle #9:
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

It’s crucial to set a regular cadence of Build > Measure > Learn cycles and limit the amount of input going into each cycle, according to how much the team can commit to. Giving the team the autonomy to communicate and decide how much they can do within a cycle helps teams avoid burnout, and keeps them committed to their goals. 

At the same time, this allows you (as a manager, team lead, etc.) to trust the team’s realistic estimates and ensure the team commits to meeting their delivery dates.

Agile Principle #10:
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

When conducting qualitative research with customers, there’s often no replacement for the kind of depth and nuance you can get from face-to-face conversations.

Yet, in-person interviews and focus groups can be incredibly resource intensive, as compared to alternative methods such as online focus groups. As with any research it’s up to you to weigh the benefits and drawbacks and choose the tools and methods that are right for each particular project and research stage.

Agile Principle #11:
The best architectures, requirements, and designs output emerges from self-organizing teams.

At the heart of any agile project is the self-organizing team. There are a few key reasons to grant project teams more autonomy, namely:

• Teams working on the ground tend to be the most aware of customer needs and implementation challenges
• Teams that  are trusted to perform well at the job they are given are more engaged and higher performing
• It enables faster and more effective communication within the team

Allowing teams to have autonomy and to figure out the methodology that works best for them allows contributors to react quicker to changes on the ground, iterate on the fly, and push the entire organization to achieve business objectives in a more Agile fashion.

Agile Principle #12:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Just as a good Agile team iterates on products and services delivered, so too must it iterate and improve on its own internal processes. At the end of each sprint cycle, hold a retrospective to discuss what worked, what didn’t and what could be done better. There is no fixed process in Agile. As long as the principles are generally adhered to, find a process that works and constantly look to improve it.

The same can be done with your clients or within your organization, too. While it requires a high degree of openness and trust, doing this can allow your clients or org to have a greater sense of control, feel like they have skin in the game, and cement relationships between work and the greater organization.

Wrapping Up Agile Principles

Following the Agile principles can help every team respond more quickly to changes in the market, and build products that truly bring value to customers. Ultimately though, every team should find how these principles can best work for them, and iterate until they find that winning formula.

Can't get enough industry insights? Check out our free eBook on the state of A.I. in market research!