When we consider integrating User Experience (UX) and Agile Methodologies, our framing conditions us to think that once we identify the intersection point, we’ll have all the answers we need.

This would be correct and sufficient, if we had not had disagreements before the advent of agile methodologies. It would apply if we had been working smoothly until the Agile Manifesto was published in 2001; however, the reality is more complex.

https://www.slideshare.net/sbustelo/las-metodologias-agiles-como-problema-de-diseno
Presentación: Las metodologías ágiles como problema de diseño – Santiago Bustelo

Agile methodologies are often proposed or imposed by engineering, and here we see that the “agile methodologies” universe consists of two dimensions: Engineering and Management. The relationship between Design and Engineering has been problematic not just since 2001, but for ages: architects and engineers have been criticizing each other for centuries.

The first step towards healthy collaboration is resolving the relationship between Design and Engineering. For that, I really like this definition that I knew from Bret Victor: “Technology satisfies human needs by amplifying human capabilities”.

This definition is revealing in several ways. First: Without people, there is no technology. Second, it clarifies that Engineering focuses on functional aspects that address the problem… while Design ensures that the solution fits the user by understanding their needs and capabilities. Technology is not limited to the mechanical; it’s not something engineers invent and designers merely color. Without Design, there is no technology—only technical curiosities.

To incorporate Design into the process, I find three critical questions useful: What problem are we solving? For whom(s)? And how will we know we’ve succeeded? These questions allow us to integrate the three areas of the problem in a single conversation: Engineering, Design, and Management

When discussing Management, it’s essential to understand what a Methodology is: a framework for organizing a process that involves people. The key takeaway from this definition is that it reveals what a Methodology does not encompass.

A methodology does not replace people (involved in the process), conversations (tool to share vision of the future and coordinate actions), nor to decision making. Choosing a methodology is, in itself, a decision.

A methodology cannot prescribe decisions, just as traffic rules (e.g., “drive on the right”) cannot dictate where to go; they can only provide the organization needed to reach the destination while minimizing the risk of accidents.

Decision-making is a fundamental part of Design and the most significant value it brings to the process. It’s common for those who hire us to view Design solely in terms of execution, making “pretty” the design decisions previously made by Engineering and Business (often without understanding what a design decision entails).

As designers, we must make the right distinctions, proposing and delivering on the promise of helping Engineering and Business make better decisions, to the point where design decisions inform the business decisions they should be based on.

When Design is viewed merely as execution, a project may seem more or less complex based on the “number of screens” to be produced—or any other quantifiable deliverable.

At Kambrica, we’ve found that the complexity of Design can be more appropriately understood as a product of the complexity of the execution due to the complexity of the decisions. This model allows us to clearly demonstrate the necessary role of UX in facilitating stakeholders’ decision-making processes and providing information to make them evidence-based.

Another important distinction is the common misuse of the term Agile. Particularly in Business, there is interest in adopting agile methodologies due to the idea of speed.

The reality is that speed is not part of the agile manifesto’s principles: what they propose is responsiveness to change rather than clinging to a plan. In other words, agile is the skier who dodges obstacles and reaches the finish line; rushed is the one who ends up in the hospital.

The rushed skier throws themselves toward the goal in an act of faith, driven by anxiety. The agile skier considers the terrain’s evidence in a constant decision-making process: a cycle of observation, orientation, decision, and action.

In a project, UX research provides the evidence-based information necessary for decision making. However, it’s often dismissed with the excuse that “it’s slow,” which is another way of saying, “there’s no time.” But time isn’t something that can be stored in a drawer.

Time is something to be allocated. What does “no time” really mean? Suppose someone goes to a ski resort, asks for skis, and when the attendant asks their size, the customer says, “I don’t have time to put on boots; I just want the skis.” What he means is that he does not understand boots as a necessary condition for using skis.

UX professionals need to learn to hear “no time” not as an inflexible rejection, but as an invitation to point out the necessary condition between our proposal and what our client needs.

In our client’s decision making process, there is a balance with two trays: one with what they don’t want, present or future problems, their fears; and the other with what they want, the future they want to be part of, their desire.

Addressing concerns is critical to getting attention: anything we propose before satisfying that point will be ignored or misunderstood, to the point that instead of being seen as part of the solution, it may be viewed as additional problems weighing down the fear tray.

This approach helps address the common request for quantitative techniques, even when we find they contribute little or nothing to understanding and solving the problem. The reason for this request is that the clients who make it, need something to present to their superiors: they are being measured. These interlocutors’ main concern is not aligned with design quality; it’s focused on their survival within the organization.

In these cases, quantitative research should be presented as a necessary condition for achieving a quantification that our clients will find positive. This means recognizing metrics that can show increasing measures throughout the project. I distinguish three levels in quantitative research:

  • Validation (checking what “we know we know”) is the simplest qualitative process, the least risky, and the one most feasible to establish quantitative metrics for.
  • Investigation (searching for what “we know we don’t know”) involves greater uncertainty and is only viable once our client has understood the value of UX in reducing risks, typically after validating assumptions that were initially presented as truths.
  • Exploration (searching for what we don’t know we don’t know) is the qualitative process furthest from the client’s concern for their organizational survival; it’s only viable when our client has resources, political capital, experience, and commitment.

Only with solid tools for conversations and decision-making can we focus on designing a methodology.

The most important goal of any methodology is to achieve a healthy client-provider relationship on the project scale. Without any methodology, as more people join from both sides, cross-conversations, confusion, and problems arise, leading to the formation of two camps: “those jerks” and “that bunch of useless people”.

That’s why every methodology proposes a single interlocutor on each side, with authority, technical competence, business understanding and management skills.

A critical foundation for agile methodologies is the Lean philosophy’s Value vs. Waste distinction. Value is what the Client values; waste is everything else… even things we consider necessary conditions for achieving Value.

Identifying waste forces us to question all the activities we undertake. In the case of building a house, the walls –providing protection from the elements and preserving privacy– are clearly a Value. However, scaffolding, though considered necessary for building those walls, are actually construction waste: the inhabitants won’t live with the scaffolding once the building is inaugurated. If the scaffolding were made of gold, the budget would increase by several million dollars, without the end clients finding any Value in it. That’s why scaffolding are modular, reusable, and in many cases, rented.

Other types of waste can be more straightforward to identify. If materials are unloaded 10 blocks away from where they are needed instead of at the right spot, additional time and effort will be required to move them where they should have been unloaded initially.

Identifying waste in software is much more difficult. Lean Software Development is a valuable tool for identifying, reducing, and eliminating waste in our projects:

Product Waste:
These are the most obvious… but also the latest to be identified. They become evident once the project is in production… and therefore, when there are no longer resources to resolve them. UX research aims to identify these wastes economically, in a controlled environment, when there is still time and resources to mitigate them:

  • Defects: bugs, things that don’t work according to the end user’s expectations, usability issues.
  • Unused Functionality: typically, the result of a lack of understanding of users’ real needs and capabilities.

Process Waste:
These can be identified and addressed during the process itself. Addressing them reduces the likelihood of product waste manifestation. They require management skills, team responsibility, and Client expectation management:

  • Hand-offs: When a task is passed from one person to another, there is either a necessary conversation between those people, or information is lost in the process.
  • Multitasking: Humans can consciously perform only one task at a time; “multitasking” is actually interleaving fragments of two or more tasks. Switching from task A to task B requires an effort greater than zero to understand the context of the second task; this penalty applies again when returning to task A.
  • Relearning: Returning to a task or practice after a long time requires effort to regain context and operational capability, which can be avoided by maintaining continuity.
  • Waiting: This occurs when someone cannot proceed with their assigned tasks due to a lack of decisions or inputs they depend on. One way to avoid these situations is by managing a “sprint” schedule that imposes cadence on the project and must involve the Client.
  • Incomplete work: All unfinished decisions and executions increase technical debt to the point where the cost of settling it in the future may become unfeasible. It is often the result of project haste and pressure, lack of planning, and vision.
  • Unused talent: One common scenario is when the Client considers Design to be mere execution, overlooking the team’s ability to help the Business make better decisions. It requires management, authority, expectation management, and commitments. This impacts the project in ways that cannot be quantified (no one can measure against what “could have been”) and affects the team in terms of motivation breaks.

At Kambrica, we developed, iterated, and proposed a model that first recognizes the value of Facilitation and Research processes in reducing the complexity of decision making. It reveals that design execution, far from “solving” (as is often the client’s perception), actually always opens up new questions that require appropriate processes for their resolution.

Our minimum sprint model considers weekly cycles, with a Management track running one week ahead of the execution track. During the Planning phase, the two tracks overlap, also including a mid-week follow-up instance with the Business to reduce risks and deviations.

By applying this model, we successfully coordinate all projects, regardless of their complexity.

In summary, integrating User Experience and agile methodologies requires working across several dimensions, from general to specific: from the understanding of Design, Engineering, and Management, to the design and application of a particular methodology to guide projects by identifying and reducing waste, and establishing and fulfilling commitments responsibly.

The Measure of Design 2018: Slow Methods in agile times – IxDA Viña del Mar

The event featured Mauricio Azócar (Agile Coach at Tinet), Estefanía Cotrini (Project Manager at Ilógica), and Santiago Bustelo (Founder and UX Director at Kambrica).

The digital service design industry increasingly relies on agile methodologies, which have brought new ways of working, with different rhythms and goals that have proven to contribute to efficiency and transparency in design and development processes. However, many agile methodologies like Scrum, Agile, or Lean were created from development, and therefore do not initially consider the relevance of the role of design in the experience, its teams, or its methods.

In this context, IxDA Viña del Mar raised the following questions: What is the role of “slow methods” inherent to UCD and research in the agile times we are in? How does each type of methodology address the user experience? What external, human, or other factors favor or hinder the development of processes under each methodology?

Many thanks to Nicolás Espinoza, Katherine Exss, and the entire team and volunteers at IxDA Viña del Mar for the invitation, the excellent reception, and the effort to make everything possible!

Presentation Credits

All other images and videos under CC0 License (Free for any use without attribution required), public domain, or self-produced.