enthiosys agile product management - agile product management, motivated from within

Tips on Selling Qualitative Market Research to Agile Software Developers

 

This article was written for QRCA, the Qualitative Research Consultants Association.

Agile Software Development is the hottest topic in the software development community. It is a new way of developing software that is producing higher quality software in record time. In this article I’ll provide a brief overview of Agile Software Development, explain why developers who embrace Agile practices are naturally pre-disposed to the benefits of qualitative research, and offer some tips on how you can better sell qualitative market research services to Agile software teams.

What is Agile Software Development?

Agile Software Development refers to software that is developed under any number of methods that strive to honor the principles and practices of the Agile Manifesto for Software Development (www.agilemanifesto.org). The manifesto states:

     We are uncovering better ways of developing
     software by doing it and helping others do it.
     Through this work we have come to value:

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

     That is, while there is value in the items on
     the right, we value the items on the left more.

The authors of the manifesto, many of whom I’m fortunate to count as friends and professional colleagues, encourage everyone to reprint and otherwise share the manifesto, provided you do so in its entirety. The manifesto is also supported by twelve principles, which I encourage you to review at the web site listed above.

As you review the manifesto, I suspect you’ll find that as a qualitative market researcher you naturally find yourself agreeing to the core values of the manifesto. We have all experienced planning for a market research event, only to find out that we need to adjust our event in real-time because of participant needs. Similarly many of us often prefer the simple tools of 5×8 cards and markers for recording observations instead of a complex and costly video infrastructure. Finally, our contracts and engagements are most enjoyable when we’re given the opportunity to collaborate with our clients over a research project structure that gives us the flexibility needed to produce the most important outcomes.

Agile development practices are growing fast. I recently returned from the 2008 Agile Development in Toronto. Attendance grew by another 30% from 2007, with more than 1600 professionals representing 22 countries in attendance. Several sessions focused on the hard data that has been gathered on Agile product teams, including data from BMC Software that indicates their 1000+ world-wide development team has recorded some of the highest productivity levels ever measured in our industry. BMC credits their commitment to Agile Development as the key to their success.

But Faster Isn’t Always Better

While I’m a fan of the speed in which Agile teams can develop software, I’m also concerned about some troublesome developments in our industry. Some teams, in their desire to move quickly, have started to de-emphasize market research. At times this is an error of commission, as they incorrectly assume that market research projects will take too long or cost too much. At times this is an error of omission, as they get wrapped up in fast development cycles and start to use customer reactions to working software as a pseudo-replacement for up-front research. Unfortunately, the net effect is an increase in the time to solve a customer problem, even through there is a decrease in the time to the next release.

Since I’m a fan of both qualitative market research and agile software development, I believe that the best results are obtained when qualitative market research techniques are integrated into agile practices. To do this, of course, you need to sell your services to Agile software teams. Here are five tips to help you get this done.

# Become an Agile Market Researcher

1. Express your results in ways Agilists like to work
2. Sell before release planning
3. Sell into the product lifecycle
4. Sell continuous research

Tip #1: Become an Agile Market Researcher

Agilists prefer to work in short cycle times with “barely sufficient” up front planning. The term barely sufficient, in turn, is a philosophy that agilists use to guide their work practices. Instead of creating a long document that captures everything said in a meeting with properly formatted action items, an agilist will be just as happy as snapping a photo of the meeting whiteboard, posting the photo into the project wiki, and transcribing the bare minimum of action items for search purposes. Other common phrases used in Agile teams that convey the same value include “YAGNI” – “You Ain’t Gonna Need It”, and “Simple Design”. Both of these phases are intended to prevent Agile teams from spending too much time on details that simply don’t matter, an all too common problem in software development.

Of course, Agile software development isn’t anarchy. We plan an agile project at a level suitable to the needs of the project complexity, number of developers, and so forth. There is a direct analogy to market research. At Enthiosys, we take a very different approach to planning an Innovation Games® project based on the number of participants, location, complexity of the games, and goals of the client. We recently completed a 500-person Innovation Games® project that took more than four months to plan and more than 25 facilitators to execute. We can contrast that to another Innovation Games® event for 18 people that took one facilitator 3 weeks to plan.

The key point is that you’ll need to examine your preference for formalism and ceremony before working with an Agile team. In general, formalism and ceremony is low. Attention to technical excellence is highly valued—so, highly, in fact, that it is one of the principles of the manifesto! Never cut corners with an Agilist, but don’t waste your time agonizing over the perfect font for your final report.

The cycle time speed of an Agile team deserves special mention. Do not underestimate the speed at which an Agile team can produce results. BMC makes very expensive, complex software that is used to monitor the computers in large data centers. Using Agile practices they reduced their cycle time from roughly one release per year to one release per quarter. VeriSign Managed Security Services, a client of Enthiosys, similarly reduced their release cycle time to three months – and faster if needed. Many Agile teams can release their software monthly.

The take-home point here is that if you start the conversation telling an Agile time that you’ll need 4 months to plan, execute, and post-process the results of your proposed project, their eyes will glaze over and they’ll gently escort you from the room. Instead of selling the biggest project you can, focus on understanding their goals and problems and then selling the smallest project you can think of that will help them with the same. As you’ll see later, you’ll build the foundation for continuous collaboration.

Tip #2: Express Your Results in an Agile Manner

Traditional software requirements have been rightfully characterized as painful to create, painful to read, and painful to use. A key principle of the manifesto states that the highest priority of the development team is to satisfy their intended customer through early and continuous delivery of valuable software.

This principle is expressed in Agile teams through two fundamental things. The first is the backlog, which is the prioritized list of work that the team needs to accomplish in the next release. The second is how individual backlog items are expressed. While the only criteria for expressing backlog items is that the development must be able to understand the backlog item well enough to build it in one of their iteration cycles (typically two to four weeks), many Agile teams have adopted user stories as a means of expressing the work that needs to be done.

A user story is a software requirement written in the following form:

     As a [kind of user], I want to [do some thing].

At Enthiosys, we’re hard at work putting some of our Innovation Games® online, starting with our Buy a Feature game. We’ve generated dozens of user stories, and we have many more on our backlog. Here are a few examples of our user stories.

     As a planner, I can specify who will facilitate the game.
     As a facilitator, I can start the game whenever I want.
     As a facilitator, I can stop the game whenever I want.
     As a facilitator, I can remove a player from the game, so that I can prevent unruly players from disrupting the experience of other players.

As you can guess, the user of a user story often equates to a persona that has been identified in market research terms. In this case, note that the last user story has been extended to include additional information to the development team to help them understand the motivations for the story.

Well-written user stories promote collaboration between the developers and the product managers regarding what constitutes a successful completion of the user story. Again, using the last user story as an example, my development team asked the product manager in charge of our development efforts questions like:

     If a player is removed, can they be invited to play again if they promise to behave? [No]
     If a player is removed, can the facilitator replace them with a different player? [No]
     If a player is removed, should they money that they’ve been given be allocated to another player? [possibly yes – the facilitator will decide]

Qualitative research helps develop better user stories because you’ll have deeper, more concrete knowledge about what motivates the users / customers of the system. You can express these as market segments. You will find that expressing your results and conclusions directly as user stories enables the development team to more readily leverage your insights. These insights will also help Agile teams in prioritizing the backlog.

Tip #3: Sell Before Release Planning

Selling qualitative market research to Agile teams means you need to do more than just work as an agilist and express your results in a form that they can absorb. You also need to understand the timing and cycles of an Agile development project so that you can present your services at the right time in order to have them purchased.

Consider that Agile teams must balance two usually opposing forces: they want to release software frequently and they organize their work in a backlog. Most backlogs are infinite – good software is never really done. To manage these forces Agile teams engage a special process called release planning where they take their backlog and plan the sequence of iterations required to deliver all of the backlog items. One key point in the timing of the sale of your services is that, in general, an Agile team will be more likely to purchase market research before release planning to help ensure that they’re prioritizing the most important items early in the release. If you don’t know where the team is at in their development cycle, they may think your services are great, but still not purchase them because they’re hard at work on the release.

The careful reader will note that the Agile Manifesto explicitly called out the willingness of an Agile team to embrace changing requirements, and that market research can provide them with new information that justifies a change in the existing plan. While this is true, my experience is that most qualitative research uncovers “big” features that need to be created in order for the product to be successful. These big features are called epics in the Agile community, because they require multiple iterations to complete. The process of release planning is often the conversion of a large epic into many user stories. Once this is done, adjusting the user stories in the release plan is pretty easy. Adding a new epic is very hard, because the size of the work is just too big. You’ll be better off making certain you understand where the team is on their release cycle and selling your services accordingly.

Tip #4: Sell Into The Product Lifecycle

A product goes through several phases throughout its life. There is the ‘New Product Development’ phase, which occurs before release. Then the product is released and the product follows a familiar s-shaped curve of adoption (see sketch, below). There are a lot of different names for the different phases, which I’ve intentionally simplified into just three. The point is that your client will have different kinds of market research questions at different phases of the product lifecycle.

In the beginning, before the product is released, you really want to help them understand the problems that are most valuable to solve, and possible help them size the market for these problems. In the early stage, you’ll want to focus your research on the impediments to purchasing and using the product. In later stages, you’ll want to focus on how to stay abreast of inevitable competitive threats, and in the final stages you’ll want to help them prepare for the ‘next big thing’ so that the process starts all over again. Since releases happen frequently throughout the lifecycle, you should understand where they are in the lifecycle so that you can better position your services before a release planning session.

Tip #5: Sell Continuous Research

My last tip has to do how Agile teams work and exactly when they collaborate with customers. Many Agile teams collaborate with customers in the planning of the project through requirements gathering – which is just a technical term for market research – and sometimes after release planning, where they confirm the release plan with customers. Some advanced agile teams take this even further and incorporate customers into the review meeting that happens at the end of every iteration.

The problem with this model is that teams often revert to simply telling their customers about what they’ve accomplished in the iteration and confirming the plans for the next iteration. While this is quite powerful, it misses the opportunity to conduct a mini-research project with the customers about how they are evolving to better leverage the resultant software.

Consider, for example, how many companies treat qualitative market research. Great companies conduct several projects a year. Most of the time, however, market research is done much more infrequently. I find this frustrating, especially when a client cites market research that is months and/or years old. Given the complex and changing world we inhabit, our clients should be talking with their customers much more frequently.

Amazingly, that is what you get in a high-performing Agile team: the opportunity for continuous collaboration that when structured the right way provides insights into the market. Not just confirmation that the product development effort is on track, but a whole wealth of information.

At Enthiosys, we have a special term for customers who participate this closely with their development organization. We call them co-development partners, because they are so intimately involved in the success of your product. Over time, the development organization can move from episodic research to continuous research.

Summary

Although I’ve focused on tips for selling qualitative research, it is important to remember that the first step of selling is listening. Listen for the goals and problems of your client. Armed with this understanding, show them that you can:

1. Work in an agile manner.
2. Express your results in a form that they can immediately use
3. Help them produce better release plans
4. Help them move their product through the lifecycle
5. Help them create a continuous collaboration model with their customers

Good luck, and thank you in advance for helping Agile development teams better understand their customers and in the process build better software.

Return to insights-tools