El documento presenta los métodos Lean, Agile y Design Thinking y cómo pueden integrarse. Explica que cada método se enfoca en diferentes aspectos como la comunicación, la iteración rápida y la colaboración con los clientes. Luego, describe varios enfoques para combinar estos métodos como el desarrollo paralelo de las vías de diseño y desarrollo o el descubrimiento ágil de productos. El objetivo es aprovechar las fortalezas de cada método para crear soluciones centradas en el usuario de manera eficiente.
3. ¡Hola!
Asesor Design Thinking & Agile Practitioner en BBVA Bancomer
Instructor en Usaria, Aprende UX, E&S Global y ConsulteK
Profesor en EBC · División de Educación Corporativa, ITAM · Extensión Universitaria y Desarrollo Ejecutivo y Escuela Bolsa Mexicana
Parte de UX Nights y Ágiles México
Víctor García
4. Agenda
• Una pequeña historia
• Lean vs Agile vs Design Thinking
• Métodos de integración Lean, Agile & Design Thinking
• El método Mojito
• Dudas y preguntas
7. Como lo explicó el
cliente
Como lo entendió el líder
del proyecto
Como lo diseñó el
equipo de UX
Como lo programó el
equipo de desarrollo
Lo que revisó el equipo
de QA
Como se consultó la
documentación
Como se le cobró al
cliente
Como quedó la fase II
Como fue la campaña
de marketing
Lo que los usuarios
realmente querían
8. “ – Jeff Gothelf.
Nuestros equipos de tecnología están aprendiendo Agile.
Nuestros equipos de producto están aprendiendo sobre Lean
y nuestros equipos de diseño están aprendiendo sobre Design Thinking.
¿Cuál de esos es lo correcto?”.
10. Agile, Lean y Design Thinking
• [Las organizaciones] encuentran estas disciplinas discordantes entre sí,
debido a que sus prácticas, aparentemente complementarias, obligan a
cada disciplina a avanzar en diferentes cadencias, con diferentes prácticas,
orientando diferentes medidas de éxito.
• Cada disciplina trabaja a través de sus propias ceremonias y tácticas,
definiendo un estado ideal de éxito, único para ellos. La colaboración,
entendimiento común, y el incremento de la productividad, que fueron
prometidos por todas estas disciplinas, a veces, no se encuentran en
ninguna parte.
11. “ – Jeff Gothelf.
[No basta con “hacer” Lean, Agile o Design Thinking, es necesario]
hacer una revisión profunda dentro de cada uno de estos métodos
para entender su génesis, su filosofía y la mejor manera
en que se puedan manifestar en nuestras compañías”.
14. T I M B R O W N
Se trata de una disciplina que, utilizando la
sensibilidad y los métodos de los diseñadores,
satisface las necesidades del público con aquello
que resulta tecnológicamente posible y que,
gracias a una estrategia de negocio viable, puede
convertirse en valor para los clientes y en
oportunidades en el mercado”.
“
15.
16. Elementos clave
• Empatía.
• Confianza creativa.
• Colaboración radical y equipos multidisciplinarios.
• Pensamiento divergente y convergente.
• Pensamiento visual.
• Prototipos.
• Iteración.
18. E R I C R I E S
Es un conjunto de prácticas pensadas para ayudar
a los emprendedores a incrementar las
probabilidades de crear una startup con éxito. No
es una fórmula matemática infalible, sino una
filosofía empresarial innovadora que ayuda a los
emprendedores a escapar de las trampas del
pensamiento empresarial tradicional”.
“
19.
20. Elementos clave
• Experimentar lo antes posible las ideas sobre el producto para evitar caer en
suposiciones incorrectas acerca del comportamiento del mercado.
• Supuestos, experimento e hipótesis.
• Tipos de Producto Mínimo Viable.
• Métrica de éxito.
• 10 tipos de Pivote.
22. A G I L E M A N I F E S T O
Estamos descubriendo formas mejores de desarrollar software tanto
por nuestra propia experiencia como ayudando a terceros. A través de
este trabajo hemos aprendido a valorar:
• Individuos e interacciones sobre procesos y herramientas.
• Software funcionando sobre documentación extensiva.
• Colaboración con el cliente sobre negociación contractual.
• Respuesta ante el cambio sobre seguir un plan.
Esto es, aunque valoramos los elementos de la derecha, valoramos más
los de la izquierda”.
“
24. Elementos clave
• Comunicación efectiva entre miembros del equipo debe prevalecer por encima de las
restricciones propias de las herramientas.
• Cuanto antes dispongamos de un producto que funcione, seremos capaces de
encontrar la solución que mejor se adapte al mercado.
• Si el equipo colabora con el cliente, se podrá crear un entendimiento común sobre el
problema y las posibles soluciones.
• Fallar rápido. Fallar barato. El producto inicial no dará con la mejor solución posible, el
objetivo es averiguar qué se ha hecho mal lo antes posible, ajustar y volver a probar.
27. PROBLEMASOLUCIÓNMERCADO
SIN
MODELO DE NEGOCIO
MODELO DE NEGOCIO
NO VALIDADO
MODELO DE NEGOCIO
VALIDADO
Fuente: Elaboración propia a partir de https://blog.usejournal.com/when-which-design-thinking-lean-design-sprint-agile-a4614fa778b9
Empatizar
Definir
Idear
Prototipar
Evaluar
Construir
Medir
Aprender
Sprint Planning
Sprint
Sprint
Review
Retrospective
DESIGN THINKING
LEAN STARTUP
AGILE
PROBLEMASOLUCIÓN
SIN
MODELO DE NEGOCIO
SOLUCIÓN
MODELO DE NEGOCIO
NO VALIDADO
MERCADO
MODELO DE NEGOCIO
VALIDADO
Product Backlog
Refinement
Release
28. Ejercicio
• De acuerdo al esquema, reflexiona y escribe en Post-its métodos, técnicas, prácticas y
herramientas que has utilizado en tu experiencia profesional en cada etapa o intersección
de Lean, Agile y Design Thinking - 2 minutos.
• Por grupos pequeños (3 a 5 personas), conversen sobre su experiencia personal,
identifiquen aspectos positivos y negativos de cada etapa o intersección. Escriban en Post-
its sus reflexiones - 10 minutos.
• Vacíen sus anotaciones en el registro gráfico - 3 minutos.
(15 minutos)
32. 2001 2007 2008
• Se publica el
Manifiesto Ágil
• Adapting
Usability
Investigations for
Agile User-
centered Design
• Eric Ries escribe
en su blog sobre
el método Lean
Startup.
33. Desarrollo en vías en paralelo (2007).
Planear y recopilar
datos de los usuarios
Ciclo 0
Ciclo 1 Ciclo 2 Ciclo 3
Implementar diseño
Diseño
Código
Diseño
Código
Implementar diseño Track de desarrollo
Track de diseño
Implementar funcionalidades
de alto costo de desarrollo
y bajo costo de diseño
Diseñar para el ciclo 2
Recopilar datos de los usuarios
para el ciclo 3
Evaluar código del ciclo 1
Diseñar para el ciclo 3
Recopilar datos de los usuarios
para el ciclo 4
Evaluar código del ciclo 2
Diseñar para el ciclo 4
Recopilar datos de los usuarios
para el ciclo 5
Datos
Datos
35. Buenas prácticas
• Las investigaciones de usabilidad se llevan a cabo durante todo el ciclo de
vida del producto, en lugar de agruparse en el extremo inicial o final.
• Primero se trabaja en los elementos de diseño más importantes, no se
“desperdicia” (waste) ningún esfuerzo describiendo diseños no utilizados.
• Los cambios de producto sugeridos por las pruebas de usabilidad y las
investigaciones contextuales se pueden implementar en la versión actual
del producto.
36. Buenas prácticas
• Las actividades de diseño se producen al menos un ciclo ágil o un Sprint por
delante del equipo de desarrollo en una “pista de diseño de interacción”
separada de la “pista de desarrollo”.
37. “ – Desirée Sy.
Es posible utilizar el arsenal familiar de métodos de investigación de usabilidad
en proyectos ágiles cambiando el momento y la granularidad de las
investigaciones y cómo se informan los resultados.
39. 2007 2009 2013
• Inicia la
revolución móvil
• Agile
Development that
incorporates
User Experience
Practices
• Aparece Lean UX
40. UCD en ciclos de desarrollo ágil (2009).
Visitas de sitio
Entrevistas
Investigación
Estudios de competidores
Creación de Historias de Usuario
Storyboard
Prototipo
Diseño
Estudio
Reporte de datos
Trabajo del equipo del usuario
Sprint 0 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint n-1... Sprint n
Investigación
del contexto
para entender
las metas del usuario
Recopilación de metas de usuario para el equipo
Ida y vuelta Validación
Planeación del sprint
Disponibilidad continua
Código reemplaza al prototipo como especificación
41.
42. Aspectos negativos
• Hay poco tiempo para el diseño inicial
• Es difícil hablar de los usuarios cuando están mal definidos
• Agile está centrado en el desarrollador
• Hay poco tiempo para hacer pruebas de usabilidad
• Agile no es propicio para un equipo UX centralizado
• “Tenemos que hacer Ágil como dice el libro, y UX no está en ese libro”
43. Aspectos positivos
• Los practicantes de la experiencia del usuario son puentes
• El trabajo de UX debe ser temprano y flexible
• Prototipos de baja fidelidad como documento de especificación
• El trabajo de la experiencia del usuario ocurre en paralelo
• Validación de UX estilo guerrilla
44. “ – Jakob Nielsen.
The main change for user experience practitioners
who must support an Agile team is in mindset.
45. Ejercicio
• De acuerdo al método presentado y a tu experiencia, escribe en Post-its los
aspectos positivos y negativos que identifiques - 3 minutos.
• Vaciar anotaciones en el registro gráfico - 2 minutos.
(5 minutos)
47. User Story Mapping. Discover the whole story,
build the right product
Jeff Patton
48. 2013 2014 2015
• Aparece Lean UX • User Story
Mapping.
Discover the
whole story, build
the right product
• Design Thinking
es portada en la
revista HBR
49.
50. Discovery y delivery
En el desarrollo de productos y servicios, las organizaciones siempre intentan,
o deberían intentar, contar con un equilibrio entre dos aspectos
fundamentales:
• Discovery: Entender un problema real de las personas y descubrir una
solución.
• Delivery: Construir la solución.
56. DISCOVERY
Building the right product
Creating better outcomes
Maximize learning velocity
DELIVERY
Building the product right
Creating high quality output
Maximize delivery velocity
Agile.
No waste
62. OPPORTUNITIES DISCOVERY DELIVERY VALIDATION RELEASE
• Crea un Opportunity
Backlog a partir de
ideas de productos y
solicitudes de
clientes, usuarios y
stakeholders.
• Utiliza el
descubrimiento para
elaborar, diseñar y
validar ideas del
producto.
• El objetivo es
identificar el
producto viable más
pequeño posible. El
trabajo de
descubrimiento debe
dar como resultado
items del Product
Backlog. Divide los posibles items del Product Backlog
en los elementos necesarios para múltiples
lanzamientos viables de productos o features.
• Durante la entrega, el
foco es diseñar,
descomponer en
tareas y describir a
detalle los elementos
del Product Backlog.
• Revisión del software
terminado con el
equipo y
stakeholders.
• Validar el incremento
del producto con
clientes y usuarios.
• Una vez que se lance
el software, continúa
midiendo el
rendimiento del
producto en relación
con sus resultados
objetivo.
• Las nuevas
oportunidades
valiosas vienen
después de ver el
producto en uso.
63. OPPORTUNITIES
OPPORTUNITY
ASSESSMENT
• Antes de dedicar
tiempo a detalles
sobre cualquier idea,
discutir para quién es
el producto, la
funcionalidad o la
mejora, qué beneficio
traerá al construirlo y
cuánto podría costar.
• Utilizar los resultados
de esta conversación
para priorizar
oportunidades y para
tomar decisiones de
ir / no ir.
DISCOVERY
PRODUCT DISCOVERY
• En el descubrimiento
responder:
1. ¿Qué problema
estamos resolviendo
y para quién?
2. ¿Qué soluciones
valorarían los
usuarios?
3. ¿Cuáles son las
soluciones más
usables?
4. ¿Qué es factible
construir dado el
tiempo y las
herramientas?
DELIVERY
PRODUCT TEAM
PLANNING
• El equipo de producto
se reúne de manera
frecuente para
discutir el progreso
del release,
seleccionar historias
para los próximos
sprints / iteraciones y
planificar el trabajo
necesario para
preparar las historias
para el equipo de
desarrollo.
STORY WORKSHOP
• Analizar los detalles
de las historias y
acordar los criterios
de aceptación.
VALIDATION
ENOUGH TO TEST
WITH USERS
• Las historias que se
completen en un solo
sprint pueden
parecer
insignificantes para
los usuarios.
• Reúne suficientes
piezas del producto
para validar que los
usuarios puedan
alcanzar un objetivo
significativo, antes de
realizar las pruebas.
RELEASE
ENOUGH TO RELEASE
• Reúne suficientes
partes validadas del
producto que sumen
una versión valiosa
del producto para
liberar.
69. Opportunity Canvas
Users & Customers
What types of users and customers have the challenges your
solution addresses?
Look for differences in user’s goals or uses that would affect their
use of the product. Separate users and customers into different
types based on those differences that make a difference. It’s a
bad idea to target “everyone” with your product.
Problems
What problems do prospective users and customers have today
that your solution addresses?
What needs, goals, or jobs-to-be-done done should your
solution address?
Solution ideas
List product, feature, or enhancement ideas that solve problems
for your target audience.
How will users use your
solution?
If your target audience has your solution, what will they do
differently as a consequence? And, how will that benefit them?
User Metrics
What specific user behaviors can you measure that will indicate
they try, adopt, use, and place value in your solution?
Solutions Today
How do users address their problems today?
List competitive products or work-around approaches your users
have for meeting their needs.
Adoption Strategy
How will customers and users discover and adopt your solution?
Business Challenges
How do the customers’ and users’ and their challenges above impact your business? If you don’t solve these problems for your
customers and users, will it hurt your business? How?
Business Benefits and Metrics
What business performance metrics will be affected by the success of this solution? These usually change as a consequence of users
actually buying and using your solution.
Title: Date:
Iteration:
12
1
3
4
6
5
7
89
Budget
1. What might it cost your organization if you don’t create this
solution?
2. What might your organization earn or save if you do?
3. Given that, what would your organization budget to create this
solution?
Download at: http://jpattonassociates.com/opportunity-canvas/
Challenge OutcomesOutput
70. Discovery
• Product Discovery Canvas.
• Product Goal:
• Elevator Pitch.
• Simple Personas:
• Proto-Persona.
• User Story Mapping.
• Simple User Interface sketches:
• Design Studio Prototyping Process.
71.
72. Elevator pitch template
For [target customers] who are dissatisfied with [the current market alternative], our product is
a [new product category] that provides [the product’s key problem-solving capability]. Unlike
[the product alternative], our product [describe what the product does, its key features].
target customers
For
the current market alternative,
who are
dissatisfied
with
new product category
Our product
is A
the product’s key problem-solving capability.
that provides.
the product alternative,
Unlike
describe what the product does, its key features.
our product
Agile Project Kick-off Kit
78. Ejercicio
• De acuerdo al método presentado y a tu experiencia, escribe en Post-its los
aspectos positivos y negativos que identifiques - 3 minutos.
• Vaciar anotaciones en el registro gráfico - 2 minutos.
(5 minutos)
80. The Agile Samurai. How Agile Masters Deliver
Great Software
Jonathan Rasmusson
81. 2000 2001 2010
• Agile Project
Initiation
Techniques –
The Inception
Deck & Boot
Camp.
• Se publica el
Manifiesto Ágil
• The Agile
Samurai. How
Agile Masters
Deliver Great
Software.
2013
• Lean UX.
82. “ – Jonathan Rasmusson
¿Cuántos de tus proyectos comienzan así:
El equipo se reúne al inicio de un proyecto pensando que
todos están “en la misma página”?»
83.
84. “ – Jonathan Rasmusson
Y cuando empiezas a construir algo, te das cuenta de que estabas pensando en
algo completamente diferente”.
85.
86. “ – Jonathan Rasmusson
Esto sucede todo el tiempo en los proyectos:
asumir que hay consenso cuando no existe ninguno.
Para eliminar este problema, hemos creado una herramienta ligera llamada
“The Agile Inception Deck: 10 preguntas y ejercicios que estarías loco si no
realizas antes de iniciar tu proyecto”».
87.
88. El mejor momento
• Agile Inception Deck se creó dentro del espíritu de desarrollo ágil de
software.
• El objetivo es no enmarañarse en seis meses de planificación y
especulación previa al proyecto, sino obtener el mismo resultado en un
período mucho más corto de tiempo al iniciar el proyecto.
89. Objetivos
• Obtener el compromiso de los involucrados en el proyecto.
• Resolver cualquier conflicto potencial en el proyecto, metas u objetivos.
• Asegurarse de tener un punto de vista común sobre el proyecto.
• Establecer expectativas.
90. Cómo realizar un AID
• Taller colaborativo, con la participación de todas las personas fuertemente
involucradas en el problema a discutir.
• Rol de facilitador del taller.
• Definir una duración total (1 día a 2 semanas).
92. Why are we here? Elevator Pitch
Design a
Product Box
Create a
NOT list
Meet your
neighbors
Show your
solution
Ask what keeps us
up at night?
Size it up
Be clear on what´s
going to give
Show what it´s
going to take
1 2 3 4 5
6 7 8 9 10
93. Why are we here? Elevator Pitch
Design a
Product Box
Create a
NOT list
Meet your
neighbors
Show your
solution
Ask what keeps us
up at night?
Size it up
Be clear on what´s
going to give
Show what it´s
going to take
1 2 3 4 5
6 7 8 9 10
Seeing the big picture
94. Why are we here? Elevator Pitch
Design a
Product Box
Create a
NOT list
Meet your
neighbors
Show your
solution
Ask what keeps us
up at night?
Size it up
Be clear on what´s
going to give
Show what it´s
going to take
1 2 3 4 5
6 7 8 9 10
Making it real
95. Siguientes pasos…
• Construir un User Story Map
• Definir Minimum Viable Product
• Definir Minimum Marketeable Feature
• Integrar primera versión del Product Backlog
100. Buenas prácticas
• En Dual-Track Agile, el flujo de trabajo no se caracteriza por que cada rol
entregue artefactos en el siguiente paso; más bien es colaborativo: el
gerente de producto, el diseñador y el ingeniero principal están trabajando
juntos, uno al lado del otro, para crear y validar los elementos del Backlog.
101. Buenas prácticas
• En lugar de centrarnos en los artefactos, nos centramos en los prototipos y
en la validación de esos prototipos en Discovery, con el beneficio adicional
de que el prototipo sirve como la especificación para la entrega.
102. “ – Marty Cagan.
Building and launching a product idea is generally
the slowest, most expensive way to validate the idea.”
108. Lean UX Canvas (v2)
Users
What types (i.e., personas) of users and customers should you focus on first?
(Hint: Who buys your product or service? Who uses it? Who configures it? Etc)
Solutions
What can we make that will solve our business problem and
meet the needs of our customers at the same time? List
product, feature, or enhancement ideas here.
User Outcomes & Benefits
Why would your users seek out your product or service? What benefit would they gain from
using it? What behavior change can we observe that tells us they've achieved their goal?
(Hint: Save money, get a promotion, spend more time with family)
Hypotheses
Combine the assumptions from 2, 3, 4 & 5 into the following hypothesis statement:
“We believe that [business outcome] will be achieved if [user] attains [benefit] with [feature].”
(Hint: Each hypothesis should focus on one feature only.)
What’s the least amount of work we need
to do to learn the next most important
thing?
Design experiments to learn as fast as you can whether your riskiest assumption is true or
false.
Business Problem
What problem does the business have that you are trying to solve?
(Hint: Consider your current offerings and how they delver value, changes in the market,
delivery channels, competitive threats and customer behavior.)
Business Outcomes
How will you know you solved the business problem? What will you measure?
(Hint: What will people/users be doing differently if your solutions work? Consider metrics
that indicate customer success like average order value, time on site, and retention rate.)
Title of initiative: Date:
Iteration:
5
3
8
1
6
4
7
2
Download this canvas at: www.jeffgothelf.com/blog/leanuxcanvas-v2
What’s the most important
thing we need to learn first?
For each hypothesis from Box 6, identify its riskiest
assumptions. Then determine the riskiest one right now. This is
the assumption that will cause the entire idea to fail if it’s
wrong.
(Hint: In the early stages of a hypothesis focus on risks to value
rather than feasibility.)
109. Hypothesis Prioritization Canvas Project Name: Date:
Iteration:
2
Download this canvas at: https://jeffgothelf.com/blog/the-hypothesis-prioritization-canvas
3 4
Test
These hypotheses have the promise of a big return but also pose
significant risks. These are the hypotheses you should focus your
experimentation, learning and discovery activities on.
Ship & Measure
The level of confidence is high about these hypotheses. Combined
with a strong belief they will deliver customer and business value, we
build, launch and measure them. Don’t spend your discovery cycles
here.
Discard
These hypotheses provide little value and pose a high level of risk to
your business or product. Don’t spend any more time on them.
Don’t test. Usually Don’t Build
These hypotheses don’t add significant value but are also low risk so
don’t require discovery efforts. However, sometimes ideas land here
that are table stakes for the operation of the business. They won’t
differentiate you in the market but you need them to be in business
(e.g., a payment system).
HighperceivedvalueLowperceivedvalue
Low risk
1
High risk
119. Ejercicio
• De acuerdo al método presentado y a tu experiencia, escribe en Post-its los
aspectos positivos y negativos que identifiques - 3 minutos.
• Vaciar anotaciones en el registro gráfico - 2 minutos.
(5 minutos)
125. Ejercicio
• Por grupos pequeños (3 a 5 personas), conversen sobre todos los métodos
presentados, de acuerdo a su experiencia, propongan un esquema de
integración que represente su método Mojito - 15 minutos.
• Compartir - 5 minutos.
(20 minutos)