Categorías
Lean UX

Lean vs Agile vs Design Thinking

Has descubierto que tus equipos de ingeniería, producto y diseño, todos están tirando en direcciones opuestas de los demás, en lugar de colaborar de manera más efectiva, porque cada considera que trabaja con la metodología adecuada.

Tal vez no estés viviendo esta situación, sin embargo, estás en una experiencia similar. No te preocupes, hoy te ayudaré en como concentrar los valores de design thinking, lean y agile en uno solo.

Es posible que en tu organización te encuentres con este dilema:

  • Los equipos técnicos se enfocan en acelerar el proceso.
  • Los equipos de producto se enfocaron en reducir el desperdicio.
  • Los equipos de diseño querían al inicio largas fases de investigación y diseño que ayudaran a descubrir en que es lo que los equipos deberían trabajar.

Entonces, ¿cuál proceso es el correcto?

El libro de Lean vs Agile vs Design Thinking de Jeff Gothelf te ayudará a conocer lo que realmente necesites para construir productos digitales con equipos de alto rendimiento.

Y es porque tu trabajo consiste en identificar y escoger los elementos específicos de cada práctica que se acoplan bien para tus equipos, y para los valores de marca que estás tratando de comunicar.

En la experiencia de Jeff Gothelf al tratar con sus clientes, encontró unas cuantas prácticas centrales que sirven como puntos efectivos para gestionar equipos.

Reseña del libro en video

10 buenas prácticas basados en Agile, Lean Startup y Design Thinking para gestionar eficientemente a tus equipos de trabajo

1. Trabajo en ciclos cortos

Para reducir el riesgo toma pasos pequeños. Toma una nueva idea o práctica e inténtala con un subconjunto de equipos. Esta nueva práctica no debería de manejarse como un cambio permanente. En lugar de eso, presenta esto como un “experimento en proceso”.

Si esto falla, el equipo habrá invertido muy poco tiempo y esfuerzo en este cambio, pero habrá prendido mucho. Si el experimento es exitoso, el equipo mantiene la práctica, la mejora, y luego la organización la transfiere a otros equipos.

2. Haz retrospectivas regularmente

Las reuniones de retrospectiva es la base de la mejora continua porque son una oportunidad para considerar las prácticas actuales, evaluar su eficacia y determinar como progresar.

La recomendación es que al final de cada sprint alientes a tus equipos a reunirse por una hora, revisen que fue lo que funciono bien durante ese ciclo, que no funciono bien, y que se comprometan todos a mejorar una o dos cosas claves antes del siguiente sprint.

3. Pon a los consumidores en el centro de todo

El consumidor es la persona que tiene que usar el producto. Si no hay consumidores no hay negocio.

Si hay un debate al interior del equipo con respecto a lo que se tiene que trabajar, cuanto tiempo invertir en algo, o si el producto se encamina en la dirección correcta, considera las siguientes preguntas:

  • ¿Estamos entregando algo que es importante para los usuarios?
  • ¿Cómo investigamos si estamos entregando valor a los usuarios?
  • ¿Cómo es que lo que valoran los usuarios afecta la forma en como establecemos prioridades?

4. Ve y observa

Como líder, es tu responsabilidad ir de manera regular a donde se hace el software, hablar con los equipos, y preguntarles como van las cosas, que está funcionando bien, y en que cosas podrían estar estancados o con problemas.

Trae esos aprendizajes a las reuniones gerenciales y comparte esa información a tus colegas. Los aspectos que estén causando problemas deberán ser diagnosticados y remediados o discontinuados.

5. Balancea el trabajo de descubrir sobre el producto con el trabajo de generar y entregar el producto

Prueba únicamente hipótesis de alto riesgo. Las funcionalidades que califican como de alto riesgo y de alto valor son los únicos que deberían ser punto de interés para esfuerzos de descubriendo del producto.

Una vez que identificas esas suposiciones con riesgos, determina que es lo que más importante que necesitas aprender acerca de ellas, y entonces aprovecha la técnica de descubrimiento más apropiada para aprender lo que requieres.

6. Haz menos investigación, pero más frecuentemente

Es necesario continuar la práctica de investigar usuarios invitando a participar como observador a un equipo inter funcional, pero simplemente hacer menos de esta actividad, con más frecuencia.

Difunde tus hallazgos ampliamente y de forma inmediata después de la prueba. Muestra el valor del ejercicio, reduce el compromiso de participar, así como el costo, y encontrar que el nivel de aceptación de parte de la organización se eleva.

7. Trabaja (y entrena) como un equipo balanceado

Los equipos balanceados proporcionan la experiencia, perspectivas y habilidades necesarias para todos los aspectos de un proyecto. Los equipos deben ser independientes, autónomos y empoderados para tomar decisiones basados en la evidencia que su trabajo de descubrimiento de producto va revelando.

8. Transparencia radical

A medida que se despliegan nuevos procesos, puede existir resistencia ante el cambio, por ello asegúrate que quede claro ante el equipo de trabajo porque ellos están intentando algo nuevo. Permite que la gente vea como el proceso se va dando con otros equipo.

Lleva acabó retrospectivas abiertas de manera que otros puedan comprender donde el nuevo proceso, está experimentando problemas en tu organización.

9. Revisa tu estructura de incentivos

Los equipos optimizarán el trabajo gracias a los incentivos que deben estar reflejados en los criterios de gestión del desempeño.

Si quieres fomentar colaboración y aprendizajes, los empleados deben ser evaluados con respecto a la eficacia de su colaboración y su habilidad para crear oportunidades de aprendizaje continuo en el trabajo.

10. Has el trabajo de descubrimiento de producto en el backlog

El trabajo relacionado al descubrimiento del producto deberá convertirse en factor clave en el backlog. Deberá ser visualizado junto con las tareas relacionadas a entregas de funcionalidad. Deberá también ser priorizado con respecto a otros artículos en el backlog y deberá ser asignado a miembros del equipo.

Se deberá administrar este tipo de tareas, como se hace para tareas de entrega, y las implicaciones del trabajo de descubrir deberán tomarse seriamente. Cambiar tus planes como reacción a esos aprendizajes es agilidad.

¿Quieres saber más sobre Lean vs Agile vs Design Thinking?

Si eres un gerente de producto, ingeniero de software, diseñador o líder de equipo, este libro te dará herramientas prácticas que son inmediatamente aplicables a las actividades diarias de su equipo.

Este breve libro táctico reconcilia las diferencias percibidas en Lean Startup, Agile y Design Thinking, centrándose no en rituales y prácticas sino en los valores que sustentan los tres métodos. 

Lean vs Agile vs Design Thinking: Lo que realmente necesitas conocer para construir productos digitales con equipos de alto rendimiento surge de los años de experiencia práctica directa de Jeff en liderazgo de equipos y en entrenamiento y asesoría de compañía que van desde pequeñas startups hasta grandes organizaciones empresariales.

Libro recomendado para esta lectura: Lean vs Agile vs Design Thinking

Jeff Gothelf (@jboogie), autor del galardonado libro Lean UX, y el libro Sense & Reponse, las tácticas de este libro provienen de años de experiencia práctica en el liderazgo de equipo y en compañías de coaching y mentoring que van desde Pequeñas empresas de nueva creación.

Sobre el Autor

Conclusiones

Espero que esto te ayude demasiado en tu proyecto. Si algún colega crees que lo necesita, no dudes en compartirlo. Te invito a leer mis otros contenidos de UX.

Encuéntrame como @andrescabreraux en cualquier red social de tu preferencia para que puedas enviarme tus dudas o sugerir un tema.

2 respuestas en “Lean vs Agile vs Design Thinking”

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *