What is Agile Product Development?

Summary: Agile product development is about putting users at the center of the product development process as the 12 principles of the Agile Manifesto suggest. Some companies are missing this point in an effort to lower cost and time-to-market.

12 minutes to read. By author Michaela Mora on February 6, 2020
Topics: Business Strategy, Customer Experience, New Product Development, UX Research

What is Agile Product Development?

Almost 20 years after the Agile Manifesto was signed, many companies think of agile product development mainly as a fast and cheap process.

Since 2001, when the Agile Manifesto a group of software developers wrote it, the term was picked to represent a philosophical framework based on 12 principles to drive product development.

Finding a single word to summarize a complex process is a challenging task. Language evolves and the intended meaning can be lost. “Agile” seems to be suffering that fate in the product development realm.

In a recent presentation at the 2020 QRCA conference, David Tuffy, former VP of Product at Remesh.ai, made it clear that the Agile Manifesto was never about being faster and cheaper.

According to Tuffy, “Being agile is not about being faster than the innovation center. It’s about disproving or proving your hypotheses as early as possible, so you can focus on the things that you know are true. It’s about understanding what does and doesn’t work as early as possible so you can focus on that next thing at work.

In an attempt to operationalize the 12 principles, several of the initial co-signers of the manifesto developed, what Tuffy calls, “agile artifacts.” These are different flavors of project management approaches, such as Scrum, SAFe, Kanban, Six Sigma, etc.

Unfortunately, it seems that despite the certifications available, “agile” is getting a bad aura. Its essence is being diluted by shorter deadlines and small budgets.

To explain his point, Tuffy grouped the 12 principles in 3 broad categories that are the core of the agile product development process. Without them, “agile” is just an empty label.

To be truly agile in product development, you need to:

  • Get feedback from end-users
  • Embrace uncertainty
  • Collaborate across teams

Tuffy goes further to explain how each of the principles should be applied in order to keep the spirit of agile alive in product development. This applies to both digital and physical products.

Get End User Feedback

Agile Manifesto Principles:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

This is probably the most important and revolutionary principle in the manifesto. It permeates the remaining 11 principles.

Talking to users seems like an obvious idea, but it is, in fact, a novel one for many companies. This is what they often skip because of hubris, short deadlines, small budgets, or all the above.

When no prior research exists, as it is the case for many new products, qualitative research, in particular, can be instrumental. It can help understand motivation and barriers to product use.

Unfortunately, even those companies willing to do user research try to cut corners, doing it on the cheap without realizing all the biases they may be introducing by not letting experienced researchers handling the talking and analysis.

They also miss the point of the need for iteration in gathering user feedback. Most do one round of interviews, focus groups, product testing, or usability testing, and think they are done.

Even, after a product launch, we need to keep talking to users in order to produce products with a competitive advantage.

Embrace Uncertainty

Agile Manifesto Principles:

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

For Tuffy, “Agile actually harnesses the fact that we’re learning new things and we’re having to change all the time along the way, and this becomes a competitive edge.”

He recommends, spending less time planning the end product, and more on formulating hypotheses about the target population and invalidating those hypotheses as decisions are made on how to proceed.

Although Tuffy, emphasizes the role of qualitative research throughout this process, in my opinion, quantitative research should also be part of it for strategic go/no-go decisions.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.

The call for an “agile” new product development process came in reaction to the long, sequential, relay-based, “waterfall” model for new product development.

In this model, the product team would not see any reaction to the product until it was already fully launched after many months of planning. At that point, the product may or may not have been what the intended audience needed or wanted.

To avoid finding out at the end that the company has a dud in its hands, this principle emphasizes the need for launching products that are not fully developed at shorter intervals.

The goal is to put the product in the hands of the user and gather feedback as soon as possible as the product development process continues.

In my opinion, many companies trying to be “agile” often miss the spirit of this principle. They think it is about launching faster and saving money. In fact, it is about investing time and money in continuous user research for incremental improvements.

There are also some companies aware of this goal but can’t manage to put a process in place for continuous user research. Their user feedback is sporadic, haphazard, and often very biased by the love and well-wishes of friends and family offering feedback.

Companies need to establish a cadence of user feedback and controlled experiments in the product development process, so they can test hypotheses about the risks early released minimum viable products (MVPs) pose.

4. Working software is the primary measure of progress.

Since a working product, albeit not perfectly, is the result of short development intervals, this metric becomes the motor behind the idea of the “lean” startup, which is another way of talking about “agile.”

This principle is driven by the idea that users often can’t tell you what they want but can react to what we put in front of them.

Consequently, the truly “agile” or “lean” process after the initial round of research is a cycle of Build-Measure-Learn in an iterative format.

As Tuffy put is, “Learning from your first step of qualitative research will inform what the next iteration is going to be like. And you repeat this until a product or service has met its goal or it becomes clear that it’s not going to fail again.”

5. Simplicity–the art of maximizing the amount of work not done–is essential.

This is again about quickly releasing products. Many companies are engaging in these today both in the digital and physical world.

Examples of this, according to Tuffy, are “flexible manufacturing, rapid prototyping, direct to consumer e-commerce, advances in shipping and delivery that physical products can be produced and monitored and distributed for sale and targeted areas.”

Two-week design sprints have become popular, but companies are trying to pile more and more in those cycles. Tuffy turns this idea on its head declaring that “… agile is not about speed, it’s not about doing more in less time, it’s about doing less and getting it out the door more quickly or as I like to say to my team, rather than doing more work more quickly with agile, we do less, more often.” The key term here is to deliver a Minimum Viable Product (MVP).

We need to connect the rapid product release with a system to capture data both qualitative and quantitative. This will allow us to monitor how the products are used to improve them in the next iteration.

If a company engages in two-week design sprints that don’t include testing a working product with users, it is not “agile” despite the speed.

Tuffy warns against the risk of siloing teams by making them work in very short cycles. They may be more productive by longer delivery times, or the minimum amount of time they need to deliver something to the end-user. The speed is about doing the minimum needed, not more in less time.

6. Continuous attention to technical excellence and good design enhances agility.

This principle is about balancing speed and quality.

MVP is often akin to quickly launching the first, often crappy, version of a product, hoping it will succeed. According to Tuffy, “It [MVP] should be designated a starting point for getting customer input.

Tuffy considers the “V” in MPV as a mark for delivering innovation value in two forms:

  • Being a viable option for the company
  • Providing learnings through a product iteration that moves the company towards the final product. It is an experiment, not your final product. To clarify the goal of an MVP, Tuffy prefers to use the term RAT or the Riskiest Assessment Test, instead of MVP. In other words, “Your first version of the product is really that experiment to decide if you should proceed to version two.”

Unfortunately, in the name of speed, companies tend to rush the research. Tuffy recommends reducing the number of things that we build and test each time rather than the size and duration of the research. Again, don’t try to do more in less time, because quality will suffer.

Collaborate Across Teams

Agile Manifesto Principles:

7. Business people and developers must work together daily throughout the project.

This principle calls for collaboration among all stakeholders, researchers included, in the product development process.

When it comes to research, it is crucial that all stakeholders are part in the discussion about the research goals, design, and implementation, and the decisions that follow. Stakeholders should also participate in the research, at least as observers.

If nothing else, research can help create empathy for the users among stakeholders (e.g. executives, product managers, engineers, etc.) who don’t have direct contact with users on a regular basis.

Watching a customer using your product or evaluating it can shift perspectives and generate solutions the team hasn’t thought of.

According to Tuffy, collaboration “cuts back on the back and forth time involved in making a decision,” even if involving more people sounds like it may slow down the process.

When everybody in the room is sharing objectives, agreeing on the direction of the research, watching the research unfold, it gets easier and faster to make decisions on what to do next.

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

Although team collaboration is central in agile product development, Tuffy points out that we need to recognize that teams include people with different areas of expertise. We need to recruit people in the team with complementary sets of skills and experiences and trust they can do the job.

These days, many companies look for UX unicorns (developer, designer, researcher) driven by cost savings, which undermines the spirit of collaboration and the opportunity to learn from others. A team of one is no team.

Designers, engineers, product managers should focus on what they are good at. They need to participate in the discussion about research goals and design. They should also participate as observers in the research. However, researchers should hold the standards and guide that process. It is their expertise.

By the same token, researchers need to understand the principles of design, business goals and technical requirements to make their recommendations relevant.

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

This principle is about finding a sustainable cadence for the Build-Measure-Learn cycle without burning the team by limiting the amount of work that goes into each cycle.

Again, as Tuffy recommends, don’t try to do too much at one time, but work with a reduced scope at regular intervals.

Companies often fail at this principle trying to save money and speed innovation. The sustainability of this process also goes against the current practice of looking to hire 3-in-1 (designer, developer, and researcher or 2-in-1 unicorns (designer and researchers).

Assigning too many roles to a team member leads to burnout and biased research. There are not enough hours in the day for a person to do design, develop and research well enough in a sustainable manner. It’s also psychologically taxing to be the creator and judge of your own creations.

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

Despite all technology available to facilitate communication among team members, nothing beats having face-to-face conversations. This applies not only to the team members but also to getting feedback from end-users.  Consequently, qualitative research is an invaluable tool to advocate on users’ behalf.

The chance of insights getting lost in translation is minimized when the team can observe and talk directly to users, and when the team can discuss them in person among themselves.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

This principle calls for a nimble decision-making process in which teams are trusted and empowered to make decisions without having to depend on approval from top management.

Even when companies use research vendors in the product development process, they need to treat external researchers as part of the team and trust their recommendations and decisions.

As Tuffy explains it, “Clients insisting on a top-down structure that requires executive review and approval at each stage in this process aren’t going to be able to unlock the benefits of agile.”

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

Given the continuous cycle iterations, it is important for teams to also establish a cadence of stopping points for reflection. This allows the team to learn from mistakes, understand what works and improve the process.

The “agile” approach doesn’t apply only to the development of products and services. It is about the process of being “agile” in itself. This is not a fixed process. Each iteration holds the potential for learnings and improvements.

In Conclusion

The “agile” product development process is mainly about integrating the end-user feedback through a process of teamwork and sustainable iteration.

It is NOT about speeding up the product development process but getting quicker to the point when we can get feedback from users. Doing user research early and continuously can accelerate the process if done right, but it is not a given. New learnings from testing may actually extend the process if course-correction is needed.

“Agile” is not about doing it cheaper either. Having an iterative process of Build-Measure-Learn is not cheap but can save a lot of money long-term. It can prevent a company from investing time and money in products that users don’t need.

At the same time, this process has a higher likelihood of generating growth through products and services that meet user needs.